BGP Extended Community
for Identifying the Target NodesHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinajie.dong@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinazhuangshunwan@huawei.comNokiaAntwerpBEgunter.van_de_velde@nokia.comBGP 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 particular group of BGP nodes in the network.
Currently BGP does not have a generic mechanism of designating the
target nodes of the routing information. This document defines a new
type of BGP Extended Community called "Node Target". The mechanism of
using the Node Target Extended Community to steer BGP route distribution
to particular BGP nodes is specified.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 the resources on nodes
which do not need that information.Currently BGP does not have a generic mechanism of designating 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 or 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 VPN route to VRF import 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". The mechanism of using the Node Target extended community
to control the BGP route distribution only to particular BGP nodes is
also specified.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 TBA.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 some 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 the
Node Target extended communities, and attach the Node Target extended
communities to the routes or policies to be advertised.When a BGP speaker receives a BGP Update which contains one or more
Node Target extended communities, it MUST check the target BGP
Identifiers carried in the Node Target extended communities of the
Update.If the target BGP Identifier in any of the Node Target extended
community matches with the local BGP Identifier, this node is one of
the target nodes of the Update, the information in the Update is
eligible to be kept and installed on this node.If this node is a Route Reflector, and in the Update there is
one or more Node Target extended communities which contains
non-local BGP Identifiers, information in the Update are
eligible be reflected to its peers according to the rules
defined in . The default behavior for
the RR in this case is to reflect the Update to all its peers
without checking their BGP Identifiers. Depends on a
configurable policy, the RR MAY further check the BGP
Identifiers of its peers to determine the set of peers which are
the target nodes of the Update, and only reflect the information
in the Update to the matched BGP peers. If this node is an Autonomous System Border Router (ASBR),
and the BGP Identifiers of one or more of its EBGP peers match
with the Node Target extended communities in the Update,
information in the Update is eligible to be advertised to the
matched EBGP peers.If the target BGP Identifier in any of the Node target extended
community does not match with the local BGP Identifier, this node is
not the target node of Update, the information in the Update is not
eligible to be installed on this node.If this node is a Route Reflector, information in the Update
is eligible to be reflected to its peers according to the rules
defined in . The default behavior for
the RR in this case is to reflect the Update to all its peers
without checking their BGP Identifiers. Depends on a
configurable policy, the RR MAY check the BGP Identifiers of its
peers to determine the set of peers which are the target nodes
of the Update, and only reflect the information in the Update to
the matched BGP peers. The Node Target extended community introduced in this document can be
deployed incrementally in the network. For BGP speakers which understand
the Node Target extended community, it is used to determine whether the
nodes are the target nodes of the Update. For BGP speakers which do not
understand the Node Target extended community, it will be ignored and
the information in the Update will be processed and advertised based on
normal BGP procedure. Although this could ensure that the target nodes
can always obtain the information needed, this may result in unnecessary
state maintained on the legacy BGP nodes. If the information advertised
is the Flow Spec rules, the legacy BGP speakers may install unnecessary
Flowspec rules, this may have impact on traffic which matches such
rules, thus may result in unexpected traffic steering or filtering
behaviors on such nodes. This may be mitigated by setting appropriate
routing policies on the legacy BGP nodes.This document requests that IANA assigns one new sub-type for "Node
Target Extended Community" from the "Transitive IPv4-Address-Specific
Extended Community" registry of the "BGP Extended Communities"
registry.This document requests that IANA assigns the same sub-type for "Node
Target Extended Community" from the "Non-Transitive
IPv4-Address-Specific Extended Community" 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 would potentially 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. 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.