Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS)Microsoftjefftant.ietf@gmail.comHuaweiYuhua District101 Software AvenueNanjingJiangsu210012Chinawangzitao@huawei.comHuaweiYuhua District101 Software AvenueNanjingJiangsu210012Chinabill.wu@huawei.comCisco Systemsketant@cisco.com
Routing Area
IDR Working GroupInter-Domain RoutingAdministrative groups are link attributes used for traffic
engineering. This document defines an extension to the Border Gateway Protocol -
Link State (BGP-LS) for advertisement of extended administrative groups (EAGs).Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 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
() 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
. Introduction
. Requirements Language
. Advertising Extended Administrative Groups in BGP-LS
. IANA Considerations
. Manageability Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
IntroductionAdministrative groups (commonly referred to as "colors" or "link colors")
are link attributes that are advertised by link-state protocols like IS-IS , OSPFv2 , and OSPFv3 .
The Border Gateway Protocol - Link State (BGP-LS) advertisement of the originally defined (non-extended) administrative groups is encoded
using the Administrative Group (color) TLV 1088 as defined in .These administrative groups are defined as a fixed-length 32-bit
bitmask. As networks grew and more use cases were introduced, the 32-bit
length was found to be constraining, and hence extended administrative
groups (EAGs) were introduced in .The EAG TLV () is not a replacement for the Administrative
Group (color) TLV; as explained in , both values can coexist.
It is out of scope for this document to specify the behavior of the
BGP-LS consumer . This document specifies an extension to BGP-LS for advertisement of the
extended administrative groups.Requirements LanguageThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL",
"SHALL NOT", "SHOULD",
"SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.Advertising Extended Administrative Groups in BGP-LSThis document defines an extension that enables BGP-LS speakers to
signal the EAG of links in a network to a BGP-LS consumer of network
topology such as a centralized controller. The centralized controller
can leverage this information in traffic engineering computations and
other use cases. When a BGP-LS speaker is originating the topology
learned via link-state routing protocols like OSPF or IS-IS, the EAG
information of the links is sourced from the underlying extensions as
defined in .The EAG of a link is encoded in a new Link Attribute TLV using the following format:Extended Administrative Group TLV Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Administrative Group (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Type:
1173
Length:
variable length that represents the total length of the value field in octets.
The length value MUST be a multiple of 4. If the length is not a multiple of 4, the TLV MUST be considered malformed.
Value:
one or more sets of 32-bit bitmasks that indicate the
administrative groups (colors) that are enabled on the link when
those specific bits are set.
IANA ConsiderationsIANA has assigned a code point from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry as described in the following table.
Code Point
Description
IS-IS TLV/Sub-TLV
1173
Extended Administrative Group
22/14
Manageability ConsiderationsThe new protocol extensions introduced in this document augment the
existing IGP topology information that is distributed via . Procedures and protocol extensions defined in this
document do not affect the BGP protocol operations and management other
than as discussed in Section "Manageability Considerations" of . Specifically, the tests for malformed attributes, to perform
syntactic checks as described in Section "Fault Management" of , now encompass the new BGP-LS Attribute TLV defined
in this document. The semantic or content checking for the TLV
specified in this document and its association with the BGP-LS Network Layer Reachability Information (NLRI)
types or its BGP-LS Attribute are left to the consumer of the BGP-LS
information (e.g., an application or a controller) and not to BGP itself.A consumer of the BGP-LS information retrieves this information over
a BGP-LS session (refer to Sections and of ).Security ConsiderationsThe procedures and protocol extensions defined in this document do not
affect the BGP security model. See the "Security Considerations" section of
for a discussion of BGP security.
This document only introduces a new Attribute TLV, and any syntactic
error in it would result in the BGP-LS Attribute being discarded .
Also, refer to and for analyses of security issues for BGP.
Security considerations for acquiring and distributing BGP-LS information are discussed in .
The TLV introduced in this document is used to propagate the EAG
extensions defined in .
It is assumed that the IGP instances originating this TLV will support any required security mechanisms for OSPF and IS-IS, in order to prevent any security
issues when propagating the Sub-TLVs into BGP-LS.Security concerns for OSPF are addressed in , , and .
Further security analysis for the OSPF protocol is done in .Security considerations for IS-IS are specified by .The advertisement of the link attribute information defined in this
document presents no significant additional risk beyond that associated with the
existing link attribute information already supported in .ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGPIn a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesUse of OSI IS-IS for routing in TCP/IP and dual environmentsThis memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]OSPF Version 2This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]A Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]BGP Security Vulnerabilities AnalysisBorder Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.Authentication/Confidentiality for OSPFv3This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]IS-IS Cryptographic AuthenticationThis document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]OSPF for IPv6This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design GuideThis document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design GuideThis document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.Supporting Authentication Trailer for OSPFv3Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.Security Extension for OSPFv2 When Using Manual Key ManagementThe current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.AcknowledgmentsThe authors would like to thank , , , , and for their reviews and valuable comments.Authors' AddressesMicrosoftjefftant.ietf@gmail.comHuaweiYuhua District101 Software AvenueNanjingJiangsu210012Chinawangzitao@huawei.comHuaweiYuhua District101 Software AvenueNanjingJiangsu210012Chinabill.wu@huawei.comCisco Systemsketant@cisco.com