Internet DRAFT - draft-ward-bgp-ipsec
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
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.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document discusses how BGPv4 may utilize IPsec to provide
authentication, integrity, confidentiality and replay
protection.
Table of Contents
Status of this Memo.........................................1
Copyright Notice............................................1
Abstract....................................................1
Ward Internet Draft - Expires July 2002
1
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
Acknowledgments............................................22
References.................................................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
2
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
connection.
Ward Internet Draft - Expires July 2002
3
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
reset.
[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
4
Securing BGPv4 using IPsec
February 2002
versions of IPSec and ESP with NULL encryption has the same
functionality.
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
requirement.
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)
Where:
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
5
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
6
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],
[35]:
Ward Internet Draft - Expires July 2002
7
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:
PMAC
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
BGP.
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
8
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
9
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
10
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
process.
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
11
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
12
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 nave 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
13
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
14
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
address.
[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
section.
[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
15
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
[57].
Ward Internet Draft - Expires July 2002
16
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
17
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
18
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
SA.
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
19
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
20
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
21
Securing BGPv4 using IPsec
February 2002
This vulnerability is widely present in existing IPsec
implementations.
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.
Acknowledgments
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.
References
[1] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol
4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-17.txt, January
2002.
[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
22
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., et.al., "BGPv4 Requirements and Design
Considerations", draft-ietf-ips-BGPv4-reqmts-05.txt, Work in
Progress, July 2001.
Ward Internet Draft - Expires July 2002
23
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",
http://csrc.nist.gov/encryption/modes/proposedmodes/pmac/pmac-
spec.pdf
[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
http://www.cs.ucdavis.edu/~rogaway/umac
[28] "Descriptions of SHA-256, SHA-384, and SHA-512,"
http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf.
[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
24
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.
http://csrc.nist.gov/encryption/aes/round2/AESAlgs/Rijndael/Rijn
dael.pdf
[35] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard
(AES)", U.S. DoC/NIST, summer 2001.
[36] "Symmetric Key Block Cipher Modes of Operation,"
http://www.nist.gov/modes.
[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
Submissions", http://www.counterpane.com/AES-performance.html
[42] A. Bosselaers, "Performance of Pentium implementations",
http://www.esat.kuleuven.ac.be/~bosselae/
[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
25
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.
[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",
1997, http://www-cse.ucsd.edu/users/mihir/
[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
26
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
Cisco
408 St Peter Street
Suit 600
St Paul MN 55102 Phone: 1 612 865 8972
Email: dward@cisco.com
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
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Ward Internet Draft - Expires July 2002
27
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
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Ward Internet Draft - Expires July 2002
28
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
29
