BGP Extended Community for Identifying the Target Nodes

BGP has been used to distribute different types of routing and policy information. In some cases, the information distributed may be only intended for one or a group of receiving BGP nodes in the network. One typical use case is the distribution of BGP Flow Spec rules only to a particular group of BGP nodes. Such a targeted distribution mechanism is considered useful as it can save resource on nodes which do not need that information. Currently BGP does not have a generic mechanism to designate the set of nodes to which the information is to be distributed. Route Target (RT) as defined in was designed for the matching of VPN routes into the target VPN Routing and Forwarding tables (VRFs) on the PE nodes. introduces the mechanism of steering the SR Policy information to the target head end node based on RT, it is only applicable to the SR Policy Address Family. Although it is possible to reuse RT to control the distribution of non-VPN information to one or a group of receiving nodes, such mechanism is not applicable when the information to be distributed is VPN-specific and is advertised with another set of RTs for the VRF matching, as the matching of any of the VPN RT in the BGP route would result in that route being imported to a local VRF, regardless of whether the receiving node is the target node or not. Thus a general mechanism which is independent from the control of importing VPN routes to VRFs is needed. Another possible approach is to configure, on each router, a community and the corresponding policies to match the community to determine whether to accept the received routes or not. Such mechanism relies on manual configuration thus is considered error-prone. It is preferable by some operators that an automatic approach can be provided, which would make the operation much easier. This document defines a new type of BGP Extended Community called "Node Target". It can be used by a receiving BGP node to determine whether it is the target of the BGP information.

The 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.

This section defines a new BGP Extended Community called "Node Target Extended Community". It can be a transitive extended community with the high-order octet of the type set to 0x01, or a non-transitive extended community with the high-order octet type set to 0x41. The sub-type of the Node Target Extended Community is 0x09. The format of Node Target Extended Community is shown in Figure 1.

Where: Target BGP Identifier (4 octets): The BGP Identifier of a target node. It is a 4-octet, unsigned, non-zero integer as defined in . Reserved field (2 octets): Reserved for future use, MUST be set to zero on transmission and ignored on receipt. One or more Node Target extended communities MAY be carried in an Update message to designate a group of target BGP nodes.

In this section, the mechanism for intra-domain scenario is described, the mechanism for inter-domain scenario is for further study. The domain here refers to an administrative domain, which may consists of one or multiple ASes managed by a single operator. When a network controller or BGP speaker plans to advertise BGP routing or policy information only to one or a group of BGP nodes in the network, it MUST put the BGP Identifier of each target node into a list of Node Target extended communities, and attach the Node Target extended communities to the BGP Update to be advertised. Duplicated BGP identifiers MUST NOT be carried in the Node Target extended communities of a BGP Update. When a BGP speaker receives a BGP Update which contains one or more Node Target extended communities, it MUST check the BGP Identifiers carried in the Node Target extended communities of the Update. An invalid BGP Identifier (e.g. 0.0.0.0) received in Node Target Extended Communities MUST be ignored on receipt and SHOULD be logged. If multiple Node Target extended communities in an Update carry the same BGP Identifier, the receiver SHOULD treat them as a single occurrence of that target. Duplicate occurrences have no additional meaning and SHOULD be silently ignored. If any of the Target BGP Identifiers in the Node Target extended communities matches the local BGP Identifier, this node is one of the target nodes of the Update, information in the Update is eligible for installation on this node. If none of the Target BGP Identifiers in the Node Target extended communities matches with the local BGP Identifier, this node is not among the target nodes of the Update, information in the UPDATE MAY still be accepted by the BGP speaker (e.g. stored in Adj-RIB-In), but it MUST NOT be installed locally in the RIB/FIB/ACL etc. of this node, and MUST NOT be advertised further to other nodes. Routing information that is not targeted to this node SHOULD still be observable for diagnostic purposes, this can be done by an indication that the route does not pass the Node Target check , together with the Node Target extended communities received. A counter of routes not passing the node-target check SHOULD also be kept. The specific storage location is implementation-dependent. FlowSpec is a motivating use case for this mechanism. When a FlowSpec NLRI carries Node Target extended communities, the Node Target check SHOULD be applied before the validation procedure defined in . The mechanism of using Node Target extended community to control the BGP route distribution only to particular BGP nodes is out of the scope and will be specified in a separate document.

An operator who is responsible for the administration of one or multiple ASes need to ensure each BGP speaker in the network is assigned with a unique BGP Identifier. The Node Target extended communities may be originated by a network controller or a BGP speaker, In order to construct the list of node targets, an inventory of the BGP Identifiers of the target nodes in the domain MUST be maintained. The mechanism used to obtain and update such inventory is out of the scope of this document. Operators are expected to derive it from their existing inventory, orchestration, or configuration management systems.. Each node target consumes an 8-octet extended community, and targets are enumerated individually. A large group of node target extended communities therefore adds substantially to the size of the Update. Operators SHOULD keep the target groups to a practical size, and SHOULD consider whether a small set of target nodes can meet the deployment need. Implementations MAY impose a local limit on the number of Node Target extended communities per Update. The Node Target extended community can be deployed incrementally. BGP speakers that do not understand it ignore it and process the Update according to normal BGP procedures. This ensures target nodes obtain the information they need, but may also result in unnecessary state on legacy nodes. If the information is FlowSpec, legacy speakers may install unnecessary FlowSpec rules, potentially affecting traffic that matches those rules. This may be mitigated by setting appropriate routing policies on the legacy BGP nodes. Operators should be aware of this requirement during the migration.

Per the early allocation process, IANA has assigned the sub-type value 0x09 for "Node Target Extended Community" from the "Transitive IPv4-Address-Specific Extended Community Sub-Types" registry of the "BGP Extended Communities" registry. Per the early allocation process, IANA has assigned the sub-type value 0x09 for "Node Target Extended Community" from the "Non-Transitive IPv4-Address-Specific Extended Community Sub-Types" registry of the "BGP Extended Communities" registry.

The mechanism defined in this document can limit the scope of the receiving nodes of BGP Updates, which make it possible for an attacker to do fine-grained targeting of malicious BGP Updates only to a restricted set of routers. This may make it more difficult for a network administrator to discover an attack. This may be mitigated by filtering the Node Target extended communities at the administrative network boundaries. A misconfigured or injected Node Target extended community could suppress route installation across an entire administrative domain without generating any protocol error. Operators should treat target lists as security-sensitive configuration.

The authors would like to thank Zhenbin Li, Ercin Torun, Jeff Haas, Robert Raszuk and John Scudder for the review and discussion of this document.