--- 1/draft-ietf-mpls-ldp-dod-00.txt 2012-03-12 20:14:04.954754464 +0100 +++ 2/draft-ietf-mpls-ldp-dod-01.txt 2012-03-12 20:14:05.006805712 +0100 @@ -1,24 +1,24 @@ Network Working Group T. Beckhaus Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene -Expires: July 7, 2012 France Telecom +Expires: September 13, 2012 France Telecom K. Tiruveedhula - M. Konstantynowicz Juniper Networks + M. Konstantynowicz L. Martini Cisco Systems, Inc. - January 04, 2012 + March 12, 2012 LDP Downstream-on-Demand in Seamless MPLS - draft-ietf-mpls-ldp-dod-00 + draft-ietf-mpls-ldp-dod-01 Abstract Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand @@ -43,21 +43,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 7, 2012. + This Internet-Draft will expire on September 13, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -93,25 +93,30 @@ 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24 4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 + 6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 28 + 6.1.1. Access to network packet flow direction . . . . . . . 28 + 6.1.2. Network to access packet flow direction . . . . . . . 29 + 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30 + 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 30 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold. @@ -1191,47 +1196,202 @@ This document uses a new a new Optional Parameter Queue Request TLV in the Label Request message defined in Section 4.4.3. IANA already maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by RFC5036. The following value is suggested for assignment: TLV type Description 0x0971 Queue Request TLV 6. Security Considerations + MPLS LDP Downstream on Demand deployment in the access network is + subject to similar security threats as any MPLS LDP deployment. It + is recommended that baseline security measures are considered as + described in the LDP specification [RFC5036] including ensuring + authenticity and integrity of LDP messages, as well as protection + against spoofing and Denial of Service attacks. + + Some deployments may require increased measures of network security + if a subset of Access Nodes are placed in locations with lower levels + of physical security e.g. street cabinets (common practice for VDSL + access). In such cases it is the responsibility of the system + designer to take into account the physical security measures + (environmental design, mechanical or electronic access control, + intrusion detection), as well as monitoring and auditing measures + (configuration and Operating System changes, reloads, routes + advertisements). + + But even with all this in mind, the designer still should consider + network security risks and adequate measures arising from the lower + level of physical security of those locations. + +6.1. Security and LDP DoD + +6.1.1. Access to network packet flow direction + + An important property of MPLS LDP Downstream on Demand operation is + that the upstream LSR (requesting LSR) accepts only mappings it sent + a request for (in other words the ones it is interested in), and does + not accept any unsolicited label mappings by design. + + This limits the potential of an unauthorized third party fiddling + with label mappings operations on the wire. It also enables ABR LSR + to monitor behaviour of any Access LSR in case the latter gets + compromised and attempts to get access to an unauthorized FEC or + remote LSR. Note that ABR LSR is effectively acting as a gateway to + the MPLS network, and any label mapping requests made by any Access + LSR are processed and can be monitored on this ABR LSR. + +6.1.2. Network to access packet flow direction + + Another important property of MPLS LDP DoD operation in the access is + that the number of access nodes and associated MPLS FECs per ABR LSR + is not large in number, and they are all known at the deployment + time. Hence any changes of the access MPLS FECs can be easily + controlled and monitored on the ABR LSR. + + And then, even in the event when Access LSR manages to advertise a + FEC that belongs to another LSR (e.g. in order to 'steal' third party + data flows, or breach a privacy of VPN), such Access LSR will have to + influence the routing decision for affected FEC on the ABR LSR. + Following measures SHOULD be considered to prevent such event from + occurring: + + a. ABR LSR - access side with static routes - this is not possible + for Access LSR. Access LSR has no way to influence ABR LSR + routing decisions due to static nature of routing configuration + here. + + b. ABR LSR - access side with IGP - this is still not possible if + the compromised Access LSR is a leaf in the access topology (leaf + node in topologies I1, I, V, Y described earlier in this + document), due to the leaf metrics being configured on the ABR + LSR. If the compromised Access LSR is a transit LSR in the + access topology (transit node in topologies I, Y, U), it is + possible for this Access LSR to attract to itself traffic + destined to the nodes upstream from it. However elaborate such + 'man in the middle attack' is possible, but can be quickly + detected by upstream Access LSRs not receiving traffic, and + legitimate traffic from them getting dropped. + + c. ABR LSR - network side - designer SHOULD consider giving a higher + administrative preference to the labeled unicast BGP routes vs. + access IGP routes. + + In summary MPLS in access design with LDP DoD has number of native + properties that prevent number of security attacks and make their + detection quick and straightforward. + + Following two sections describe other security considerations + applicable to general MPLS deployments in the access. + +6.2. Data Plane Security + + Data plane security risks applicable to the access MPLS network are + listed below (a non-exhaustive list): + + a. packets from a specific access node flow to an altered transport + layer or service layer destination. + + b. packets belonging to undefined services flow to and from the + access network. + + c. unlabelled packets destined to remote network nodes. + + Following mechanisms should be considered to address listed data + plane security risks: + + 1. addressing (a) - Access and ABR LSRs SHOULD NOT accept labeled + packets over a particular data link, unless from the Access or + ABR LSR perspective this data link is known to attach to a + trusted system based on employed authentication mechanism(s), and + the top label has been distributed to the upstream neighbour by + the receiving Access or ABR LSR. + + 2. addressing (a) - ABR LSR MAY restrict network reachability for + access devices to a subset of remote network LSR, based on + authentication or other network security technologies employed + towards Access LSRs. Restricted reachability can be enforced on + the ABR LSR using local routing policies, and can be distributed + towards the core MPLS network using routing policies associated + with access MPLS FECs. + + 3. addressing (b) - labeled service routes (e.g. MPLS/VPN, tLDP) + are not accepted from unreliable routing peers. Detection of + unreliable routing peers is achieved by engaging routing protocol + detection and alarm mechanisms, and is out of scope of this + document. + + 4. addressing (a) and (b) - no successful attacks have been mounted + on the control plane and has been detected. + + 5. addressing (c) - ABR LSR MAY restrict IP network reachability to + and from the access LSR. + +6.3. Control Plane Security + + Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the data plane + security depends on the security of the control plane. + + To ensure control plane security access LDP DoD connections MUST only + be made with LDP peers that are considered trusted from the local LSR + perspective, meaning they are reachable over a data link that is + known to attach to a trusted system based on employed authentication + mechanism(s) on the local LSR. + + The TCP/IP MD5 authentication option [RFC5925] should be used with + LDP as described in LDP specification [RFC5036]. If TCP/IP MD5 + authentication is considered not secure enough, the designer may + consider using a more elaborate and advanced TCP Authentication + Option (TCP-AO RFC 5925) for LDP session authentication. + + Access IGP (if used) and any routing protocols used in access network + for signalling service routes SHOULD also be secured in a similar + manner. + + For increased level of authentication in the control plane security + for a subset of access locations with lower physical security, + designer could also consider using: + + o different crypto keys for use in authentication procedures for + these locations. + + o stricter network protection mechanisms including DoS protection, + interface and session flap dampening. + 7. Acknowledgements The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai Leymann and Ina Minei for their suggestions and review. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. 8.2. Informative References [I-D.ietf-mpls-ldp-ipv6] - Asati, R., Manral, V., Papneja, R., and C. Pignataro, - "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-05 - (work in progress), August 2011. + Pignataro, C., Asati, R., Papneja, R., and V. Manral, + "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06 + (work in progress), January 2012. [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", - draft-ietf-mpls-seamless-mpls-00 (work in progress), - May 2011. + draft-ietf-mpls-seamless-mpls-01 (work in progress), + March 2012. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. @@ -1242,20 +1402,23 @@ Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009. + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, June 2010. + Authors' Addresses Thomas Beckhaus Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 Darmstadt, 64307 Germany Phone: +49 6151 58 12825 Fax: @@ -1278,25 +1441,25 @@ 10 Technology Park Drive Westford, Massachusetts 01886 USA Phone: 1-(978)-589-8861 Fax: Email: kishoret@juniper.net URI: Maciek Konstantynowicz - Juniper Networks + Cisco Systems, Inc. Phone: Fax: - Email: maciek@juniper.net + Email: maciek@bgp.nu URI: Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 USA Phone: Fax: