One document matched: draft-berger-idr-encaps-ipsec-00.txt
Internet Draft Lou Berger (LabN)
Category: Standards Track Russ White (Cisco Systems)
Expiration Date: May 9, 2008
November 9, 2007
BGP IPSec Tunnel Encapsulation Attribute
draft-berger-idr-encaps-ipsec-00.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 May 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 supported. This document defines support for IPsec
tunnel types.
Berger and White Standards Track [Page 1]
Internet-Draft draft-berger-idr-encaps-ipsec-00.txt November 9, 2007
Contents
1 Introduction .............................................. 3
1.1 Conventions used in this document ......................... 3
2 IPsec Tunnel Encapsulation Types .......................... 4
3 IPsec Tunnel Encapsulation Attributes ..................... 4
3.1 Encapsulation sub-TLV ..................................... 4
3.2 No-Label sub-TLV .......................................... 5
3.3 Alternate Address sub-TLV ................................. 6
4 Security Considerations ................................... 6
5 IANA Considerations ....................................... 7
6 References ................................................ 7
6.1 Normative References ...................................... 7
6.2 Informative References .................................... 8
7 Acknowledgments ........................................... 9
8 Authors' Addresses ........................................ 9
9 Full Copyright Statement .................................. 9
10 Intellectual Property ..................................... 9
Berger and White Standards Track [Page 2]
Internet-Draft draft-berger-idr-encaps-ipsec-00.txt November 9, 2007
1. 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 defined 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]. Two IPsec tunnel
specific tunnel attributes are also defined in this document. The
first tunnel attribute is used to identify whether an inner MPLS
should not be used when IPsec tunnels are used with BGP/MPLS IP VPNs.
The other tunnel attribute defined in this document provides an
optimized method for the advertisement of tunnels that support the
identical reachability information. Such tunnels are more likely to
occur in the IPsec context to overcome performance limitation of
IPsec forwarding hardware. These tunnels may be identified by
different IP addresses or the same IP address with additional context
(such as provided for in section 3.1). Such tunnels provide "equal
cost" next hops.
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].
Berger and White Standards Track [Page 3]
Internet-Draft draft-berger-idr-encaps-ipsec-00.txt November 9, 2007
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: Tunnel Type = 3
- ESP: Tunnel Type = 4
Note, see Section 4.3 of [ENCAPS-SAFI] for a discussion on the
advertisement and use of multiple tunnel types.
The sub-TLV types defined in [ENCAPS-SAFI] MAY be used with the AH
and ESP tunnel types. The following Sub-TLV types are also defined
for use with both tunnel types:
- No-label: sub-TLV type = 3
- Alternate address: sub-TLV type = 4
Except where explicitly modified by this document, the processing of
messages carrying Encapsulation NLRIs containing the AH and ESP
tunnel types MUST follow [ENCAPS-SAFI].
3. IPsec Tunnel Encapsulation Attributes
The Encapsulation, Protocol type, No-label and Alternate address
attributes (sub-TLV types) MAY be used with the AH and ESP tunnel
types. The Protocol type is defined in [ENCAPS-SAFI] and is
unmodified by this document. The other attributes are described in
this section.
3.1. Encapsulation sub-TLV
The syntax and semantics of the encapsulation sub-TLV is the same for
both AH and ESP tunnels. When present for AH and ESP tunnel types,
the Encapsulation sub-TLV indicates the Security Parameters Index
(SPI) to use in the AH or ESP tunnel header when sending payload
packets to the associated next hop. It is intended to be used for
identifying extra context information about the received payload.
When the tunnel type of the TLV is AH or ESP, the following is the
structure of the value field of the encapsulation sub-TLV
Berger and White Standards Track [Page 4]
Internet-Draft draft-berger-idr-encaps-ipsec-00.txt November 9, 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC4302] and [RFC4303] for the respective definitions of SPI
in the context of AH and ESP tunnels.
Note that use of the Encapsulation sub-TLV with AH and ESP tunnels is
OPTIONAL. Unless an SPI value is being used to provided extra
context, i.e., more than one SPI is advertised for the next hop, the
encapsulation sub-TLV MUST NOT be present.
3.2. No-Label sub-TLV
When the tunnel type of the TLV is AH or ESP, the No-label sub-TLV is
defined. The No-label sub-TLV has no additional information and
consists solely of the Sub-TLV Type (3) and Sub-TLV Length (2).
The No-label sub-TLV is only relevant when prefix information is
advertised with an MPLS label per [RFC4364] or [RFC4659]. The use of
the No-label sub-TLV is OPTIONAL. When present, the No Label sub-TLV
indicates that additional MPLS encapsulation MUST NOT be added by the
ingress when sending payload packets to the associated next hop. When
prefixes are not advertised with an associated MPLS label, the No-
label sub-TLV SHOULD NOT be present. The No-label sub-TLV MUST NOT
be present when the advertised MPLS label is to be used.
The No-label sub-TLV is present, the MPLS label value MAY be set to
the implicit NULL Label (3, per [RFC3032]) or be used as a token to
identify the next hop. When used as a token, all prefixes advertised
with the different Next Hop fields SHOULD have the different label
(token) values. Such usage can facilitate withdraw when the same
prefix is advertised to with multiple next hops.
Note, the same result MAY be achieved by advertising a prefix per
[RFC4364] or [RFC4659] with the implicit NULL Label (3, per
[RFC3032]) without this OPTIONAL sub-TLV.
Berger and White Standards Track [Page 5]
Internet-Draft draft-berger-idr-encaps-ipsec-00.txt November 9, 2007
3.3. Alternate Address sub-TLV
When the tunnel type of the TLV is AH or ESP, the Alternate address
sub-TLV is defined. The Alternate address sub-TLV is used to provide
an additional destination tunnel end-point IP address. When this
sub-TLV is present, the address provided in the sub-TLV along with
the address provided in the next hop Tunnel Address field and any
other Alternate address Sub-TLVs SHOULD be used as "equal cost" next
hops. Multiple Alternate address Sub-TLVs MAY be included in a
Tunnel Encapsulation attribute. The format of the Alternate address
Sub-TLV is:
+---------------------------+
| AA (variable) |
+---------------------------+
Alternate Address (AA):
The Alternate Address (AA) field contains an IPv4 or IPv6
address. The size of the field is reflected in the Sub-TLV
Length field and is dependent on the address type. The size of
the AA field MUST be 4 octets when an IPv4 address is
represented and 16 octets when an IPv6 address is represented.
The use of the Alternate address sub-TLV is OPTIONAL. A BGP speaker
may maintain (and advertise to its peers) more than one route to a
given destination. Each of these routes can be advertised using
separate NLRIs with different Network Address of Next Hops, or via
the Alternate address Sub-TLV. Note that when the Alternate address
Sub-TLV is used, all next hops included in the same advertisement
will share the same next hop field and can only be withdrawn as a
group.
4. 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
Berger and White Standards Track [Page 6]
Internet-Draft draft-berger-idr-encaps-ipsec-00.txt November 9, 2007
decryption at the receiver.
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.
5. IANA Considerations
IANA is requested to administer assignment of new namespaces and new
values for namespaces defined in this document and reviewed in this
section.
Upon approval of this document, the IANA will make the assignment in
the Tunnel TLVs and sub-TLVs section the registry.
Tunnel Type Reference
----------- ---------
AH: Type = 3 [This document]
ESP: Type = 4 [This document]
Tunnel Type Sub-TLV Type Reference
------ ---- ------------ ---------
AH/ESP Encapsulation: type = 1 [This document]
AH/ESP Protocol type: type = 2 [ENCAPS-SAFI]
AH/ESP No-label: type = 3 [This document]
AH/ESP Alternate address: type = 4 [This document]
6. References
6.1. Normative References
[ENCAPS-SAFI] Mohapatra, P., Rosen, E., "BGP Information SAFI
and BGP Tunnel Encapsulation Attribute", Work in
Progress, draft-ietf-idr-encaps-safi-00.txt,
August 2007.
[RFC3032] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter,
D. Farinacci, T. Li, and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC4271] Rekhter, Y., Ed. et al, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
Berger and White Standards Track [Page 7]
Internet-Draft draft-berger-idr-encaps-ipsec-00.txt November 9, 2007
6.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[RFC2784] Farinacci, D., et al, "Generic Routing Encapsulation
(GRE)", RFC 2784, March 2000.
[RFC3931] Lau, J., Ed., et al, "Layer Two Tunneling Protocol -
Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)"
RFC 4303, December 2005.
[RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4659] De Clercq, J., et al, "BGP-MPLS IP Virtual Private
Network (VPN) Extension for IPv6 VPN", RFC 4659,
September 2006.
[RFC4798] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS using IPv6
Provider Edge Routers (6PE)", RFC 4798, February 2007.
[SOFTWIRES] Wu, J. et al, "Softwire Mesh Framework", Work in
Progress, draft-ietf-softwire-mesh-framework-02.txt,
July 2007.
[V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI
with an IPv6 Next Hop", Work in Progress,
draft-ietf-idr-v4nlri-v6nh-01.txt, October 2007.
Berger and White Standards Track [Page 8]
Internet-Draft draft-berger-idr-encaps-ipsec-00.txt November 9, 2007
7. Acknowledgments
The extension of the Encapsulation NLRI to support IPsec tunnels was
suggested by Eric Rosen (as an alternative to draft-berger-l3vpn-ip-
tunnels-01.txt.) This document takes some text and concepts from
draft-berger-l3vpn-ip-tunnels-01.txt which was co-authored with Ron
Bonica.
8. 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
9. Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
10. 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.
Berger and White Standards Track [Page 9]
Internet-Draft draft-berger-idr-encaps-ipsec-00.txt November 9, 2007
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
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 and White Standards Track [Page 10]
Generated on: Fri Nov 9 16:44:33 EST 2007
| PAFTECH AB 2003-2026 | 2026-04-24 01:30:02 |