Network Working Group James Ng Internet Draft (editor) Expiration Date: June 2003 Cisco Systems File Name: draft-ng-sobgp-bgp-extensions-01.txt June 2003 Extensions to BGP to Support Secure Origin BGP (soBGP) draft-ng-sobgp-bgp-extensions-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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. 1. Contributors A large number of people contributed to or provided valuable feedback on this document; we've tried to include all of them here (in no particular order), but might have missed a few: Russ White, Alvaro Retana, Dave Cook, John Scudder, David Ward, Martin Djernaes, Chris Lonvick, Brian Weiss, Tim Gage, Scott Fanning, Barry Friedman, Jim Duncan, Yi Yang, Robert Adams, Tony Tauber, Iljitsch van Beijnum, and Jonathan Natale. Ng, et al. [Page 1]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 2. Abstract There is a great deal of concern over the security of routing systems within the Internet, particularly in relation to the Border Gateway Protocol [BGP], which is used to provide routing information between autonomous systems. This document proposes a system where the origin of any advertisement within BGP can be verified and authenticated, preventing the advertisement of prefix blocks by unauthorized networks, and verifying that the final destination in the path is actually within the autonomous system to which the packets are being routed. This document does not: o Attempt to provide information on how such a security system could or should be deployed; readers are referenced to [SOBGP- DEPLOY] for this discussion. o Attempt to determine what sorts of keys should be used within such a system, nor how any sort of trust relationship can or should be built between the entities cooperating within the routing system. These are considered in [SOBGP-CERTIFICATE]. o Attempt to analyse the performance, memory utilization, or other impacts on devices running this protocol; these are addressed in [SOBGP-DEPLOY]. o Attempt to analyse the security protection provided by the pro- posed security system. Readers are referred to [SOBGP-ANALYSIS]. This document primarily focuses on extensions to the BGP protocol itself to support such a security system. This document is to solve several vulnerabilities within a BGP routing system given the follow- ing constraints and assumptions: o Any signalling which must take place to provide security should be specified in as flexible a way as possible. For instance, any certificates exchanged may be solely contained with the BGP pro- tocol, or through some other transport/distribution mechanism. [SOBGP-DEPLOY] contains more discussion on this issue. o The proposed solution should be incrementally deployable, and require minimal changes in a network to support it (software changes only along the path where support is required, for instance). o The proposed solution should not rely on the routing system it is securing to reach information necessary to secure the routing Ng, et al. [Page 2]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 system (reliance on an IGP to reach destinations within a rout- ing domain is acceptable, but reliance on BGP to reach destina- tions outside the routing domain is unacceptable). o The operator may configure various levels of trust, preferring faster convergence over security validtion, or more immediate and stronger security validation over convergence times. o All routing information received from peering relationships within an autonomous system is implicitly trusted. o No current optimizations in implementations of the BGP protocol should be affected, if possible. It's important to note that any given security system is a tradeoff between several factors, including the actual security provided and the difficulty entailed in deploying the system; different solutions may provide different levels of protection between these, leaving some parts of the problem unsolved. This proposal does not protect against: o Attacks through all forms of autonomous system spoofing. This proposal can be subverted if an attacker is able to masquerade as an autonomous system under some network conditions. It is assumed that management of inter-AS connections and policy implementation can resolve these possible attacks. o Path Authentication. While this system allows the path any given update advertises to be checked against paths known to be valid, it does not ensure this particular update provides the best path. It is observed that there are many possible valid paths within a BGP routing system, and BGP itself is designed to find the correct path among the possible paths. o Authentication of path attributes, such as the community and MED attributes passed with a prefix. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this docu- ment. For more information consult the online list of claimed rights. Ng, et al. [Page 3]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 3. Definitions o Entity: A participant in the internetwork routing system. 4. The Security Message This document proposes a new message type, the SECURITY message, which is to be used for carrying security information within the BGP protocol. The SECURITY message is type 6. The SECURITY message is used to transport the certificates described in [SOBGP-CERTIFICATE]. 4.1. Negotiating Security Capability The ability to exchange SECURITY messages shall be negotiated at ses- sion startup, as described in [CAPABILITY]. The capability code is <to be assigned by IANA>. A pair of BGP speakers MAY negotiate to send messages in the SECURITY message type only (exchange no NLRI or forwarding information). If two BGP speakers have negotiated to exchange SECURITY messages, they should exchange the certificates contained in their local data- bases after having exchanged NLRI information, unless they have nego- tiated otherwise in the security option exchange. If two speakers have negotiated to exchange SECURITY messages a secu- rity option exchange must precede any other message exchange (NLRI information, other security messages etc.). The security option exchange is initiated, from both sides, with a SECURITY Option Requestmessage and not finished before a SECURITY Option ACK Message is received from the peer. 4.2. The Security Message Format The SECURITY message is formatted as described in [BGP], with a type code of 6. Within each message is a series of TLVs, or security mes- sage blocks, formatted as: 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 | +-------------------------------+-------------------------------+ | Data | +--------- Ng, et al. [Page 4]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 o Type: A two octet unsigned integer describing the type of infor- mation contained within the data field. o Length: A two octet unsigned integer describing the length of the data field, in octets. o Data: The data, as described within this and other documents which describe information to be carried within the SECURITY message type. Four TLVs are currently defined within the SECURITY message. Further TLVs are defined for carrying certificates in [SOBGP- CERTIFICATE]. 4.3. Security Option exchange When the Security Capability in BGP have been negotiated no other message exchange may happen until a full SECURITY Option exchange have been completed. The security option exchange is present to negotiate special security behaviors which should be used for the current session, which is also the reason why it must precede all other types of message exchange (e.g. NLRI information, other SECURITY Messages etc.). If the SECU- RITY Option exchange can not be completed successfully a NOTIFICATION message[BGP] send to the peer with an Error Code of <to be deter- mined> (SECURITY Message Error) and with the subcode 1 (Failed Option Exchange) and the session must be termintated. A SECURITY Option exchange must be initiated from both sides, by by sending A SECURITY Option Request message, including a list op options which should apply on the current session. If a speaker do not request SECURITY Options it must send an empty list to the peer. If a receiver can not accept one or more of the options listed in the SECURIY Option Request Message it must compile a list of rejected and/or unrecognized options and send them back in a SECURITY Option NAK Message. If the received SECURITY Option Request Message only contain options which can be supported by the receiver it must respond with a SECURITY Option ACK Message and apply the options to the current session. If the BGP session is closed it must decease using the options. Ng, et al. [Page 5]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 4.3.1. The SECURITY Option Codes SECURITY Option Codes are 1 octet long well known values and defined as following: o 0x01: Would like to receive SECURITY information before NLRI information. This option code MUST NOT be included with option code 0x02. o 0x02: Will only accept validated certificates of any type on this session (only valid for iBGP sessions). This option code MUST NOT be included with option code 0x01. 4.3.2. The SECURITY Option Request TLV The SECURITY Option Request TLV provides a way for exchanging speak- ers to inform their peers about local configurations which may per- tain to the peering session. SECURITY Option Request TLVs are encap- sulated within a TLV Type 1, and transmitted within the SECURITY mes- sage type. If SECURITY Option Request TLVs are transmitted, they MUST be transmitted before the transmission of any other SECURITY data. 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 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Options | +---------------------------------------------------------------+ o TLV type: (2 octets), 1 o Length: (2 octets), Length, in octets, of the option field. o Options: (variable length) A list of Option Codes used to request/inform the peer about options to be used on the current session. 4.3.3. The SECURITY Option NAK TLV The SECURITY Option NAK TLV provides negative feedback from a peer which previously have received an SECURITY Options Request message. 0 1 2 3 Ng, et al. [Page 6]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 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 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Options | +---------------------------------------------------------------+ o TLV type: (2 octets), 2 o Length: (2 octets), Length, in octets, of the option field. o Options: (variable length) A list of Option Codes, which were present in the previously received SECURITY Option Request Mes- sage, but not accepted and/or recognized by the speaker. 4.3.4. The SECURITY Option ACK TLV The SECURITY Option ACK TLV provides positive feedback from a peer which previously have received an SECURITY Options Request message. 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 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ o TLV type: (2 octets), 3 o Length: (2 octets), set to 0. 4.3.5. The Request TLV 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 +-------------------------------+-------------------------------+ | TLV Type | Request Type | +-------------------------------+-------------------------------+ | Length | Reserved | +-------------------------------+-------------------------------+ | Request Indicator SubTV | +--------------------------- o TLV type: (2 octets), 4 o Request Type: (2 octets), treated as an unsigned integer indi- cating the type of the type of information requested. Ng, et al. [Page 7]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 o Length: (2 octets), set to the total length of the request in octets. o Reserved: (2 octets), set to 0x0000. o Request Indicator: The information indicated by the request type bit field. The Request Type field indicates the type of certificates requested. Three request types are defined in this document. 1 Any certificate matching the Request Indicator are requested. 2 EntityCerts matching the Request Indicator are requested. 3 ASPolicyCerts matching the Request Indicator are requested. 4 PrefixPolicyCerts matching the Request Indicator are requested. Request indicator SubTVs restrict the set of certificates returned; there may be one or more request indicator SubTVs included in a request. Each SubTV consists of a two octet type field, treated as an unsigned integer, and a fixed length field containing the request indicator. o Type 1: A four octet origin/authorized AS Number; two octet AS numbers shall be right justified within this field (placed in the two least significant octets). o Type 2: A four octet signer/authorizer AS Number; two octet AS numbers shall be right justified within this field (placed in the two least significant octets). o Type 3: A four octet IPv4 address is included in the request indicator. o Type 4: A sixteen octet IPv6 address is included in the request indicator. o Type 5: An eight octet starting serial number is included in the request indicator. o Type 6: An eight octet ending serial number is included in the request indicator. Ng, et al. [Page 8]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 4.3.6. The EntityCert TLV 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 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | EntityCert | +--------------------------- o TLV type: (2 octets), 5 o Length: (2 octets), Length of the EntityCert, in octets o EntityCert: (variable length), EntityCert, as described in [SOBGP-CERT] 4.3.7. The ASPolicyCert TLV 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 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | ASPolicyCert | +--------------------------- o TLV type: (2 octets), 6 o Length: (2 octets), Length of the ASPolicyCert, in octets o EntityCert: (variable length), ASPolicyCert, as described in [SOBGP-CERT] 4.3.8. The PrefixPolicyCert TLV 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 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | PrefixPolicyCert | +--------------------------- o TLV type: (2 octets), 7 Ng, et al. [Page 9]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 o Length: (2 octets), Length of the PrefixPolicyCert, in octets o EntityCert: (variable length), PrefixPolicyCert, as described in [SOBGP-CERT] 5. Receiving and Processing SECURITY messages The sections below describe the receipt and processing of SECURITY messages. 5.1. The Level of Certificate Processing Each section below describes the processing of SECURITY messages based on the way in which soBGP is deployed on the BGP speaker. For more information on deployment options, see [SOBGP-DEPLOY]. 5.1.1. Full Local Certificate Processing If a BGP speaker is fully processing certificates locally, for each received certificate it must: o The unique identifiers (described for each certificate type in [SOBGP-CERTIFICATE] of any certificate received MUST be compared to the unique identifiers of certificates already held in local databases. Any certificate which matches a certificate already held in a local database MUST be discarded. o Certificates received from untrusted peers and certificates received without the VALIDATED bit set SHOULD be placed in a local certificate database, and processed according to [SOBGP- CERTIFICATE]. o Certificates received from iBGP peers which have negotiated trusted certificate exchange SHOULD placed in a local certifi- cate database, and processed as though they were all sucessfully validated according to the process described in [SOBGP- CERTIFICATE]. o ASPolicyCerts and PrefixPolicyCerts received and placed in the local certificate database, and marked as validated, SHOULD be readvertised to all iBGP peers which have a trusted peering relationship, marked as VALIDATED. EntityCerts SHOULD NOT be marked as trusted and readvertised along trusted peering rela- tionships. Ng, et al. [Page 10]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 o All certificates received and placed in the local certificate database, and not marked as validated, should be readvertised to trusted iBGP peers; they MUST not be marked as VALIDATED. o All certificates received and placed in the local certificate database should be readvertised to all BGP peers which have negotiated the untrusted exchange of soBGP certificates. 5.1.2. No Local Cryptographic Processing If a BGP speaker is accepting certificates only from trusted peering relationships, for each received certificate, it must: o The unique identifiers (described for each certificate type in [SOBGP-CERTIFICATE] of any certificate received MUST be compared to the unique identifiers of certificates already held in local databases. Any certificate which matches a certificate already held in a local database MUST be discarded. o Certificates received from iBGP peers which have negotiated trusted certificate exchange and marked as VALIDATED must be placed in a local certificate database, and processed as though they were all sucessfully validated according to the process described in [SOBGP-CERTIFICATE]. o Certificates received from any BGP peer which has not negotiated trusted certificate exchange, and any received certificate which is not marked as VALIDATED, should be readvertised to all BGP peers which have not negotiated trusted certificate exchange. These certificates MUST be discarded; they MUST NOT be stored locally. 5.1.3. No Local Certificate Processing If a BGP speaker is validating routing information through direct interaction with another device performing soBGP processing, and is not processing or storing certificates locally, for each soBGP certi- ficate received, it must readvertise all certificates received from any BGP peer to all other BGP peers which have negotiated soBGP cer- tificate exchange through the SECURITY message. The BGP speaker MUST NOT mark the readvertised certificates as VALIDATED. Ng, et al. [Page 11]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 5.2. Filtering of Certificates A BGP speaker may, for reasons of policy, filter soBGP certificates received from a peer. o If a BGP speaker is part of a transit AS, it SHOULD NOT filter soBGP certificates. o A BGP speaker MAY discard soBGP certificates which describe the authorization of address space which is being filtered out of the local routing information. 5.3. Receiving and Processing Requests If a device receives a Request TLV, as described in the section "The Security Message," above, it should: o Examine the request to ensure it is logically consistent. For instance, requesting an Entitycert based on an IPv4 address range is not logically consistent, since these certificates only contain an AS and a Signer AS. o If the request is not logically consistent, discard it. o If the request is logically consistent, examine its local data- bases, and transmit the certificates requested which fulfill the conditions supplied in the request indicator SubTVs. o If more than one of the same request indicator is included in a request message, they shall be treated as an OR condition; if any of the conditions match, the certificate shall match the set. 6. Operation and General Requirements This section discusses the processing of routing updates, validation of the AS_PATH contained in routing updates, general BGP requirements for autonomous systems running soBGP, and requirements for BGP ses- sions exchanging soBGP certificates. Ng, et al. [Page 12]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 6.1. Receiving and Validating Prefixes A local database of authorized prefix/origin AS/policy triples is built using the techniques described in [SOBGP-CERTIFICATE], and used to validate updates as they are received (or updates which exist in the AdjRIB-In), as described in this section. This local database is termed the "authorization database." Since one of the goals of soBGP, stated at the beginning of this document, is to impact the performance of the BGP protocol as little as possible, there is no requirement to perform the steps outlined in this section at any particular time in the processing of received BGP updates. The validation of routes received may occur as these routes are received, before they are placed in the Adj-RIB-In, periodically, or some time after convergence has been attained, as determined by configuration on the device validating the routes received. o The local authorization database is examined, and the entries with the longest prefix length which encompasses the range of addresses described by the prefix is chosen. o This set of entries is examined to determine if the route is originated from one of the AS' listed in the set of entries. o If the route is not originated from one of the AS' listed in the set of entries, the route is said to be invalid, and should be excluded from further consideration for installation in to the local RIB. o If the authorization database entry indicates the Second Hop must be checked, the second hop of the AS PATH should be veri- fied as described in the section "Verifying the Second Hop," below. If the second hop check fails, the route is said to be invalid, and should be removed from further consideration for installation into the local RIB. o If the authorization database indicates the AS_PATH of the update must be checked, the AS PATH of the route should be veri- fied, as described in the section "Verifying the AS PATH," below. If the AS_PATH is not validated, the route should be removed from further consideration for installation in the local RIB. o Other policies contained in the local authorization database should be applied as directed by the policy. o If there is no entry in the local authorization database which Ng, et al. [Page 13]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 encompasses the range of addresses described by the prefix, then the route is said to be unverified, and should be handled according to local policy (either discarded, or have its secu- rity preference lowered). 6.2. Aggregation Aggregation is a difficult problem with any method which attempts to verify the origin of any given prefix, since aggregation removes the relationship between prefixes originated and originators. Prefixes may only be aggregated by an entity which is otherwise authorized to advertise the aggregated prefix. 6.3. Verifying the Path In order to verify the path of any given advertisement, we propose to build a directed graph of all possible transit paths within the Internet, and verifying the path of each advertisement against this graph. Note that for any given prefix, this graph will contain a superset of all valid paths for the prefix. The BGP protocol itself is designed to choose the correct path out of the possible paths. In order to build the directed graph, each entity within the routing system may advertise the autonomous systems it is connected to using the attached AS' field carried in a certificate as described in [SOBGP-CERTIFICATE]. This graph is called the PATH database. 6.3.1. Building and Using the Directed Graph Each device verifying routing information it is receiving may build a directed graph from the information contained in the Policy Certifi- cate for each AS (as described above), which provides a list of all known valid paths through the internetwork. Each link between a pair of AS' may be verified from both ends of the link (using a two way connectivity check), thus ensuring that no single AS may advertise itself as connected to an entity it is not connected to. As routes are validated, the AS PATH contained in the route may be checked against the PATH database for congruence with a known good path. If the AS PATH traverses a link which cannot be verified to exist in both directions (the link fails the two way connectivity check), it's security preference may be lowered or the route may be discarded, as local device configuration directs. Ng, et al. [Page 14]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 6.4. Verifying the Second Hop As a prefix is processed by a receiving the device, the originator and second hop in the AS PATH may be checked against the authorized originator and the list of attached AS' advertised by that origina- tor. If the second hop in the AS path (the second entry in the AS PATH) does not match one of the attached AS' advertised by the origi- nator, the prefix should be treated as invalid, and discarded. 6.5. Requirements for Systems Running soBGP There are three general requirements imposed on autonomous system border routers and devices running soBGP: o Any peering session along the border of an autonomous system running soBGP SHOULD be authenticated through some means such as [BGP-MD5], IPsec ([ESP], [AH]), or through some other current, effective means of protecting BGP sessions from being hijacked, or otherwise abused. o Any peering session along which soBGP certificates are exchanged MUST be authenticated through some means such as [BGP-MD5], IPsec ([ESP, [AH]), or through some other current, effective means of protecting BGP sessions from being hijaaked, or other- wise abused. o The AS_PATH of any routing information received from any BGP peer outside the autonomous system MUST be checked to validate the next hop AS is the AS the update was received from. If the next hop AS in any received update does not match the configured AS the route is learned from, the update MUST be discarded. 7. The Security Preference As indicated in other sections of this document, the user has a wide range of flexibility when determining the level of security to be applied to each prefix. The level of security may be translated into a Security Preference and used to influence the route selection pro- cess [BGP]. To determine the Secuirty Preference of a prefix, the following algo- rithm may be used: 1 A Security Preference is assigned to each prefix indicating neu- tral trust. The neutral value is locally significant to the Ng, et al. [Page 15]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 autonomous system, and all routers in it MUST use the same value. 2 The Security Preference SHOULD be lowered for any of the follow- ing cases: o The AS_PATH verification failed at a link other than the second hop. o The Second Hop verification failed. o The prefix is unverified. o The prefix is invalid. Each of these cases represents a different degree of failure in the validation and verification process. The amount by which the Security Preference is lowered is locally significant to the autonomous system, and all routers in it MUST use the same value. If the local policy determines that a prefix may be used (even if it may have failed the validation and verification pro- cess), it is recommended that the Security Preference be lowered such that a lower value is assigned to invalid paths. 3 The Security Preference SHOULD be increased for any of the fol- lowing cases: o The prefix is validated. o The Second Hop verification passed. o The AS_PATH verification passed for the whole path. The amount by which the Security Preference is increased is locally significant to the autonomous system, and all routers in it MUST use the same value. It is recommended that the Security Preference be increased such that a higher value is assigned to paths that pass all the validation and verification steps. The resulting Security Preference value may be used to select among different routes for the same prefix; the higher value MUST be pre- ferred. Any of the following methods may be used: A Consider the Security Preference prior to calculating the degree of preference [BGP] for a prefix. B Assign the value of the Security Preference to any of the attri- butes used in the Decision Process [BGP]. Care must be taken Ng, et al. [Page 16]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 with attributes for which the lower value is preferred. C Use a Cost Community [COST] and its associated methods to con- sider the Security Preference at any step in the Decision Pro- cess [BGP] without overloading other attributes. Care must be taken as the lowest value in a Cost Community is preferred. The method selected MUST be consistent through the local Autonomous System. 8. Security Considerations This document defines extensions to BGP that address specific secu- rity concerns for the protocol. While it adds functionality, the flexilibty allows it to not introduce any new security concerns. 9. IANA Considerations This document defines the Security Message for BGP, which contains a series of TLVs. IANA is expected to maintain a registry of all the values defined, as follows: The SECURITY message Type field : o Type value 0 is reserved. o Type values 1 through 7 are assigned in this document. o Type values 8 through 16575 MUST be assigned using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. o Type values 16576 through 32895 SHOULD be assigned using the "Specification Required" policy defined in RFC2434 [RFC2434]. o Type values 32896 through 65535 are for "Private Use" as defined in RFC2434 [RFC2434]. Request TLV Request Type Field: o Bits 1 through 3 are assigned in this document. o Bits 4 thru 8 MUST be assigned using the "IETF Consensus" pol- icy defined in RFC2434 [RFC2434]. o Bits 9 thru 16 are for "Private Use" as defined in RFC2434 [RFC2434]. Ng, et al. [Page 17]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 10. Normative References [BGP] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [MULTIPROTOCOL-BGP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., "Multiproto- col Extensions for BGP-4", RFC 2858, June 2000 [CAPABILITY] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP- 4", RFC2842, May 2000 [SOBGP-DEPLOY] White, R. (editor), "Considerations for Secure Origin BGP (soBGP) Deployment", draft-white-sobgp-deployment-02, October 2002 [SOBGP-RADIUS] Lovnick, Chris, "RADIUS Attributes for soBGP Support", draft- ietf-rpsec-radius-sobgp-00, October 2002 [SOBGP-CERTIFICATE] Weis, Brian (Editor), "Secure Origin BGP (soBGP) Certificates", draft-weis-sobgp-certificates-00, June 2003 11. Informative References [COST] Retana, A., White, R., "BGP Custom Decision Process", draft- retana-bgp-custom-decision-00, October 2002. [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con- siderations Section in RFCs", RFC 2434, October 1998. [BGP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig- nature Option", RFC2385, August 1998 [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998. [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [SOBGP-ANALYSIS] Ng, et al. [Page 18]
INTERNET DRAFT Secure Origin BGP (soBGP) June 2003 Not yet published 12. Editor's Address James Ng (Editor) Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 jamng@cisco.com Ng, et al. [Page 19]