Internet Draft Lou Berger (LabN)
Category: Standards Track Russ White (Cisco Systems)
Expiration Date: October 30, 2008 Eric Rosen (Cisco Systems)
April 30, 2008
BGP IPSec Tunnel Encapsulation Attributedraft-ietf-softwire-encaps-ipsec-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 30, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The BGP Encapsulation Subsequence Address Family Identifiers (SAFI)
provides a method for the dynamic exchange of encapsulation
information, and the indication of encapsulation protocol types to be
used for different next hops. Currently support for GRE and L2TPv3
tunnel types are defined. This document defines support for IPsec
tunnel types.
Berger, et al. Standards Track [Page 1]

Internet-Draft draft-ietf-softwire-encaps-ipsec-01.txt April 30, 20081. Introduction
The BGP [RFC4271] Encapsulation Subsequence Address Family
Identifiers (SAFI) allows for the communication of tunnel information
and the association of this information to a BGP next hop. The
Encapsulation SAFI can be used to support the mapping of prefixes to
next hops and tunnels of the same address family, IPv6 prefixes to
IPv4 next hops and tunnels using [RFC4798], and IPv4 prefixes to IPv6
next hops and tunnels using [V4NLRI-V6NH]. The Encapsulation SAFI
can also be used to support the mapping of VPN prefixes to tunnels
when VPN prefixes are advertised per [RFC4364] or [RFC4659].
[SOFTWIRES] provides useful context for the use of the Encapsulation
SAFI.
The Encapsulation SAFI is defined in [ENCAPS-SAFI]. [ENCAPS-SAFI]
also defines support for the GRE [RFC2784] and L2TPv3 [RFC3931]
tunnel types. This document builds on [ENCAPS-SAFI] and defines
support for IPsec tunnels. Support is defined for IP Authentication
Header in Tunnel-mode (AH), [RFC4302], and for IP Encapsulating
Security Payload in Tunnel-mode (ESP), [RFC4303]. Support for IP-in-
IP, [RFC2003], and MPLS-in-IP, [RFC4023] protected by IPsec Transport
Mode is also defined.
The Encapsulation NLRI Format is not modified by this document.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. IPsec Tunnel Encapsulation Types
Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel
Encapsulation attribute. This document defines the following tunnel
type values:
- AH in Tunnel-mode: Tunnel Type = 3 [RFC4302]
- ESP in Tunnel-mode: Tunnel Type = 4 [RFC4303]
- IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
[RFC4023]
Berger, et al. Standards Track [Page 3]

Internet-Draft draft-ietf-softwire-encaps-ipsec-01.txt April 30, 2008
- MPLS-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 6
[RFC4023]
Note, see Section 4.3 of [ENCAPS-SAFI] for a discussion on the
advertisement and use of multiple tunnel types.
Note, the specification in [RFC4023] for MPLS-in-IP tunnels with
IPsec Transport mode applies as well to IP-in-IP tunnels.
This document does not specify the use of the sub-TLV types defined
in [ENCAPS-SAFI] with these tunnel types. See below for the
definition of an IPsec tunnel type specific sub-TLV.
3. Use of IPsec
If a R1 is a BGP speaker that receives an Encapsulation SAFI update
from another BGP speaker, R2, then if R1 has any data packets for
which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the
specified "tunnel type", and all such data packets MUST be sent
through that SA.
Let R1 and R2 be two BGP speakers that may send data packets through
R3, such that the data packets from R1 and from R2 may be received by
R3 over the same interface. Then if R3 has sent an update containing
an Encapsulation SAFI, and if this update specifies an IPsec tunnel
type, and if this update is received by R2, and an Encapsulation-SAFI
with an IPsec tunnel type, SHOULD also be received by R1. That is,
on a given interface, if IPsec is required for any data packets, it
SHOULD be required for all. This eliminates dependence on the IPsec
selector mechanisms to correctly distinguish traffic which needs to
be protected from traffic which does not. IPsec does not necessarily
need to be required for control packets that are directly addressed
to R3.
Security policy has the granularity of BGP speaker to BGP speaker.
The required security policies must be configured into the BGP
speakers, and the policy for each SA is negotiated via IKE.
Berger, et al. Standards Track [Page 4]

Internet-Draft draft-ietf-softwire-encaps-ipsec-01.txt April 30, 20084. IPsec Tunnel Authenticator sub-TLV
This document defines a new sub-TLV for use with the Tunnel
Encapsulation Attribute defined in [ENCAPS-SAFI]. The new sub-TLV is
referred to as the "IPsec Tunnel Authenticator sub-TLV" and MAY be
included in any Encapsulation SAFI NLRI ([ENCAPS-SAFI]) indicating a
Tunnel Type defined in this document. Support for the IPsec Tunnel
Authenticator sub-TLV MUST be implemented whenever the tunnel types
defined in this document are implemented. However, its use is
OPTIONAL, and is a matter of policy.
The sub-TLV type of the IPsec Tunnel Authenticator sub-TLV is 3. The
sub-TLV length is variable. The structure of the sub-TLV is as
follows:
- Authenticator Type: two octets
This document defines authenticator type 1, "SHA-1 hash of public
key", as defined in section 3.7 of RFC 4306.
- Value: (variable)
A value used to authenticate the BGP speaker that generated this
NLRI. The length of this field is is not encoded explicitly, but
can be calculated as (sub-TLV length - 2).
In the case of authenticator type 1, this field contains the
20-octet value of the hash.
A BGP speaker which sends the IPsec Tunnel Authenticator sub-TLV with
authenticator type 1 MUST be configured with a private key, public
key pair, the public key being the key whose hash is sent in the
value field of the sub-TLV. The BGP speaker MUST either (a) be able
to generate a self-signed certificate for the public key, or else (b)
be configured with a certificate for the public key.
When the IPsec Tunnel Authenticator sub-TLV is used, it is highly
RECOMMENDED that the integrity of the BGP session itself be
protected. This is usually done by using the TCP MD5 option
[RFC2385].
Berger, et al. Standards Track [Page 5]

Internet-Draft draft-ietf-softwire-encaps-ipsec-01.txt April 30, 20084.1. Use of the IPsec Tunnel Authenticator sub-TLV
If a IPsec Tunnel Authenticator sub-TLV with authenticator type 1 is
present in the Encapsulation SAFI update, then R1 (as defined above
in Section 3) must use IKE to obtain a certificate from R2 (as
defined above in Section 3), and R2 must send a certificate for the
public key whose hash occurred in the value field of the IPsec Tunnel
Authenticator sub-TLV. R1 MUST NOT attempt to establish an SA to R2
UNLESS the public key in the certificate hashes to the same value
that occurs in the IPsec Tunnel Authenticator sub-TLV.
5. Security Considerations
This document uses IP based tunnel technologies to support data plane
transport. Consequently, the security considerations of those tunnel
technologies apply. This document defines support for IPsec AH
[RFC4302] and ESP [RFC4303]. The security considerations from those
documents apply to the data plane aspects of this document.
As with [ENCAPS-SAFI], any modification of the information that is
used to form encapsulation headers, or to choose a tunnel type, or to
choose a particular tunnel for a particular payload type, user data
packets may end up getting misrouted, misdelivered, and/or dropped.
Misdelivery is less of an issue when IPsec is used as such
misdelivery is likely to result in a failure of authentication or
decryption at the receiver. Furthermore, in environments where
authentication of BGP speakers is desired, the IPsec Tunnel
Authenticator sub-TLV defined in Section 4 may be used.
More broadly, the security considerations for the transport of IP
reachability information using BGP are discussed in [RFC4271] and
[RFC4272], and are equally applicable for the extensions described in
this document.
If the integrity of the BGP session is not itself protected, then an
imposter could mount a denial of service attack by establishing
numerous BGP sessions and forcing an IPsec SAs to be created for each
one. However, as such an imposter could wreak havoc on the entire
routing system, this particular sort of attack is probably not of any
special importance.
Berger, et al. Standards Track [Page 6]

Internet-Draft draft-ietf-softwire-encaps-ipsec-01.txt April 30, 20089. Authors' Addresses
Lou Berger
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
Email: lberger@labn.net
Russ White
Cisco Systems
Email: riw@cisco.com
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
Email: erosen@cisco.com
10. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
11. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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
Berger, et al. Standards Track [Page 9]

Internet-Draft draft-ietf-softwire-encaps-ipsec-01.txt April 30, 2008
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Berger, et al. Standards Track [Page 10]