idr J. Hu
Internet-Draft Nokia
Intended status: Standards Track October 10, 2019
Expires: April 12, 2020

BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration
draft-hujun-idr-bgp-ipsec-transport-mode-00

Abstract

This document defines a method of using BGP to advertise IPsec transport mode protected tunnel (like GRE tunnel with IPsec transport mode protection) configuration along with NLRI, based on [I-D.ietf-idr-tunnel-encaps] and [I-D.hujun-idr-bgp-ipsec].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on April 12, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

[I-D.hujun-idr-bgp-ipsec] defines a method of using BGP to advertise configuration for IPsec tunnel with ESP tunnel mode, however there are other use cases require of using IPsec/ESP transport mode with other types of IP tunnel, like GRE tunnel, as defined in [RFC4301] and [RFC4303]. Figure 2 shows an example of IPv4 GRE tunnel packet with ESP transport mode protection. This document defines a method of using BGP to advertise configuration for these use cases.

             ----------------------------------------------------
             |IPv4 header  | ESP | GRE | Payload |   ESP   | ESP|
             |(any options)| Hdr | Hdr | Packet  | Trailer | ICV|
             ----------------------------------------------------
                                       |<-- encryption --->|
                                 |<-------- integrity ---->|

Figure 1: IPv4 GRE tunnel packet with ESP transport protection

The method follows same principle as [I-D.hujun-idr-bgp-ipsec], keep changes to BGP minimal and not changing IKEv2/IPsec; however the IPsec transport mode protected IP tunnel is not a tunnel stack or nested tunnels, IPsec transport mode protection doesn't add extra IP header.

The requirement of using IPsec transport mode is signaled by including a sub-TLV: IPsec transport protected, in a BGP tunnel encapsulation TLV.

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2. IPsec Transport Protected sub-TLV

This sub-TLV represents using IPsec transport mode protection for the tunnel specified by parent tunnel encapsulation TLV, its value is a IPsec configuration tag as defined in [I-D.hujun-idr-bgp-ipsec].

                       +--------------------------------------+
                       |   IPsec Configuration tag (4 octets) |
                       +--------------------------------------+

Figure 2: IPsec Configuration Tag

For a given tunnel encapsulation TLV, IPsec configuration tag sub-TLV MUST appear only one time.

2. Semantics and Operation

Except for what this document explicitly specifies, the semantics and operation of tunnel encapsulation TLV with IPsec Transport Protected sub-TLV are same as defined in [I-D.ietf-idr-tunnel-encaps] and [I-D.hujun-idr-bgp-ipsec].

IPsec Transport Protected sub-TLV MAY be included in any type of IP tunnel TLV specified in [I-D.ietf-idr-tunnel-encaps]; it MUST be ignored when included in a IPsec tunnel TLV.

The inclusion of IPsec Transport Protected TLV and its value is determined by local policy.

Following are the rules of operations:

  1. All routers are pre-provisioned with Mapping between IPsec configuration tag value and IPsec configurations include authentication method/credentials
  2. If a given NLRI needs a specific tunnel encapsulation with IPsec transport mode protection, then advertising router need to include an IPsec Transport Protected sub-TLV with required configuration tag, in the corresponding tunnel encapsulation TLV/attribute, along with the NLRI in BGP UPDATE U;
  3. When a router need to forward a packet along a path is determined by a BGP UPDATE which has a tunnel encapsulation attribute that contains one or more tunnel TLV, router selects a tunnel TLV based on Semantics defined in [I-D.ietf-idr-tunnel-encaps], if the selected tunnel TLV contains IPsec Transport Protected sub-TLV, then the router use first feasible CHILD_SA for IP tunnel packet encryption, a CHILD SA is considered as feasible when it meets all following conditions:
  4. If router can't find such CHILD SA, then it will use IKEv2 to create one with following IPsec configuration:

3. IANA Considerations

This document will request new values in IANA "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for IPsec Transport Protected sub-TLV.

4. Security Considerations

IKEv2 is used to create IPsec tunnel, which ensures following:

There is concern that malicious party might manipulate IPsec tunnel encapsulation attribute to divert traffic, however this risk could be mitigated by IKEv2 mutual authentication.

BGP route filter include outbound route filter [RFC5291], Origin Validation [RFC6811] and BGPSec [RFC8205] could be used to further secure BGP UPDATE message.

IKEv2 cookie [RFC7296] and varies mechanisms defined including client puzzle defined in [RFC8019] could be used to protect IKEv2 from Distributed Denial-of-Service Attacks.

Follow latest IETF ESP/IKEv2 implementation requirement and guidance ([RFC8221] and [RFC8247] at time of writing) to make sure always using secure and up-to-date cryptographic algorithms;

5. Change Log

6. References

6.1. Normative References

[I-D.hujun-idr-bgp-ipsec] Hu, J., "BGP Provisioned IPsec Tunnel Configuration", Internet-Draft draft-hujun-idr-bgp-ipsec-01, September 2019.
[I-D.ietf-idr-tunnel-encaps] Patel, K., Velde, G. and S. Ramachandra, "The BGP Tunnel Encapsulation Attribute", Internet-Draft draft-ietf-idr-tunnel-encaps-14, September 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

6.2. Informative References

[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, August 2008.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R. and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P. and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014.
[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks", RFC 8019, DOI 10.17487/RFC8019, November 2016.
[RFC8205] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017.
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y. and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017.
[RFC8247] Nir, Y., Kivinen, T., Wouters, P. and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, DOI 10.17487/RFC8247, September 2017.

Author's Address

Hu Jun Nokia 777 East Middlefield Road Mountain View, CA 95148 United States EMail: jun.hu@nokia.com