By Topic

Authentication on LDP (Label Distribution Protocol)

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

The purchase and pricing options are temporarily unavailable. Please try again later.
3 Author(s)

This article proposes a solution for the LDP (Label Distribution Protocol) from the MPLS (Multiprocol Label Switch) architecture. The objective is authenticate, on an end to end basis, the establishment of an LSP (Label Switching Path) between the Ingress LSR (Label Switching Router) and its Egress, to supply the LDP protocol deficiency that doesn't have one end to end authentication mechanism defined for non-adjacent LSRs. Actually authentication defined for the LDP, RFC3036, based on the TCP/MD5 option, is restricted to adjacent LSRs, because depends on a TCP connection between the involved LSRs. In the case of LSPs between non-adjacent LSRs, during the establishment of the first LSP, an end-to-end TCP connection doesnu2019t exist between these LSRs. So the solution from RFC3036 doesnu2019t deal with efficient way situations where two LSRs intend to authenticate mutually end-to-end during the establishment of a new LSP This work model of authentication defines mechanisms to the LDP that make possible to carry the authentication fields through the intermediate LSRs transparently end-to-end, allowing of this form that the endpoints of the LSP could be authenticated. The solution makes use of an authentication mechanism based on public-key cryptography attached to the LDP messages that makes possible to the receiver LSR verifies and authenticates the originator of the messages. It provides integrity protection to the information through a hash mechanism and additionally protects against reply attacks through the insertion of a nonce in the LDP messages. It doesnu2019t provide confidentiality. As requisite, the solution demands that the LDP operate in "Ordered" control mode and regarding to the distribution modes of the LDP, "On-Demand" and "Unsolicited", both are compatible. There where defined two new TLVs (Type-Length-Value) to the LDP to provide this authentication solution, "Hash TLV" and "Nonce TLV", and a new "Status Code" type with the value "Authenticatio- - n Failed" for the LDP Status TLV. LDP messages involved in the authentication process are LABEL REQUEST, LABEL MAPPING and LDP NOTIFICATION, these three types of messages give conditions to the LDP to request and send labels for the establishment of LSPs and to notify fails about these operations. This solution was planned for environments where LSPs crosses external multi-domain environments, not trustworthy between themselves and for this reason need a way to authenticate the endpoints of the LSP during its establishment.

Published in:

Latin America Transactions, IEEE (Revista IEEE America Latina)  (Volume:1 ,  Issue: 1 )