[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                           James Ng
Internet Draft                                                  (editor)
Expiration Date: October 2004                              Cisco Systems
File Name: draft-ng-sobgp-bgpextensions-00.txt                April 2004

             Extensions to BGP Transport soBGP Certificates
                  draft-ng-sobgp-bgpextensions-00.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 Weis, 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)              April 2004


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, verifying that the final destination in the path is
   actually within the autonomous system to which the packets are being
   routed, and proving the validity of the AS Path contained in the
   update.

   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-
        ARCH] 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-ARCH].

   o    Attempt to analyze the security protection provided by the pro-
        posed security system. This may be address in a future draft.

   This document primarily focuses on extensions to the BGP protocol
   itself to support such a security system through the transport of the
   certificates described in [SOBGP-CERTIFICATE].

   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 2]


INTERNET DRAFT         Secure Origin BGP (soBGP)              April 2004


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 [TBD]. The SECURITY message is
   used to transport the certificates described in [SOBGP-CERTIFICATE].


4.1. Negotiating Security Capability

   The ability to exchange SECURITY messages MAY be negotiated at ses-
   sion startup, as described in [CAPABILITY]. The capability code is
   <to be assigned by IANA>.


   o    Speakers MAY negotiate the exchange of SECURITY information only
        or SECURITY and NLRIs.

   o    If the exchange of SECURITY messages is negotiated, the SECURITY
        option message MUST be exchanged before any other SECURITY mes-
        sages are exchanged. The option bits in this message determine
        if SECURITY messages or NLRIs will be exchanged first.

   o    If two BGP speakers have negotiated to exchange SECURITY mes-
        sages, they SHOULD exchange the soBGP certificates contained in
        their local databases.


4.2. The Security Message Format

   The SECURITY message is formatted as described in [BGP], with a type
   code of [TBD]. Within each message is a series of TLVs, or security
   message 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 3]


INTERNET DRAFT         Secure Origin BGP (soBGP)              April 2004


   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.

      Two TLVs are currently defined within the SECURITY message.
      Further TLVs are defined for carrying certificates in [SOBGP-
      CERTIFICATE].


4.2.1. The SECURITY Option TLV

   The SECURITY Option TLV provides a way for exchanging speakers to
   inform their peers about local configurations which may pertain to
   the peering session. SECURITY Option TLVs are encapsulated within a
   TLV Type 1, and transmitted within the SECURITY message type.

   If SECURITY Option 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 (0x0001)

   o    Length: (2 octets), set to 2

   o    Options: (4 octets), a bitfield, described below

   The options field is a 32 bit bitfield, allowing up to 32 different
   options to be specified.

   o    Bit 0: If set, indicates that SECURITY information should be
        sent before NLRI information on this session; if cleared, indi-
        cates that NLRI information should be sent before SECURITY
        information.

   o    Bit 1: If set, indicates that this peer will only transmit



Ng, et al.                                                      [Page 4]


INTERNET DRAFT         Secure Origin BGP (soBGP)              April 2004


        validated certificates of any type along this session. This bit
        MUST NOT be used for eBGP sessions.

   o    Bit 2: If set, indicates that this peer will only accept vali-
        dated certificates of any type along this session (valid only on
        iBGP sessions).

   Bit 0 in the option field allows the operator to configure the local
   device so it receives all prefixes first, decreasing convergence to
   the minimum time, or receives all SECURITY information first, allow-
   ing all prefixes to be validated before they are installed.

   Bits 1 and 2 allow peers along an iBGP session to trust the certifi-
   cations they receive without validating them. If bit 1 is set on the
   transmitting peer, bit 2 is set on the receiving peer, and the BGP
   peering session is an authenticated or encrypted iBGP session, the
   receiving peer may accept all received certificates from the
   transmitting peer as already validated. This is called a trusted
   peering relationship.


4.2.2. 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                      | Length                        |
   +-------------------------------+-------------------------------+
   | Request Type                  | Length                        |
   +-------------------------------+-------------------------------+
   | Request Indicator SubTV ....                                  |
   +---------------------------
   | Request Type                  | Length                        |
   +-------------------------------+-------------------------------+
   | Request Indicator SubTV ....                                  |
   +---------------------------

   o    TLV type: (2 octets), 2

   o    Length: (2 octets), set to the total length of the request in
        octets.

   o    Request Type: (2 octets), treated as an unsigned integer indi-
        cating the type of information requested.

   o    Length: (2 octets), set to the number of requests of the request
        type included in this request.




Ng, et al.                                                      [Page 5]


