--- 1/draft-ietf-idr-bgp-prefix-sid-13.txt 2018-02-07 15:13:13.781316685 -0800 +++ 2/draft-ietf-idr-bgp-prefix-sid-14.txt 2018-02-07 15:13:13.817317550 -0800 @@ -1,23 +1,23 @@ IDR S. Previdi, Ed. Internet-Draft C. Filsfils Intended status: Standards Track A. Lindem -Expires: August 9, 2018 Cisco Systems +Expires: August 11, 2018 Cisco Systems A. Sreekantiah H. Gredler RtBrick Inc. - February 5, 2018 + February 7, 2018 Segment Routing Prefix SID extensions for BGP - draft-ietf-idr-bgp-prefix-sid-13 + draft-ietf-idr-bgp-prefix-sid-14 Abstract Segment Routing (SR) architecture allows a node to steer a packet flow through any topological path and service chain by leveraging source routing. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SID). Each SID represents a topological or a service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. @@ -41,21 +41,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 August 9, 2018. + This Internet-Draft will expire on August 11, 2018. Copyright Notice Copyright (c) 2018 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 @@ -100,21 +100,21 @@ as "go to prefix P following shortest path" or a service instruction (e.g., "pass through deep packet inspection"). Other types of segments may be defined in the future. A segment is identified through a Segment Identifier (SID). Typically, the ingress node of the SR domain prepends an SR header containing segments identifiers (SIDs) to an incoming packet. As described in [I-D.ietf-spring-segment-routing], when SR is applied to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the - SID consists of a label while when SR is applied to the IPv6 + SID consists of a label, while when SR is applied to the IPv6 dataplane the SID consists of an IPv6 address. A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment attached to a BGP prefix. A BGP Prefix-SID is always a global SID ([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e., the set of Autonomous Systems under a common administration and control and where SR is used) and identifies an instruction to forward the packet over the ECMP-aware best-path computed by BGP to the related prefix. The BGP Prefix-SID is the identifier of the BGP prefix segment. In this document, we always refer to the BGP segment @@ -425,25 +425,25 @@ The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY contain the Originator SRGB TLV. A BGP Prefix-SID attribute received without a Label-Index TLV MUST be considered as "unacceptable" by the receiving speaker. If multiple prefixes are received with the same label index value, all these prefixes MUST have their BGP Prefix-SID attribute considered as "unacceptable" by the receiving speaker. When a BGP speaker receives a path from a neighbor with an acceptable - BGP Prefix-SID attribute, it MUST program the derived label as the - local label for the prefix in its MPLS dataplane. In case of an - error, a BGP speaker MUST follow to the error handling rules - specified in Section 6. A BGP speaker SHOULD log an error for - further analysis. + BGP Prefix-SID attribute and that path is selected as the best path, + it SHOULD program the derived label as the local label for the prefix + in its MPLS dataplane. In case of an error, a BGP speaker MUST + follow to the error handling rules specified in Section 6. A BGP + speaker SHOULD log an error for further analysis. When a BGP speaker receives a path from a neighbor with an unacceptable BGP Prefix-SID attribute or when a BGP speaker receives a path from a neighbor with a BGP Prefix-SID attribute but is unable to process it (it does not have the capability or local policy disables the capability), it MUST treat the path as if it came without a BGP Prefix-SID attribute. For the purposes of local label allocation, a BGP speaker MUST assign a local (also called dynamic) label (non-SRGB) for such a prefix as per classic Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. A BGP speaker @@ -465,29 +465,30 @@ When an SR IPv6 BGP speaker receives an IPv6 Unicast BGP Update with a prefix having the BGP Prefix-SID attribute attached, it checks whether the IPv6 SID TLV is present. If present and chosen as the best path, the prefix is installed into the Segment Routing IPv6 dataplane as described in [I-D.ietf-spring-segment-routing]. The Label-Index and Originator SRGB TLVs MUST be ignored on reception. For future extensibility, no TLVs are required for the BGP IPv6 unicast address family. However, a BGP Prefix-SID attribute corresponding to the BGP IPv6 address family without an IPv6 SID TLV - MUST be ignored. + SHOULD be ignored. 5. Advertising BGP Prefix-SID Attribute The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760]. In order to prevent distribution of the BGP Prefix-SID attribute beyond its intended scope of applicability, attribute filtering SHOULD be - deployed. + deployed to remove the BGP Prefix-SID attribute at the adminstrative + boundary of the segment routing domain. A BGP speaker that advertises a path received from one of its neighbors SHOULD advertise the BGP Prefix-SID received with the path without modification, as long as the BGP Prefix-SID was acceptable. If the path did not come with a BGP Prefix-SID attribute, the speaker MAY attach a BGP Prefix-SID to the path if configured to do so. The content of the TLVs present in the BGP Prefix-SID is determined by the configuration. 5.1. MPLS Dataplane: Labeled Unicast @@ -510,21 +511,21 @@ In all cases, the label field of the advertised NLRI ([RFC8277], [RFC4364]) MUST be set to the local/incoming label programmed in the MPLS dataplane for the given advertised prefix. If the prefix is associated with one of the BGP speaker's interfaces, this is the usual MPLS label (such as the Implicit or Explicit NULL label). 5.2. IPv6 Dataplane A BGP speaker that originates an IPv6 prefix with the BGP Prefix-SID - attribute MAY include the IPv6 SID TLV. + attribute SHOULD include the IPv6 SID TLV. 6. Error Handling of BGP Prefix-SID Attribute When a BGP Speaker receives a BGP Update message containing a malformed or unacceptable BGP Prefix-SID attribute attached to a Labeled IPv4/IPv6 unicast prefix [RFC8277], it MUST ignore the received BGP Prefix-SID attributes and not advertise it to other BGP peers. This is equivalent to the "Attribute discard" action specified in [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an error for further analysis. @@ -612,29 +613,38 @@ case, the BGP Prefix-SID advertisement is applicable to the inter-AS context, i.e., EBGP, while it is confined to a single administrative domain. 9. Security Considerations This document introduces a BGP attribute (BGP Prefix-SID) which inherits the security considerations expressed in: [RFC4271], [RFC8277], and [I-D.ietf-spring-segment-routing]. + When advertised using BGPsec as described in [RFC8205], the BGP + Prefix-SID attribute doesn't impose any unique security + considerations. + It should be noted that, as described in Section 8, this document refers to a deployment model where all nodes are under the single administrative domain. In this context, we assume that the operator doesn't want to leak any information related to internal prefixes and topology outside of the administrative domain. The internal information includes the BGP Prefix-SID. In order to prevent such leaking, the standard BGP mechanisms (filters) are applied at the boundary of the SR/administrative domain. + To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service + (DDoS) attack due to excessive BGP updates with an unacceptable BGP + Prefix-SID attribute, message rate-limiting as well as suppression of + duplicate messages SHOULD be deployed. + 10. Contributors Keyur Patel Arrcus, Inc. US Email: Keyur@arrcus.com Saikat Ray Unaffiliated @@ -647,22 +657,22 @@ The authors would like to thank Satya Mohanty for his contribution to this document. The authors would like to thank Alvaro Retana for substantive comments as part of the Routing AD review. The authors would like to thank Shyam Sethuram for comments and discussion of TLV processing and validation. The authors would like to thank Peter Yee, Tony Przygienda, Mirja - Kuehlewind, and Alexey Melnikov for IETF last call directorate and - IESG reviews. + Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, and + Warren Kumari for IETF Last Call directorate and IESG reviews. 12. References 12.1. Normative References [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. @@ -694,20 +704,24 @@ [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . + [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol + Specification", RFC 8205, DOI 10.17487/RFC8205, September + 2017, . + [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, . 12.2. Informative References [I-D.ietf-idr-bgp-ls-segment-routing-ext] Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., and M. Chen, "BGP Link-State extensions for Segment Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-04