--- 1/draft-ietf-mpls-seamless-mpls-00.txt 2012-03-12 16:13:56.134670613 +0100 +++ 2/draft-ietf-mpls-seamless-mpls-01.txt 2012-03-12 16:13:56.218672837 +0100 @@ -1,25 +1,24 @@ MPLS Working Group N. Leymann, Ed. Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene -Expires: November 30, 2011 France Telecom +Expires: September 13, 2012 France Telecom C. Filsfils - Cisco Systems M. Konstantynowicz - Juniper Networks + Cisco Systems D. Steinberg Steinberg Consulting - May 29, 2011 + March 12, 2012 Seamless MPLS Architecture - draft-ietf-mpls-seamless-mpls-00 + draft-ietf-mpls-seamless-mpls-01 Abstract This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service @@ -38,104 +37,108 @@ 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 November 30, 2011. + + This Internet-Draft will expire on September 13, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 7 - 2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 8 - 2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11 - 2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 11 - 2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 11 - 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 13 - 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 14 - 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 16 - 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 16 - 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . . 16 - 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 17 - 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . . 17 - 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . . 17 - 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 18 - 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . . 18 - 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.1.2. General Network Topology . . . . . . . . . . . . . . . 18 - 5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 - 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . . 20 - 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 20 - 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . . 21 - 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . . 22 - 5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 23 - 5.1.8. Network Availability and Simplicity . . . . . . . . . 24 - 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 24 - 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . . 25 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7 + 2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 10 + 2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 + 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 12 + 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13 + 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . . 15 + 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . . 16 + 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . . 16 + 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17 + 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . . 17 + 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.1.2. General Network Topology . . . . . . . . . . . . . . . 17 + 5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18 + 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . . 19 + 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 + 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . . 20 + 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . . 21 + 5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22 + 5.1.8. Network Availability and Simplicity . . . . . . . . . 23 + 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 + 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . . 24 5.1.8.3. Hierarchical Dataplane and BGP Prefix - Independent Convergence . . . . . . . . . . . . . 25 - 5.1.8.4. Local Protection using Anycast BGP . . . . . . . . 26 - 5.1.8.5. Assessing loss of connectivity upon any failure . 31 - 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 36 - 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . . 37 - 5.1.9. Next-Hop Redundancy . . . . . . . . . . . . . . . . . 37 - 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . . 38 + Independent Convergence . . . . . . . . . . . . . 24 + 5.1.8.4. Local Protection using Anycast BGP . . . . . . . . 25 + 5.1.8.5. Assessing loss of connectivity upon any failure . 30 + 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 35 + 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . . 36 + 5.1.9. Next-Hop Redundancy . . . . . . . . . . . . . . . . . 36 + 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . . 37 5.2.1. Control and Data Plane State for Deployment - Scenario #1 . . . . . . . . . . . . . . . . . . . . . 38 - 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . . 38 - 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 39 - 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . . 40 - 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 41 - 5.2.1.5. Numerical application for use case #1 . . . . . . 42 - 5.2.1.6. Numerical application for use case #2 . . . . . . 42 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 + Scenario #1 . . . . . . . . . . . . . . . . . . . . . 37 + 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . . 37 + 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 38 + 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . . 39 + 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 40 + 5.2.1.5. Numerical application for use case #1 . . . . . . 41 + 5.2.1.6. Numerical application for use case #2 . . . . . . 41 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 + 8.1. Access Network Security . . . . . . . . . . . . . . . . . 43 + 8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 43 + 8.3. Control Plane Security . . . . . . . . . . . . . . . . . . 44 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . . . 44 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 44 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 45 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction MPLS as a mature and well known technology is widely deployed in today's core and aggregation/metro area networks. Many metro area networks are already based on MPLS delivering Ethernet services to residential and business customers. Until now those deployments are usually done in different domains; e.g. core and metro area networks are handled as separate MPLS domains. @@ -1884,68 +1887,129 @@ o TN IP FIB 750 o TN MPLS LFIB 150 o RR BGP NLRI 40 000 o RR BGP paths 80 000 6. Acknowledgements - Many people contributed to this document. The authors wish to thank - - in alphabetical order: - - o Wim Henderickx (Alcatel) - - o Clarence Filsfils (Cisco Networks), - - o Thomas Beckhaus, Wilfried Maas, Roger Wenner (Deutsche Telekom), - - o Kireeti Kompella, Yakov Rekhter (Juniper Networks), - - o Mark Tinka (Global Transit) - - o Simon DeLord (Telstra) + Many people contributed to this document. The authors would like to + thank Wim Henderickx, Clarence Filsfils, Thomas Beckhaus, Wilfried + Maas, Roger Wenner, Kireeti Kompella, Yakov Rekhter, Mark Tinka and + Simon DeLord for their suggestions and review. 7. IANA Considerations This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 8. Security Considerations - In a typical MPLS deployment the use of MPLS is limited to relatively - small network consisting of core and edge nodes. Those nodes are - under full control of the services provider and placed at locations - where only authorized personal has access (this also includes - physical access to the nodes). With the extensions of MPLS towards - access and aggregation nodes not all nodes will be "locked away" in - secure locations. Small access nodes like DSLAMs will be located in - street cabinets, potentially offering access to the "interested - researcher". Nevertheless the unauthorized access to such in device - SHOULD NOT impose any security risks to the MPLS infrastructure - itself. Seamless MPLS must be stable regarding attacks against - access and aggregation nodes running MPLS. + The Seamless MPLS Architecture 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 + [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. - Levels of Security: tbd. +8.1. Access Network Security - Access Network: tbd. + A detailed description for Access Network Security in Seamless MPLS + can be found in the LDP Downstream on Demand document + [I-D.ietf-mpls-ldp-dod]. - Aggregation Network: tbd. +8.2. Data Plane Security - Core Network: tbd. + 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. + +8.3. Control Plane Security + + Similarly to Inter-AS MPLS/VPN deployments RFC4364 [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 [RFC5925] should be used with LDP as described in LDP + specification RFC5036 [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 RFC5925 + [RFC5925]) 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. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References @@ -1963,20 +2027,26 @@ Uttaro, J., Leymann, N., and M. Horneffer, "LFA applicability in SP networks", draft-filsfils-rtgwg-lfa-applicability-00 (work in progress), March 2010. [I-D.ietf-bfd-v4v6-1hop] Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress), January 2010. + [I-D.ietf-mpls-ldp-dod] + Beckhaus, T., Decraene, B., Tiruveedhula, K., + Konstantynowicz, M., and L. Martini, "LDP Downstream-on- + Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-00 (work + in progress), January 2012. + [I-D.kothari-henderickx-l2vpn-vpls-multihoming] Kothari, B., Kompella, K., Henderickx, W., and F. Balus, "BGP based Multi-homing in Virtual Private LAN Service", draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work in progress), July 2009. [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-09 (work in @@ -2032,20 +2102,23 @@ [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, June 2010. + Authors' Addresses Nicolai Leymann (editor) Deutsche Telekom AG Winterfeldtstrasse 21 Berlin 10781 DE Phone: +49 30 8353-92761 Email: n.leymann@telekom.de @@ -2064,24 +2138,24 @@ Cisco Systems Brussels, Belgium Phone: Fax: Email: cfilsfil@cisco.com URI: Maciek Konstantynowicz - Juniper Networks + Cisco Systems Phone: Fax: - Email: maciek@juniper.net + Email: maciek@cisco.com URI: Dirk Steinberg Steinberg Consulting Ringstrasse 2 Buchholz 53567 DE Email: dws@steinbergnet.net