[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
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]