Internet DRAFT - draft-ward-bgp-ipsec


              Internet Draft 
David Ward
              Document: draft-ward-bgp-ipsec-00.txt 
Cisco Systems
              Expires: 2002 
January 2002

                                  Securing BGPv4 using IPsec

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

           The list of Internet-Draft Shadow Directories can be accessed at

           Copyright Notice

           Copyright (C) The Internet Society (2001).  All Rights Reserved.


           This document discusses how BGPv4 may utilize IPsec to provide
           authentication, integrity, confidentiality and replay

           Table of Contents

              Status of this Memo.........................................1
              Copyright Notice............................................1

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

              1. Introduction.............................................2
                   1.1 Terminology........................................3
                   1.2 Requirements language..............................3
              2. BGPv4 security requirements..............................3
                   2.1 BGPv4  Security Proposal...........................4
                   2.2 Rekeying issues....................................5
                   2.3 IKE issues.........................................6
                   2.4 Transform issues...................................7
              3. BGPv4/IPsec inter-operability guidelines.................8
                   3.1 BGPv4/IPsec binding................................9
                   3.2 Initiating a New BGPv4 Session....................10
                   3.3 Graceful BGPv4 Teardown...........................11
                   3.4 Non-graceful BGPv4 Teardown.......................12
                   3.5 Fragmentation Issues..............................12
                   3.6 Per-packet Security Checks........................14
                   3.7 IPsec Packet Integrity Assumptions................14
                   3.8 Transport mode versus tunnel mode.................14
                   3.9 IPsec tunnel mode addressing considerations.......16
                   3.10 NAT traversal for multihop peering sessions......18
              4. Security considerations.................................18
                   4.1 IKE and BGPv4 authentication......................18
                   4.2 Certificate authentication........................19
                   4.3 Machine versus user certificates..................20
                   4.4 Pre-shared keys in IKE............................21
                   4.5 Use of AES in counter mode........................22
              Author's Addresses.........................................27

           1. Introduction

           BGP v4, described in [1], is a connection-oriented dynamic
           routing protocol.  A BGP session begins with an BGP OPEN message
           being sent to a configured BGP Peer over TCP, followed by a
           series of other steps to complete initialization.  While the BGP
           session may include mutual authentication [52] and negotiation
           of session parameters [53], BGP does not define its own per-
           packet authentication, integrity, confidentiality or replay
           protection mechanisms.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           IPsec is a protocol suite used to secure communications at the
           network layer between two peers.  The IPsec protocol suite is
           specified within the IP Security Architecture [6], IKE [7],
           IPsec Authentication Header (AH) [3], and IPsec Encapsulating
           Security Payload (ESP) [4] documents.  IKE is the key management
           protocol while AH and ESP are used to protect IP traffic.

           This draft proposes use of the IPsec protocol suite for
           protecting BGP v4 traffic over IP networks, and discusses how
           IPsec and BGP should be used together.

           1.1 Terminology

           BGP         BGP is a peer-peer protocol in which peers
                       open TCP connections to other remote peers.

           Initiator   The BGP peering Initiator connects to a remote
                       peer on a well known TCP port <170> by sending an
                       OPEN message.

           Remote Peer The BGP Remote Peer listens on the well-known TCP
                       port for incoming connections, and replies over
                       the same connection.

           1.2 Requirements language

           In this document, the key words "MAY", "MUST,  "MUST  NOT",
           "optional", "recommended",  "SHOULD",  and  "SHOULD  NOT",  are
           to be interpreted as described in [2].

           2. BGPv4 security requirements

           The BGPv4 protocol is used to transmit routing update packets
           over IP networks. Therefore, both the session and data packets
           of BGP are vulnerable to attack.  Examples of attacks include:

                   [1]  An adversary may try to discover user identities by
                   snooping data packets.

                   [2]  An adversary may try to modify packets (both
                   session and data).

                   [3]  An adversary may try to hijack the BGPv4

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

                   [4]  An adversary can launch denial of service attacks
                   by terminating BGP connections, such as by sending a TCP

                   [5]  An adversary may attempt to disrupt the BGP peering
                   negotiation so as to weaken the BGP authentication
                   process or gain access to peer passwords.

           To address these threats, the BGPv4 security implementation MUST
           provide authentication, integrity and replay protection for
           control and data packets. It MUST provide confidentiality for
           control and data packets. An BGPv4 security implementation MUST
           also provide a scalable approach to key management.

           The current BGP protocol, and drafted authentication mechanisms
           do not meet the security requirements as listed. BGPv4 md5 [52]
           authentication provides mutual authentication between the local
           and remote peer at connection origination, and secures session
           and data traffic on a per packet basis but, does not provide
           per-packet authentication, integrity, confidentiality or replay
           protection, therefore leaving the BGPv4 peering session
           vulnerable to attack. In addition, BGPv4 peering authentication,
           outlined in [1], does not provide for a protected ciphersuite
           negotiation.  Therefore, BGP md5 authentication provides a weak
           security solution.

           2.1 BGPv4  Security Proposal

           To provide authentication, integrity and replay protection of
           BGP Packets, BGPv4 security implementations MUST support
           transport mode ESP with NULL encryption and HMAC-SHA1
           authentication. All the IPsec-mandated ciphersuites (described
           in RFC 2406 [4] and RFC 2402 [3]), including NULL encryption
           MUST be supported.  Note that although an implementation MUST
           support all IPsec ciphersuites, it is an operator choice which
           ones will be used. The implementations MUST implement replay,
           authentication and integrity protection mechanisms of IPsec.

           All BGP security compliant implementations MUST implement IPsec
           ESP in transport mode for securing both BGPv4 session and data
           packets. If confidentiality is not used (e.g., BGPv4 data
           traffic), ESP with NULL encryption may be used. Note that AH
           mode is not suggested here as it may not be supported in future

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           versions of IPSec and ESP with NULL encryption has the same

           BGPv4 security MUST meet the key management requirements of the
           IPsec protocol suite. IKE SHOULD be supported for
           authentication, security association negotiation, and key
           management using the IPsec DOI [5].

           2.2 Rekeying issues

           It is expected that BGP sessions may need to last for very long
           intervals.  It is unlikely but, possible that BGP may cycle
           through the 32-bit IPsec sequence number space due to this

           As a result, BGPv4 implementations operating may in the future
           be required to implement the IPsec sequence number extension,
           described in [49].  Sequence number extension is still not
           standardized and thus, NOT a requirement for the security
           implementation at the time of this publication

           Note that depending on the transform in use, it is possible that
           rekeying will be required prior to exhaustion of the sequence
           number space.  Bellare et. al. have formalized this in [51],
           showing that the insecurity of CBC mode increases as O(s^2/2^n),
           where n is the block size in bits, and s is the total number of
           blocks encrypted.

           This formula sets a limit on the bytes that can be sent on a CBC
           SA before a rekey is required:

                       B = s * n/8 = (n/8) * 2^(n/2)

                       B = maximum bytes sent on the SA
                       n = block size in bits

           This means that cipher block size as well as key length needs to
           be considered in the rekey decision. 3DES uses a block size n =
           64 bits (2^3 bytes); this implies that the SA must be rekeyed
           before B = (64/8) * (2^32) = 2^35 bytes are sent.

           In terms of the sequence number space, for a 3DES encrypted
           message of 512 = 2^9 bytes (2^6 blocks) this implies that the

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           key has become insecure after about 2^26 messages.  This is s =
           2^26 * 2^6 = 2^32 blocks and (2^32)^2/2^64 = 1.  With the 3DES
           cipher in CBC mode, it would be prudent to rekey more often,
           such as every 2^20 messages or 2^29 bytes.  These exceedingly
           short rekey times may make it difficult to utilize 3DES
           effectively to secure BGPv4.

           In comparison, AES-CBC uses a block size of 128 bits (2^4
           bytes).  This enables B = (128/8) * (2^64) = 2^68 bytes to be
           sent prior to requiring a rekey. This means that the required
           rekey times are 2^33 times longer than for 3DES. AES-CBC mode
           SHOULD be used in the BGPv4 security implementation. This
           alleviates the need for requiring the sequence number extension
           work [49].

           In terms of the sequence number space, for an AES encrypted
           message of 512 = 2^9 bytes (2^5 blocks) this implies that the
           key has become insecure after about 2^59 messages (2^59 *
           2^5)^2/2^128 = 1.  This means that the entire current ESP
           sequence space of 2^32 messages could be consumed without
           compromising the key. AES would still permit a safe CBC mode
           construction if the ESP sequence space were expanded to 48 bits,
           since (2^48 * 2^5)^2/2^128 = 2^-22.

           2.3 IKE issues

           As noted in [48], there are situations where it is necessary for
           IKE to be implemented in firmware. With the proliferation of
           IPsec host implementations, these issues are most likely to
           arise in future designs.

           In such situations, it is important to keep the size of the IKE
           implementation within strict limits. As noted in [48] an upper
           bound on the size of an IKE implementation might be considered
           to be 800 KB, with 80 KB enabling implementation in a wide range
           of situations.

           IKE implementations currently exist which meet the requirements.
           Therefore, while removal of seldom used IKE functionality (such
           as the nonce authentication methods) would reduce complexity,
           BGPv4 implementations typically will not require this in order
           to fit within the code size budget.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           2.4 Transform issues

           Since BGPv4 implementations may operate in different deployment
           scenarios, the ability to offer IPsec security services with
           some flexibility is a goal. Since support for multiple
           algorithms multiplies the complexity and expense of system
           design, one of the goals of the transform selection effort is to
           find a minimal set of confidentiality and authentication
           algorithms that are implementable.

           In this specification, we primarily concern ourselves with IPsec
           transforms that have already been specified. Where existing
           algorithms do not gracefully scale for easy implementation, we
           further consider algorithms for which transform specifications
           are not yet complete, but for which parts are expected to be
           available for inclusion in products shipping within the next 12
           months. As the state of the art advances, the range of feasible
           algorithms will broaden and additional mandatory-to-implement
           algorithms may be considered.

           This draft proposes that BGPv4 security implementations utilize
           IPsec transport mode ESP.  Section 5 of RFC 2406 [4] states:

              "A compliant ESP implementation MUST support the following
              mandatory-to-implement algorithms:

                    - DES in CBC mode
                    - HMAC with MD5
                    - HMAC with SHA-1
                    - NULL Authentication algorithm
                    - NULL Encryption algorithm

           The DES algorithm is specified in [29]; implementation
           guidelines are found in [30], and security issues are discussed
           in [31],[43], [17]. The DES IPsec transform is defined in [32]
           and the 3DES in CBC mode IPsec transform is specified in [33].

           The MD5 algorithm is specified in [8]; HMAC is defined in [19]
           and security issues with MD5 are discussed in [19]. The HMAC-MD5
           IPsec transform is specified in [24].  The HMAC-SHA1 IPsec
           transform is specified in [25].

           In addition to these existing algorithms, NIST is currently
           evaluating the following modes [37] of AES, defined in [34],

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

                AES in Electronic Codebook (ECB) confidentiality mode
                AES in Cipher Block Chaining (CBC) confidentiality mode
                AES in Cipher Feedback (CFB) confidentiality mode
                AES in Output Feedback (OFB) confidentiality mode
                AES in Counter (CTR) confidentiality mode
                AES CBC-MAC authentication mode

           The Modes [36] effort is also considering a number of additional
           algorithms, including the following:


                   HMAC-SHA1 [25] is to be preferred to HMAC-MD5, due to
                   concerns that have been raised about the security of MD5
                   [9].  HMAC-SHA1 parts are currently available and an
                   IPsec transform specification [25] exists. As a result,
                   it is most practical to utilize HMAC-SHA1 as the
                   authentication algorithm for products shipping in the
                   near future. As a result, BGPv4 security implementations
                   MUST implement HMAC with SHA1.

           The HMAC-SHA2 algorithm [28] is also under development,
           including an IPsec transform [45], so that this may merit
           consideration in the future.  Authentication transforms also
           exist that are considerably more efficient to implement than
           either HMAC-SHA1 or HMAC-SHA2. UMAC [27],[44] is more efficient
           to implement in software and PMAC [26] is more efficient to
           implement in hardware.  PMAC is currently being evaluated as
           part of the NIST modes effort [36] but an IPsec transform does
           not yet exist; neither does a UMAC transform.

           For confidentiality, the ESP mandatory-to-implement algorithm
           (DES) is unacceptable for use with BGPv4 security. As noted in
           [17], DES is crackable with modest computation resources, and so
           is inappropriate for use in situations requiring high levels of
           security. As a result, DES SHOULD NOT be used for encrypting

           3. BGPv4/IPsec inter-operability guidelines

           The following guidelines are established to meet BGPv4 security
           requirements using IPsec in practical situations.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           3.1 BGPv4/IPsec binding

           An BGPv4 session [1], composed of one (or more) TCP connections,
           is identified by the 2-tuple of the Initiator-defined identifier
           and the Remote Peer-defined identifier, <ISID, TSID>.  Each
           connection within a given session is assigned a unique
           Connection Identification, CID. The TCP connection is identified
           by the 5-tuple <Source IP address, Destination IP address, TCP,
           Source Port, Destination Port>.  An IPsec Phase 2 SA is
           identified by the 3-tuple <ESP, destination address, SPI>.

           The BGPv4 session and connection information is carried within
           the BGPv4 Open Message, transported over TCP.  Since an BGPv4
           initiator may have multiple logical and interfaces, BGPv4
           sessions may be initiated from different IP addresses.
           Similarly, multiple BGPv4 Remote Peers may exist behind a single
           IP address (firewall, NAT gateway), so that there may be
           multiple BGPv4 sessions between a given <source IP address,
           destination IP address> pair.

           The relationship between BGPv4 sessions, TCP connections and IKE
           Phase 1 and Phase 2 SAs is as follows:

                   [1]  An BGPv4 initiator or Remote Peer may have more
                   than one interface, and therefore may have multiple IP
                   addresses. Also, multiple BGPv4 initiators and Remote
                   Peers may exist behind a single IP address.  As a
                   result, an BGPv4 Session may correspond to multiple IKE
                   Phase 1 Security Associations, though typically a single
                   IKE Phase 1 security association will exist for an
                   <Initiator IP address, Remote Peer IP address> tuple.

                   [2]  The TCP connection corresponding to the  BGPv4
                   Session is protected by a separate IKE Phase 2 SA, with
                   descriptors specific to that TCP connection. Each IKE
                   Phase 2 SA protects only a single TCP connection, and
                   each TCP connection is transported under only one IKE
                   Phase 2 SA. BGPv4 security implementations need not
                   verify that the IP addresses and TCP port values in the
                   packet match the socket information which was used to
                   setup the connection. This check will be performed by
                   IPsec, preventing malicious peers from sending commands
                   on inappropriate Quick Mode SAs.

           Given this, all the information needed for the BGPv4/IPsec
           binding is contained within the configuration for the BGPv4

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           Initiator and Remote Peer. This includes the binding between an
           IKE Phase 1 SA and the corresponding BGPv4 sessions, as well as
           the binding between an IPsec Phase 2 SA and the TCP connection
           and BGPv4 connection ID.

           3.2 Initiating a New BGPv4 Session

           In order to create a new BGPv4 Session, an Initiator
           implementing BGPv4 security first establishes IKE Phase 1 and
           Phase 2 SAs, then exchanges BGPv4 control messages over an
           IPsec-secured TCP connection.  The BGPv4 Initiator contacts the
           Remote Peer on well-known TCP port <170>. The Initiator and
           Remote Peer MUST successfully complete the IKE phase 1 and Phase
           2 negotiations before the initial TCP connection setup messages
           are exchanged so that these messages can be IPsec protected.
           From this point forward, subsequent BGPv4 connections
           established within the BGPv4 session will be protected by IKE
           Phase 2 SAs derived from the IKE Phase 1 SA. Note that this
           requirement also for the use of both the BGPv4 IPSec security
           implemenation and md5 authentication [52] but, it is not a
           practial deployment scenario. The dual deployment would be
           wasteful of CPU resources and would not provide an improved
           security implementation or deployment.

           In the Phase 2 Quick Mode exchanges used to protected individual
           BGPv4 connections, the Identity Payload fields MUST be present.
           These fields carry the source and destination addresses and
           source and destination ports of the BGPv4 Initiator and Remote
           Peers, thus binding the Phase 2 security association to specific
           TCP and BGPv4 connections.  The IKE Quick Mode ID payloads MUST
           carry individual addresses, and MUST NOT use the IP Subnet or IP
           Address Range formats.

           Once the IKE Phase 2 negotiations are complete and the TCP
           connection is established over IPsec, the BGPv4 Initiator MUST
           send the BGPv4 OPEN command over the TCP connection secured by
           the recently negotiated Quick Mode SA.

           The Initiator fills in the ISID field, and leaves the TSID field
           set to zero, to indicate that it is the first message of a new
           session establishment exchange.  The Initiator also fills in a
           CID value, which is associated with the BGPv4 connection
           corresponding to the TCP connection secured by the Quick Mode
           SA. When the BGPv4 Remote Peer replies with its OPEN Command,
           both BGPv4 devices will know the TSID, and therefore the BGPv4
           session identifier <ISDI, TSID>.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           At this point, a binding is established between the BGPv4
           session identifier and the IKE Phase 1 SAs. A single BGPv4
           session identifier may have multiple associated IKE Phase 1 SAs,
           and each IKE Phase 1 SA may have multiple associated BGPv4
           session identifiers. In addition, a binding is established
           between the BGPv4 connection identifier CID, the TCP connection
           5-tuple, and the IPsec SA, as identified by the <ESP,
           destination address, SPI> combination. Each BGPv4 connection
           corresponds to a single TCP connection and IPsec SA.

           Within IKE, each key refresh requires that a new security
           association be established.  In practice there is a time
           interval during which an old, about-to-expire SA and newly
           established SA will both be valid.  The IPsec implementation
           will choose which security association to use based on local
           policy, and BGPv4 concerns play no role in this selection

           3.3 Graceful BGPv4 Teardown

           Mechanisms within BGPv4 provide for both graceful and non-
           graceful teardown of BGPv4 Sessions or individual TCP
           connections within a given session.  The BGPv4 close or graceful
           restart message is used to effect graceful teardown. This
           command allows the BGPv4 Initiator to request that the session
           be closed.

           When the BGPv4 implementation wishes to close a session, it MUST
           use the appropriate BGPv4 commands to accomplish this.  After
           exchanging the appropriate BGPv4 control messages for session
           closure, the BGPv4 security implementation SHOULD initiate a
           half-close of each TCP connection within the BGPv4 session.
           Since a given IKE Phase 1 SA may be bound to multiple BGPv4
           sessions (although very unlikely) and the SA can also possibly
           be shared by non-BGP traffic (for the same source and
           destination IP addresses) the BGPv4 implementation will only
           signal the deletion the IKE Phase 1 SAs bound to the BGPv4
           session if there are no remaining BGPv4 sessions bound to those
           SAs. For those Phase 1 SAs that are deleted, the BGPv4 security
           implementation will also signal the IKE Phase 2 SAs bound to
           them. The actual responsibility of deleting the SA will be given
           to the IKE implementation.

           When the BGPv4 security implementation wishes to close an
           individual TCP connection while leaving the parent BGPv4 session

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           active, it SHOULD half-close the TCP connection. This results in
           a FIN being sent, putting the TCP connection into the FIN WAIT-1
           state, as described in [10]. After the other side responds, the
           TIME WAIT state is entered. After the expiration of the TIME
           WAIT timeout, the IKE Phase 2 security association bound to the
           TCP connection MUST be deleted. Closing the TCP connection prior
           to deleting the IKE Phase 2 SA ensures that all the TCP packets
           sent on the connection are IPsec-protected.

           3.4 Non-graceful BGPv4 Teardown

           If the BGPv4 security implementation becomes aware that a given
           TCP connection has unexpectedly failed, it SHOULD delete the
           associated IKE Phase 2 security association.  If the IKE
           implementation receives a Phase 2 Delete message for a security
           association bound to a TCP connection, it SHOULD notify the
           BGPv4 security implementation.  If the TCP connection whose SA
           was deleted is one which a CLOSE sequence marked for removal
           from the BGPv4 session, then the IKE Phase 2 Delete message
           serves as confirmation that the BGPv4 peer has executed an BGPv4
           teardown process for the connection. The BGPv4 connection state
           and any associated filters can now be safely removed.

           BGPv4 keep-alive messages, notification and update messages
           provide the capability to detect or signal when a non-graceful
           restart has occurred.  Whenever teardown events occur, causing
           the peer session to close, the control connection teardown
           mechanism defined in [1] must be used. Once the BGPv4 peering
           session is deleted by either peer, any phase 1 and phase 2 SA's
           which still exist as a result of the session between the peers
           SHOULD be deleted.  Phase 1 and phase 2 delete messages SHOULD
           be sent when this occurs. This should in no way interfere with
           BGPv4 Graceful Restart mechanisms [graceful restart].

           3.5 Fragmentation Issues

           Fragmentation can become a concern when prepending IPsec headers
           to a BGP PDU. One mechanism which can be used to reduce this
           problem is to utilize path MTU discovery within the TCP
           transport protocol. For example, when TCP is used as the BGPv4
           transport, then path MTU discovery [11]-[13], SHOULD be used to
           enable the TCP endpoints to discover the correct MTU, including
           effects due to IPsec encapsulation.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           However, Path MTU discovery fails when appropriate ICMP messages
           are not received by the host. This occurs in IPsec
           implementations which drop unauthenticated ICMP packets.  This
           can result in blackholing in naŹve TCP implementations, as
           described in [RFC2923].  Appropriate TCP behavior is described
           in section 2.1 of [RFC2923]:

                   "TCP should notice that the connection is timing out.
                   After several timeouts, TCP should attempt to send
                   smaller packets, perhaps turning off the DF flag for
                   each packet. If this succeeds, it should continue to
                   turn off PMTUD for the connection for some reasonable
                   period of time, after which it should probe again to try
                   to determine if the path has changed."

           If an ICMP PMTU is received by an IPsec implementation that
           processes unauthenticated ICMP packets, this value should be
           stored in the SA as proposed in [RFC2401], and IPsec should also
           provide notification of this event to TCP so that the new MTU
           value can be correctly reflected.

           When certificate authentication is used, IKE fragmentation can
           be encountered. This can occur when certificate chains are used,
           or even when exchanging a single certificate if the key size, or
           size of other certificate fields (such as the distinguished name
           and other OIDs) is arge enough. Many Network Address Translators
           (NATs) and firewalls do not handle fragments properly, dropping
           them on inbound and/or outbound.

           Routers in the path will also frequently discard fragments after
           the initial one, since they typically will not contain full IP
           headers that can be compared against an Access List.

           As a result, where IKE fragmentation occurs, the endpoints will
           often be unable to establish an IPsec security association.  The
           solution to this problem is to install NAT, firewall or router
           code load that can properly support fragments. If this cannot be
           done, then the following alternatives can be considered:

                   [1]  Obtaining certificates by other means.

                   [2]  Reducing the size of the certificate chain.

                   [3]  Reducing  the size of fields within the
                   certificates. This includes reduction in the key size,

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

                   the distinguished name or other fields. This should be
                   considered only as a last resort.

           3.6 Per-packet Security Checks

           When a packet arrives from a connection which requires security,
           BGP MUST check to ensure that the packet was decrypted and/or
           authenticated by IPsec. Since IPsec already verifies that the
           packet arrived in the correct SA, BGPv4 can be assured that the
           packet was indeed sent by a trusted peer.

           When used with BGP, IPsec will negotiate a separate Phase 2 SA
           for each TCP connection, with IPsec filters specific to the TCP
           connection. As a result, only traffic for a single TCP
           connection will flow within each IPsec Phase 2 SA. BGPv4
           security implementations need not verify that the IP addresses
           and TCP port values in the packet match the socket information
           which was used to setup the BGPv4 connection. This check will be
           performed by IPsec, preventing malicious peers from sending
           BGPv4 session packets on inappropriate Quick Mode SAs.

           3.7 IPsec Packet Integrity Assumptions

           BGP's error detection and recovery assumes that the TCP and IP
           checksums provides adequate integrity protection.

           IPsec per-packet authentication and integrity protection offers
           strong protection against an attacker attempting to modify
           packets In transit, as well as unintentional packet
           modifications caused by router malfunctions. This protection is
           considerably stronger than the 16-bit TCP checksum [11]. Since
           IPsec integrity protection occurs below TCP, if an error is
           discovered, then the packet will be discarded and TCP
           retransmission will occur, so that no recovery action need be
           taken at the BGP layer.

           3.8 Transport mode versus tunnel mode

           With respect to the BGPv4 security implemenation, the major
           differences between the IPsec tunnel mode and transport mode are
           as follows:

                   [1]  MTU considerations. Tunnel mode introduces an
                   additional IP header into the datagram that reflects
                   itself in a corresponding decrease in the path MTU seen

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

                   by packets traversing the tunnel. This may result in a
                   decrease in the maximum segment size of TCP connections
                   running over the tunnel.

                   [2]  Address assignment and configuration.  Within IPsec
                   tunnel mode, it is necessary for inner and outer source
                   addresses to be configured, and for inner and outer
                   destination addresses to be discovered. Within transport
                   mode it is only necessary to discover a single
                   destination address and configure a single source

                   [3]  NAT traversal. As noted in [20], IPsec tunnel mode
                   ESP can traverse NAT in limited circumstances, whereas
                   transport mode ESP cannot traverse NAT.  To enable NAT
                   traversal in the general case,  the IPsec NAT traversal
                   functionality described in [21], [22], [23] can be
                   implemented. More details are provided in the next

                   [4]  Connection-specific selectors. For both transport
                   and tunnel mode, it is possible to negotiate connection-
                   specific selectors, so that only a single BGPv4
                   connection will be protected by an IKE Phase 2 SA.
                   However, while negotiation of connection-specific
                   selectors is common within IPsec transport mode
                   implementations, IPsec security gateway implementations
                   typically negotiate "ANY to ANY" selectors by default.

                   [5]  Firewall traversal. Where a BGPv4 connection is to
                   traverse administrative domains, the firewall
                   administrator may desire to verify the integrity and
                   authenticity of each transiting packet,  rather than
                   opening a hole in the firewall for BGPv4. IPsec tunnel
                   mode lends itself to such verification, since the
                   firewall can terminate the tunnel mode connection while
                   still allowing the endpoints to communicate end-to-end.
                   If desired,  the endpoints can in addition utilize IPsec
                   transport mode for end-to-end security, so that they can
                   also verify authenticity and integrity of each packet
                   for themselves. In contrast, carrying out this
                   verification with IPsec transport mode is more complex,
                   since the firewall will need to terminate the IPsec
                   transport mode connection and will need to act as a TCP
                   proxy, originating a new Ipsec transmport mode
                   connection from the firewall to the internal endpoint.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

                   Such an implementation cannot provide end-to-end
                   authenticity or integrity protection.

                   [6]  IPsec-application integration. Where IPsec and the
                   application layer protocol are implemented on the same
                   device or host, it is possible to enable tight
                   integration between them. For example, the application
                   layer can request and verify that connections are
                   protected by IPsec, and can obtain attributes of the
                   IPsec security association. While in transport mode
                   implementations the IPsec and application protocol
                   implementations typically reside on the same host, with
                   IPsec tunnel mode, they may reside on different hosts.
                   Where IPsec is implemented on an external gateway,
                   integration between the application and IPsec is
                   typically not possible. This limits the ability of the
                   application to control and verify IPsec behavior.

           3.9 IPsec tunnel mode addressing considerations

           IPsec tunnels include both inner and outer source as well as
           destination addresses.

           When used with BGPv4, the inner destination address represents
           the address of the BGPv4 peer (e.g. the ultimate destination for
           the packet). The inner destination address can be discovered
           using SLP or can be resolved from an FQDN via DNS, so that
           obtaining this address is typically not an issue.

           The outer destination address represents the address of the
           IPsec security gateway used to reach the peer. Several
           mechanisms have been proposed for discovering the IPsec security
           gateway used to reach a particular peer.  [55] discusses the use
           of KX Resource Records (RRs) for IPsec gateway discovery.
           However, while KX RRs are supported by many DNS server
           implementations, they have not yet been widely deployed.
           Alternatively, DNS SRV [54] can also be used for this purpose,
           as can protocols such as Tunnel Endpoint Discovery [58].

           When used with BGPv4, the outer source address is configured
           either statically or dynamically, using mechanisms such as
           DHCPv4 [56], DHCPV6 [57], or Stateless address autoconfiguration

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           The inner source address SHOULD be included in the quick mode ID
           when the peer establishes a tunnel mode SA with the IPsec
           security gateway. This enables the IPsec security gateway to
           properly route packets back to the remote peer. The inner source
           address can be configured via a variety of mechanisms, depending
           on the scenario. Where the BGPv4 peers are located within the
           same administrative domain, it is typically possible for the
           inner and outer source addresses to be the same. This will work
           because the outer source address is presumably assigned from
           within a prefix assigned to the administrative domain, and which
           is therefore routable within the domain. Assuming that the IPsec
           security gateway is aware of the inner source address used by
           the connecting peer and plumbs a host route for it, then packets
           arriving at the IPsec security gateway destined for the address
           can be correctly encapsulated and sent down the correct tunnel.

           Where BGPv4 peers are located within different administrative
           domains, it may be necessary for the inner source address to be
           assigned by the IPsec security gateway, effectively "joining"
           the remote host to the LAN attached to the IPsec security
           gateway. For example, if the remote peer were to use its
           assigned (outer) source address as the inner source address,
           then a number of problems might result:

                   [1]  Intrusion detection systems sniffing the LAN behind
                   the IPsec security gateway would notice source addresses
                   originating outside the administative domain.

                   [2]  Reply packets might not reach their destination,
                   since the IPsec security gateway typically does not
                   advertise default, but rather only the prefix that it
                   allocates addresses from. Since the remote peer's
                   address does not originate from with a prefix native to
                   the administrative domain, it is likely that routers
                   within the domain would not have a route for it, and
                   would send the packet off to the border router, instead
                   of to the IPsec security gateway.

           For these reasons, for inter-domain use, assignment of inner
           source addresses may be needed. The use of DHCP within IPsec
           tunnel mode has been proposed for this, as described in [55].
           However, this mechanism is not yet widely deployed within IPsec
           security gateways.  Existing IPsec tunnel mode servers typically
           implement the desired functionality via proprietary extensions
           to IKE.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           3.10 NAT traversal for multihop peering sessions

           BGP security utilizes transport mode ESP. As noted in [20],
           transport mode ESP cannot traverse NAT, even though ESP itself
           does not include IP header fields within its message integrity
           check. This is because the 16-bit TCP checksum is calculated
           based on a "pseudo-header" that includes IP header fields, and
           the checksum is protected by the IPsec message integrity check.
           As a result, the TCP checksum will be invalidated by a NAT
           located between the BGPv4 Initiator and Remote Peer.

           Since TCP checksum calculation and verification is mandatory in
           both IPv4 and IPv6, it is not possible to omit checksum
           verification while remaining standards compliant.  In order to
           enable traversal of NAT existing between BGPv4 Initiators and
           Remote Peers, while remaining in compliance, BGPv4/IPsec
           implementations MAY implement IPsec/IKE NAT traversal, as
           described in [20]-[23].

           The IPsec/IKE NAT traversal specification [23] enables UDP
           encapsulation of IPsec to be negotiated if a NAT is detected in
           the path. By determining the IP address of the NAT, the TCP
           checksum can be calculated based on a pseudo-header including
           the NAT-adjusted address and ports. If this is done prior to
           calculating the IPsec message integrity check, TCP checksum
           verification will not fail.

           4. Security considerations

           IPsec IKE negotiation MUST negotiate an authentication method
           specified in the IKE RFC 2409 [7].  In this section, we discuss
           authentication issues.

           4.1 IKE and BGPv4 authentication

           While BGPv4 provides initial authentication [52], it does not
           provide per-packet authentication, integrity or replay
           protection. This implies that the identity verified in the BGPv4
           OPEN is not subsequently verified on reception of each packet.

           With IPsec, when the identity asserted in IKE is authenticated,
           the resulting derived keys are used to provide per-packet
           authentication, integrity and replay protection. As a result,

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           the identity verified in the IKE conversation is subsequently
           verified on reception of each packet.

           Let us assume that the identity claimed in BGPv4 OPEN is a user
           identity, while the identity claimed within IKE is a machine
           identity. Since only the machine identity is verified on a per-
           packet basis, there is no way for the recipient to verify that
           only the user authenticated via BGPv4 OPEN is using the IPsec

           In fact, IPsec implementations that only support machine
           authentication typically have no way to distinguish between user
           traffic within the kernel. As a result, where machine
           authentication is used, once a BGPv4/IPsec SA is opened, another
           user on a multi-user machine may be able to send traffic down
           the IPsec SA. If a network is operated by different
           administrative groups with different security privileges for
           configuration or operational duties then per user authentication
           may be applicable.

           To limit the potential vulnerability, BGP security
           implementations MUST negotiate a separate IPsec Phase 2 SA for
           each BGP peering session, with descriptors specific to that
           connection. This will prevent traffic for other BGP peers from
           travel within the IPsec SA negotiated for another BGPv4
           connection.  As a result, if access to the TCP socket used for
           the BGPv4 connection is exclusive to a single user, then access
           to the corresponding IPsec SA will also be exclusive, even if
           the IPsec implementation only supports machine authentication.

           If the IPsec implementation supports user authentication, the
           user identity asserted within IKE will be verified on a per-
           packet basis, and stronger assurances can be provided.  In this
           case, the user identity asserted within IKE will be verified on
           a per-packet basis. In order to provide segregation of traffic
           between peers When user authentication is used, the sender MUST
           ensure that only traffic from that particular user is sent down
           the BGPv4 SA.  Enforcement of this restriction is the
           responsibility of the operating system.

           4.2 Certificate authentication

           When X.509 certificate authentication is chosen within IKE, the
           BGPv4 Remote Peer is expected to use an IKE Certificate Request
           Payload (CRP) to request from the Initiator a certificate issued

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           by a particular certificate authority or may use several CRPs if
           several certificate authorities are trusted and configured in
           its IPsec IKE authentication policy.

           The BGPv4 remote peer SHOULD be able to trust several
           certificate authorities in order to allow BGP session Initiators
           to connect to it using their own certificate credential from
           their chosen PKI.  Client and server side certificate revocation
           list checking MAY be enabled on a per-CA basis, since
           differences in revocation list checking exist between different
           PKI providers.

           4.3 Machine versus user certificates

           The certificate credentials provided by the BGPv4 Initiator
           during the IKE negotiation MAY be those of the machine or of the
           BGPv4 user (router administrator or perhaps the operator
           performing BGP configuration). When machine authentication is
           used, the machine certificate is typically stored on the BGPv4
           Initiator and Remote Peer during an enrollment process. When
           user certificates are used, the user certificate can be stored
           either on the machine or on a smartcard.

           Since the value of a machine certificate is inversely
           proportional to the ease with which an attacker can obtain one
           under false pretenses, it is advisable that the machine
           certificate enrollment process be strictly controlled. For
           example, only administrators may have the ability to enroll a
           machine with a machine certificate.

           While smartcard certificate storage lessens the probability of
           compromise of the private key, smartcards are not necessarily
           desirable in all situations. For example, some organizations
           deploying machine certificates use them so as to restrict use of
           non-approved hardware. Since user authentication can be provided
           within BGPv4 (keeping in mind the weaknesses described earlier),
           support for machine authentication in IPsec makes it is possible
           to authenticate both the machine as well as the user.

           In circumstances in which this dual assurance is considered
           valuable, enabling movement of the machine certificate from one
           machine to another, as would be possible if the machine
           certificate were stored on a smart card, may be undesirable.

           Similarly, if user certificates are deployed, it is advisable
           for the user enrollment process to be strictly controlled. If

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           for example, a user password can be readily used to obtain a
           certificate (either a temporary or a longer term one), then that
           certificate has no more security value than the password. To
           limit the ability of an attacker to obtain a user certificate
           from a stolen password, the enrollment period can be limited,
           after which password access will be turned off.  Such a policy
           will prevent an attacker obtaining the password of an unused
           account from obtaining a user certificate once the enrollment
           period has expired.

           4.4 Pre-shared keys in IKE

           Use of pre-shared keys in IKE main mode is vulnerable to man-in-
           the-middle attacks when used with dynamically addressed
           Initiators. In main mode it is necessary for SKEYID_e to be used
           prior to the receipt of the identification payload. Therefore
           the selection of the pre-shared key may only be based on
           information contained in the IP header. However, where dynamic
           IP address assignment is used, it is often not possible to
           identify the required pre-shared key based on the IP address.
           The main concern here is in the case of auto-configuration of
           routers by a central administrative unit introducing the new
           equipment into the network.

           Thus when main mode pre-shared keys are used with BGPv4, the
           same pre-shared key is shared by a group of Initiators and is no
           longer able to function as an effective shared secret.  In this
           situation, neither the client nor the server identifies itself
           during IKE phase 1; it is only known that both parties are a
           member of the group with knowledge of the pre-shared key. This
           permits anyone with access to the group pre-shared key to act as
           a man-in-the-middle.

           This vulnerability does not occur in aggressive mode since the
           identity payload is sent earlier in the exchange, and therefore
           the pre-shared key can be selected based on the identity.
           However, when aggressive mode is used the user identity is
           exposed and this is often considered undesirable.

           As a result, where main mode is used with pre-shared keys,
           unless BGPv4 performs mutual authentication, the Remote Peer is
           not authenticated. This enables a rogue Remote Peer in
           possession of the group pre-shared key to successfully
           masquerade as the actual Remote Peer and mount a dictionary
           attack on legacy authentication methods such as CHAP [47]. Such
           an attack could potentially compromise many passwords at a time.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           This vulnerability is widely present in existing IPsec

           To avoid this problem, BGPv4/IPsec implementations SHOULD NOT
           use a group pre-shared key for IKE authentication with main
           mode.  If pre-shared keys are required, then aggressive mode
           SHOULD be used. IKE pre-shared authentication key values SHOULD
           be protected in a manner similar to the user's account password.

           4.5 Use of AES in counter mode

           When AES in counter mode is used, it is important to avoid reuse
           of the counter with the same key, even across all time. Counter
           mode creates ciphertext by XORing generated key stream with
           plaintext. It is fairly easy to recover the plaintext from two
           messages counter mode encrypted under the same counter value,
           simply by XORing together the two packets. The implication of
           this is that it is almost always an error to use IPsec manual
           keying with counter mode, except when the implementation takes
           heroic measures to maintain state across sessions.

           Another counter mode issue is it makes forgery of correct
           packets trivial. Counter mode should therefore never be used
           without also using data authentication.


           Thanks to Bernard Aboba of Microsoft, Steven Chiang, Mark
           Knopper, and Russ White of Cisco Systems and Susan Hares of
           Nexthop for reviewing this draft. Also great thanks goes to all
           the authors of draft-ietf-ips-security-09.txt and RFC 3193 as
           this draft is directly reusing their work and words.

           [1]  Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol
           4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-17.txt, January

           [2]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

           [3]  Kent,S., Atkinson, R., "IP Authentication Header", RFC
           2402, November 1998.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           [4]  Kent,S., Atkinson, R., "IP Encapsulating Security Payload
           (ESP)", RFC 2406, November 1998.

           [5]  Piper, D., "The Internet IP Security Domain of
           Interpretation of ISAKMP", RFC 2407, November 1998.

           [6]  Atkinson, R., Kent, S., "Security Architecture for the
           Internet Protocol", RFC 2401, November 1998.

           [7]  Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
           RFC 2409, November 1998.

           [8]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
           April 1992.

           [9]  Dobbertin, H., "The Status of MD5 After a Recent Attack",
                CryptoBytes Vol.2 No.2, Summer 1996.

           [10] Postel, J., "Transmission Control Protocol", STD 7, RFC
           793, September 1981.

           [11] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
           November 1990.

           [12] Knowles, S., "IESG Advice from Experience with Path MTU
           Discovery", RFC 1435, March 1993.

           [13] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
           for IP version 6", RFC 1981, August 1996.

           [14] Lahey, K., TCP Problems with Path MTU Discovery", RFC 2923,
           September 2000.

           [15] Paxon, V., "End-to-end internet packet dynamics", IEEE
           Transactions on Networking 7,3 (June 1999) pg 277-292.

           [16] Stone J., Partridge, C., "When the CRC and TCP checksum
           disagree", ACM Sigcomm, Sept. 2000.

           [17] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.

           [18] Krueger, M.,, "BGPv4 Requirements and Design
           Considerations", draft-ietf-ips-BGPv4-reqmts-05.txt, Work in
           Progress, July 2001.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           [19] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
           Hashing for Message Authentication", RFC 2104, February 1997.

           [20] Aboba, B., "IPsec-NAT Compatibility Requirements", draft-
           ietf-IPsec-nat-reqts-00.txt, Work in Progress, June 2001.

           [21] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets",
           draft-ietf-IPsec-udp-encaps-00.txt, June 2001

           [22] Dixon, W. et. al., "IPsec over NAT Justification for UDP
           Encapsulation", draft-ietf-IPsec-udp-encaps-justification-
           00.txt, June 2001

           [23] Kivinen, T., et al., "Negotiation of NAT-Traversal in the
           IKE",Internet draft (work in progress), draft-ietf-IPsec-nat-t-
           ike-00.txt, June 2001.

           [24] Madson, C., Glenn, R., "The Use of HMAC-MD5-96 within ESP
           and AH", RFC 2403, November 1998.

           [25] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP
           and AH", RFC 2404, November 1998.

           [26] Rogaway, P., Black, J., "PMAC: Proposal to NIST for a
           parallelizable message authentication code",

           [27] Black, J., Halevi, S., Krawczyk, H., Krovetz, T., Rogaway,
           P., "UMAC: Fast and provably secure message authentication",
           Advancesin Cryptology - CRYPTO '99, LNCS vol. 1666, pp. 216-233.
           Full version available from

           [28] "Descriptions of SHA-256, SHA-384, and SHA-512,"

           [29] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3,
           October 25, 1999.

           [30] U.S. DoC/NIST, "Guidelines for implementing and using the
           nbs data encryption standard", FIPS 74, Apr 1981.

           [31] Biham, E., Shamir, A., "Differential Cryptanalysis of DES-
           like cryptosystems", Journal of Cryptology Vol 4, Jan 1991.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           [32] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher
           Algorithm With Explicit IV", RFC 2405, November 1998.

           [33] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher
           Algorithms", RFC 2451, November 1998.

           [34] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES
           Proposal, June 1998.

           [35] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard
           (AES)", U.S. DoC/NIST, summer 2001.

           [36] "Symmetric Key Block Cipher Modes of Operation,"

           [37] "Recommendation for Block Cipher Modes of Operation",
           National Institute of Standards and Technology (NIST) Special
           Publication 800-XX, CODEN: NSPUE2, U.S. Government Printing
           Office Washington, DC, July 2001.

           [38] Frankel, S., Kelly, S., Glenn, R., "The AES Cipher
           Algorithm and Its Use with IPsec", Internet draft (work in
           progress), draft-ietf-IPsec-ciph-aes-cbc-01.txt, May 2001.

           [39] Etienne, J., "The counter-mode and its use with ESP",
           Internet draft (work in progress), draft-etienne-IPsec-esp-ctr-
           mode-00.txt, May 2001.

           [40] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-MODE encryption",
           Comment on mode of operations NIST, Jan 2001.

           [41] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C.  Hall,
           and N.  Ferguson, "Performance Comparison of the AES

           [42] A. Bosselaers, "Performance of Pentium implementations",

           [43] Bellovin, S., "An Issue With DES-CBC When Used Without
           Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA,
           April 1995.

           [44] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk,
           H., Rogaway, P., "UMAC: Message Authentication Code using

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           Universal Hashing", Internet draft (work in progress), draft-
           krovetz-umac-01.txt, October 2000.

           [45] Frankel, S., Kelly, S., "The Use of SHA-256, SHA-384, and
           SHA-512 within ESP, AH and IKE," Work in progress.

           [46] Dierks, T. and  C. Allen, "The TLS Protocol Version 1.0",
           RFC 2246, November 1998.

           [47] Simpson, W.,"PPP Challenge Handshake Authentication
           Protocol (CHAP)," RFC 1994, August 1996.

           [48] Black, D., "iSCSI Security Requirements and SRP-based ESP
           keys", Internet draft (work in progress), draft-black-ips-iscsi-
           security-00.txt, July 2001.

           [49] Steve Kent, IPsec sequence number extension proposal, IETF

           [50] American National Standard for Financial Services X9.52-
           1998, "Triple Data Encryption Algorithm Modes of Operation",
           American Bankers Association, Washington, D.C., July 29, 1998.

           [51] Bellare, Desai, Jokippi, Rogaway, "A Concrete Treatment of
           Symmetric Encryption: Analysis of the DES Modes of Operation",

           [52] Heffernan, Andy. śśProtection of BGP Sessions via the TCP
           MD5 Signature Option∆∆, Internet draft, draft-ietf-idr-
           rfc2385bis-00.txt, January 2002.

           [53] Chandra, Scudder. śśCapabilities Advertisement with BGP-4∆∆,
           Internet draft, draft-ietf-idr-rfc2842bis-00.txt, August 2002.

           [54] Gulbrandsen , A., . Vixie, P., Esibov, L. "A DNS RR for
           specifying the location of services (DNS SRV)", RFC 2782,
           February 2000.

           [55] Gulbrandsen , A., . Vixie, P., Esibov, L. "A DNS RR for
           specifying the location of services (DNS SRV)", RFC 2782,
           February 2000.

           [56] Patel, B., Aboba, B., Kelly, S., Gupta, V., "DHCPv4
           Configuration of IPsec Tunnel Mode", Internet draft (work in
           progress), draft-ietf-ipsec-dhcp-13.txt, June 2001

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           [57] Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 2373, July 1998.

           [58] Fluhrer, S., "Tunnel Endpoint Discovery", Internet draft
           (work in progress), draft-fluhrer-ted-00.txt, November 2001.

           Author's Addresses

           David Ward
           408 St Peter Street
           Suit 600
           St Paul MN 55102             Phone:  1 612 865 8972

           Intellectual Property Statement

           The IETF takes no position regarding the validity or scope of
           any intellectual property or other rights that might be claimed
           to pertain to the implementation or use of the technology
           described in this document or the extent to which any license
           under such rights might or might not be available; neither does
           it represent that it has made any effort to identify any such
           rights.  Information on the IETF's procedures with respect to
           rights in standards-track and standards- related documentation
           can be found in BCP-11.  Copies of claims of rights made
           available for publication and any assurances of licenses to be
           made available, or the result of an attempt made to obtain a
           general license or permission for the use of such proprietary
           rights by implementors or users of this specification can be
           obtained from the IETF Secretariat.

           The IETF invites any interested party to bring to its attention
           any copyrights, patents or patent applications, or other
           proprietary rights which may cover technology that may be
           required to practice this standard.  Please address the
           information to the IETF Executive

           Full Copyright Statement

           Copyright (C) The Internet Society (2001).  All Rights Reserved.

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           This document and translations of it may be copied and furnished
           to others, and derivative works that comment on or otherwise
           explain it or assist in its implementation may be prepared,
           copied, published and distributed, in whole or in part, without
           restriction of any kind, provided that the above copyright
           notice and this paragraph are included on all such copies and
           derivative works.  However, this document itself may not be
           modified in any way, such as by removing the copyright notice or
           references to the Internet Society or other Internet
           organizations, except as needed for the purpose of developing
           Internet standards in which case the procedures for copyrights
           defined in the Internet Standards process must be followed, or
           as required to translate it into languages other than English.
           The limited permissions granted above are perpetual and will not
           be revoked by the Internet Society or its successors or assigns.
           This document and the information contained herein is provided
           on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET

           Ward              Internet Draft - Expires July 2002 
                                 Securing BGPv4 using IPsec 
February 2002

           Expiration Date

           This memo is filed as <draft-ward-bgpv4-IPsec-00.txt>, and
           expires MM DD, 2002.

           Ward              Internet Draft - Expires July 2002