BGP Provisioned IPsec Transport Mode Protected Tunnel ConfigurationNokia777 East Middlefield RoadMountain ViewCA 95148United Statesjun.hu@nokia.com
routingidrThis 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 and . 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 and . 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.The method follows same principle as , 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.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 when, and only when,
they appear in all capitals, as shown here.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 .For a given tunnel encapsulation TLV, IPsec configuration tag sub-TLV MUST appear only one time.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 and .IPsec Transport Protected sub-TLV MAY be included in any type of IP tunnel TLV specified in ; 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:All routers are pre-provisioned with Mapping between IPsec configuration tag value and IPsec configurations include authentication method/credentialsIf 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;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 , 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:
it is ESP transport modeits private and public routing instance is same as routing instance in which the packet to be forwardedits peer tunnel address is same as indicated by Remote Endpoint sub-TLVthe source and destination address of the packet to be forwarded falls in the range of CHILD SA's traffic selectorits transform and other configuration maps to the tag indicated in the IPsec configuration tag sub-TLVIf router can't find such CHILD SA, then it will use IKEv2 to create one with following IPsec configuration:
ESP transport modeprivate and public routing instance is the routing instance in which the packet to be forwardedpeer tunnel address is specified by Remote Endpoint sub-TLVlocal traffic selector:
address range: local tunnel endpoint addressprotocol: tag mapped configurationport range: tag mapped configurationremote traffic selector:
address range: address in Remote Endpoint sub-TLV of selected tunnel encapsulation TLVprotocol: tag mapped configurationport range: tag mapped configurationother configurations come from mapping of the configuration tag in IPsec Transport Protected sub-TLV of selected tunnel encapsulation TLVThis document will request new values in IANA "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for IPsec Transport Protected sub-TLV.IKEv2 is used to create IPsec tunnel, which ensures following:Traffic protection keys are generated dynamically during IKEv2 negotiation, only known by participating peer of the IPsec tunnel; there is no central node to manage and distribute all keys.IKEv2 rekey mechanism refresh keys regularly; PFS(Perfect Forward Secrecy) provides additional protection;Secure authentication mechanism that only allow authenticated peer to create tunnelTraffic Selector guarantee that only agreed traffic is allowed to be forwarded within the IPsec tunnel;Using a separate, dedicate protocol(IKEv2) for key management/authentication ensure they are not tied to BGP, all existing and future IKEv2 features could be used without changing BGP;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 , Origin Validation and BGPSec could be used to further secure BGP UPDATE message.IKEv2 cookie and varies mechanisms defined including client puzzle defined in could be used to protect IKEv2 from Distributed Denial-of-Service Attacks.Follow latest IETF ESP/IKEv2 implementation requirement and guidance ( and at time of writing) to make sure always using secure and up-to-date cryptographic algorithms;v00 Sep 29, 2019: initial draft