Network Working Group Keyur Patel Internet Draft Cisco Systems Expiration Date: August 2007 Susan Hares Nexthop Technologies Aspath Based Outbound Route Filter for BGP-4 draft-ietf-idr-aspath-orf-09.txt 1. Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is an individual submission. Comments are solicited and should be addressed to the author(s). Copyright Notice Copyright (C) The IETF Trust (2007). 2. Abstract This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. Patel, Hares [Page 1] Internet Draft draft-ietf-idr-aspath-orf-09.txt Febuary 2007 3. Introduction The Cooperative Outbound Route Filtering Capability defined in [BGP- ORF] 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 Aspath based route filtering. The Aspath ORF supports Aspath route filtering as well as the regular expression based matching for address groups. 4. Aspath ORF-Type The Aspath ORF-Type allows one to express ORFs in terms of regular expression and aspath numbers. That is, it provides aspath based route filtering, including regular expression based matching. Conceptually an Aspath ORF entry consists of the fields . 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 aspath regular expression string. The "Aspath" field contains an aspath 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 boundry. Note that the value of trailing bits is irrelevant. Patel, Hares [Page 2] Internet Draft draft-ietf-idr-aspath-orf-09.txt Febuary 2007 5. Aspath ORF Encoding The value of the ORF-Type for the Aspath ORF-Type is . An Aspath ORF entry is encoded as follows. The "Match" field of the entry is encoded in the "Match" field of the common part [BGP-ORF], 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 that the Aspath field is varibale length hexadecimal string whose length is defined by Length field. Patel, Hares [Page 3] Internet Draft draft-ietf-idr-aspath-orf-09.txt Febuary 2007 6. Capability Specification for Cooperative route filtering with ASpath As specified in the Coperative Router filtering draft [draft-ietf-idr-route-filter-05.txt], 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 [BGP-CAP] 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 Network Layer protocol associated with the Network Address that follows. Presently defined values for this field are specified in RFC1700 (see the Address Family Numbers section). 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 Where KKK is a 3 bit field reserved for future expansion of regular expression differences in ORF. Where FFF indicates 3 bits. Bit 0 is the left most bit, Bit 1 is the middle bit and Bit 2 is the right most bit. bit 0 - anchors 0 - full length regex, ie: implicit anchoring of AsPath as in ^AsPath$ 1 - partial as-path regex with anchoring. ie: the regex may or may not have anchors and thus may be a partial match. eg: anchoring non-anchoring ^X -> X .* ^X$ -> X X -> .* X .* bit 1 - "." wildcard operator [Collating Element] 0 - traditional application of "." as wildcard, ie: "." matches any single character of the set [0-9 ]. 1 - "." matches an AS-path token/term, regex "." == traditional regex "[0-9]+" bit 2 - "[]" operator 0 - not supported. 1 - supported, eg: [0-9] 7. Aspath ORF Matching In addition to the general matching rules defined in [BGP-ORF], 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 Aspath regular expressions to the its (receiver's) interpretation of regular expressions as indicated in the capability announcement. Patel, Hares [Page 4] Internet Draft draft-ietf-idr-aspath-orf-09.txt Febuary 2007 7. Security Considerations This extension to BGP does not change the underlying security issues. 8. Acknowledgements We express our thanks to Andrew Partan, Avneesh Sachdev, Alec Peterson, Enke Chen, John Heasley, Dorian Kim and Bruce Cole for their comments. 9. References [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- 4)", RFC 1771, March 1995. [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering Capability for BGP-4", draft-ietf-idr-route-filter-05.txt, January 2002. 10. Author Information Keyur Patel Cisco Systems 510 McCarthy Blvd Milpitas, CA 95035 email: keyupate@cisco.com Susan Hares NextHop Technologies. Inc. 517 W. Williams Ann Arbor, MI 48103-4943 email: skh@nexthop.com 11. Full Copyright Notice Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.