INTERNET DRAFT         Secure Origin BGP (soBGP)              April 2004


   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.
   Four 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 6]


INTERNET DRAFT         Secure Origin BGP (soBGP)              April 2004


4.2.3. The Cluster List 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                        |
   +-------------------------------+-------------------------------+
   | Cluster ID                                                    |
   +-------------------------------+-------------------------------+
   | ....                                                          |
   +---------------------------

   o    TLV type: (2 octets), 3

   o    Length: (2 octets), set to the number of cluster IDs in the TLV

   The use of the Cluster List TLV is described in the Reflecting SECU-
   RITY messages section below.


5. Receiving and Processing SECURITY messages

   Each section below describes the receipt and processing of SECURITY
   messages.


5.1. Processing SECURITY Messages Containing a Certificate

   For each certificate received, the BGP speaker MUST:


   o    Examine the certificate to determine if a copy of this certifi-
        cate already exists in the local database.  Any certificate
        which is found to already be held locally MUST be discarded.

   o    If the certificate is received through an untrusted peering
        relationship, place the certificate in a local certificate data-
        base and process according to [SOBGP-CERTIFICATE].

   o    If the certificate is received through a trusted peering rela-
        tionship, place certificate in a local certificate database,
        treating it as if it is already validated according to [SOBGP-
        CERTIFICATE].

   o    If a received certificate is sucessfully validated using the
        process described in [SOBGP-CERTIFICATE], it should be readver-
        tised to all peers outside the local autonomous system (eBGP
        peers). If the peering relationship is trusted, the certificate



Ng, et al.                                                      [Page 7]


INTERNET DRAFT         Secure Origin BGP (soBGP)              April 2004


        should be advertised as validated by marking it as indicated in
        [SOBGP-CERTIFICATE].


5.2. Reflecting SECURITY Messages

   A BGP speaker MAY be configured to reflect received SECURITY mes-
   sages, with or without processing them, in a way similar to the way
   BGP routing information is reflected among iBGP speakers, described
   in [BGP-REFLECTION]. When reflecting SECURITY messages, a BGP speaker
   MUST:


   o    Examine the SECURITY message for the presence of a Cluster List
        TLV.

      o    If a Cluster List TLV exists, and the local router ID is con-
           tained in the list of Cluster IDs, discard the SECURITY mes-
           sage.

      o    If a Cluster List TLV exists, and the local router ID is not
           contained in the list of Cluster IDs, add the local router ID
           to the list and retransmit the SECURITY message to all BGP
           peers which have negotiated receipt of SECURITY messages.

      o    If a Cluster List TLV does not exist, add a new Cluster List
           TLV to the SECURITY message, including the local router ID in
           the new TLV.


5.3. 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.









Ng, et al.                                                      [Page 8]


INTERNET DRAFT         Secure Origin BGP (soBGP)              April 2004


5.4. 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.  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. Security Considerations

   This document defines extensions to BGP that address specific secu-
   rity concerns for the protocol.  While it adds functionality, the
   flexibility allows it to not introduce any new security concerns.


7. 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 3 are assigned in this document.

   o    Type values 4 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].



Ng, et al.                                                      [Page 9]


INTERNET DRAFT         Secure Origin BGP (soBGP)              April 2004


   Request TLV Request Type Field:

   o    Types 1 through 3 are assigned in this document.

   o    Types 4 thru 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].


8. 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-ARCH]
        White, R. (editor), "Architecture and Deployment Considerations
        for Secure Origin BGP (soBGP)", draft-white-sobgp-deployment-03,
        April 2004

   [SOBGP-CERTIFICATE]
        Weis, Brian (editor), "Secure Origin BGP (soBGP) Certificates",
        draft-weis-sobgp-certificates-01.txt, October 2003
















Ng, et al.                                                     [Page 10]


INTERNET DRAFT         Secure Origin BGP (soBGP)              April 2004


9. Informative References

[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 Signa-
     ture 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-RADIUS]
     Lovnick, C, "RADIUS Attributes for soBGP Support", draft-lonvick-
     sobgp-radius-04.txt, February 2004

[BGP-REFLECTION]
     Bates, T, et al, "BGP Route Reflection - An Alternative to Full
     Mesh IBGP", draft-ietf-idr-rfc2796bis-00.txt, March 2004


10. Editor's Address

   James Ng (Editor)
   Cisco Systems
   7025 Kit Creek Road
   Research Triangle Park, NC 27709
   jamng@cisco.com



















Ng, et al.                                                     [Page 11]