Analysis of Existing work for I2NSF

The Cooperative Outbound Route Filtering Capability defined in provides a mechanism for a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that can be used by its peer to filter its outbound routing updates to the speaker. This documents defines a new ORF-type for BGP, termed "ASpath Outbound Route Filter (ASpath ORF)", that can be used to perform AS Path based route filtering. The ASpath ORF supports AS path route filtering as well as the regular expression based matching for address groups.

The ASpath ORF-Type allows one to express ORFs in terms of regular expression and AS path numbers. That is, it provides AS path based route filtering, including regular expression based matching. Conceptually an ASpath ORF entry consists of the fields <Sequence, Match, Length, Aspath>. The "Sequence" field is a number that specifies the relative ordering of the entry. The "Match" field specifies whether this entry is "PERMIT" (value 0), or "DENY" (value 1). The "Length" field indicates the length of AS path regular expression string. The "aspath" field contains an AS path regular expression of an address group. The field "Sequence" is an unsigned 32 bit value. The field "Length" is an unsigned 16 bit value. The field "aspath" is a variable length hexadecimal string. The field "aspath" will be followed by enough trailing bits to make end of field fall on an octet boundary. Note that the value of trailing bits is irrelevant.

The value of the ORF-Type for the ASpath ORF-Type is <TBD>. An ASpath ORF entry is encoded as follows. The "Match" field of the entry is encoded in the "Match" field of the common part , and the remaining fields of the entry is encoded in the "Type specific part" as follows:

+--------------------------------+ | Sequence (4 octets) | +--------------------------------+ | Length (2 octet) | +--------------------------------+ | Aspath ( variable length) | +--------------------------------+ Note the aspath is a variable length hexadecimal string whose length is defined by Length field.

As specified in Cooperative Route Filter, a BGP speaker that is willing to receive ORF entries from its peer, or a BGP speaker that would like to send ORF entries to its peer advertises this to the peer by using the Cooperative Route Filtering Capability uses a new BGP capability defined as follows: Capability code: 3 Capability length: variable Capability value: one or more of the following entries:

+--------------------------------------------------+ | Address Family Identifier (2 octets) | +--------------------------------------------------+ | Reserved (1 octet) | +--------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +--------------------------------------------------+ | Number of ORFs (1 octet) | +--------------------------------------------------+ | ORF Type (1 octet) | +--------------------------------------------------+ | Send/Receive (1 octet) | +--------------------------------------------------+ | ... | +--------------------------------------------------+ | ORF Type (1 octet) | +--------------------------------------------------+ | Send/Receive (1 octet) | +--------------------------------------------------+ Fig 4. Capability encoding The use and meaning of these fields are as follows: Address Family Identifier (AFI) This field carries the identity of the address family for the Network Layer protocol associated with the Network Address that follows. Subsequent Address Family Identifier (SAFI): This field provides additional information about the type of the Network Layer Reachability Information carried in the attribute. Number of ORF Types This field contains the number of Filter Types to be listed in the following fields. ORF Type This field contains the value of an ORF Type. Send/Receive This field indicates whether the sender is (a) willing to receive ORF entries from its peer (value 1), (b) would like to send ORF entries to its peer (value 2), or (c) both (value 3) for the ORF Type that follows. In the upper bits of the Send/Receive byte the top three bits have the following encoding: [FFFKKKSR] where bit 0 is the left most bit. where: S = Send ORF for ASpath R = Receive ORF for ASpath KKK = a 3 bit field reserved for future expansion of regular expression differences in ORF. FFF = 3 bits. Bit 0 is the left most bit, and indicates anchoring status. Bit 0 = 0 - implies full length regular express (regex), that is implicit anchoring of ASPath as in "^ASPath$" anchoring--non-anchoring ^X --------> X .* ^X$ --------> X X -----------> .* X .* Bit 0 = 1 - implies partial aspath regex, regex may or may not have anchors Bit 1 is the middle bit, and it is the "." wildcard operator. [Collating Element] Bit 1 = 0 -- indicates traditional application of "." as wildcard, ie: "." matches any single character of the set [0-9 ]. Bit 1 = 1 -- indicates "." matches an AS-path token/term, regex "." == traditional regex "[0-9]+" Bit 2 is the right most bit, and indicates the "[]" operator where: Bit 2 = 0 - indicates not supported Bit 2 = 1 - indicates support, e.g. [0-9]

In addition to the general matching rules defined in , several ASpath ORF specific matching rules are defined as follows. It is possible that the speaker would have more than one ASpath ORF entry that matches the route. In that case the "first-match" rule applies. That is, the ORF entry with the smallest sequence number among all the matching ORF entries) is considered as the sole match, and it would determine whether the route should be advertised. If any speaker does not support capabilities specified by the receiver but still decide to establish the connection, the receiver is expected to translate the AS path regular expressions to the its (receiver's) interpretation of regular expressions as indicated in the capability announcement.

ORFs provide information that guides future sending, but any malformed ORF is simply missed filtering information. If ASpath ORF is malformed, the attribute shall simply be discarded.

This extension to BGP does not change the underlying security issues.

We express our thanks to Andrew Partan, Avneesh Sachdev, Alec Peterson, Enke Chen, John Heasley, Dorian Kim and Bruce Cole for their comments.

No IANA exist for this document.

No security considerations are involved with a gap analysis.