case ipsec

[mjethanandani]

One of the YANG doctors comments to the "case ipsec" on page 25 (or thereabouts) was:

3. Page 25, "case ipsec": What is the reference for usage of transport
   mode IPsec with BGP? Please elaborate in description.

When asked for a text or a reference the response from Acee was:

Since there no IETF RFC specifically describing BGP IPsec, I think some brief text on the intension here is required. Does this simply provision a transport mode SA for the BGP 5-tuple? I’m thinking one of the co-authors could do this. I’d suggest Jeff Haas since it appears Juniper supports this…

To which Jeff responded:

There is no reference here. Multiple BGP implentations support running BGP over an ipsec tunnel. A previous prod during a prior review suggested that if we had something to use from an IETF group doing yang work on ipsec for protecting routing transport sessions might be applicable here.

Acee shot back with:

If this is an IPsec tunnel then it would be provisioned like other IPsec tunnels as opposed to in the BGP YANG model. I'm assuming that if it is provisioned here, it is transport mode BGP for the TCP session associated with the BGP peer. In any case, the intended usage needs to be specified.

What text, if any can be added here to describe the intended usage?

[jhaas-pfrc]

The current text is below: case ipsec { leaf sa { type string; description "Security Association (SA) name."; } description "Currently, the IPsec/IKE YANG model has no grouping defined that this model can use. When such a grouping is defined, this model can import the grouping to add the key parameters need

The related juniper feature simply says to associate the bgp session with an externally provisioned transport session via its SA:

https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/ip_security.html#id-understanding-ipsec-for-bgp

Perhaps the following description text? "Associate the BGP session with an externally provisioned IPsec Security Association whose name is identified by this node."

[suehares]

Overview I'm not sure you are correct that there is not any work on IPsec tunnels or IP-sec associations. I2NSF took on IPsec tunnels and IPSECme is working on tunnel model IPsec. I think these models have enough to provide the basic tunnel for IDR

We are in an interim state for the BGP IPSEC support;

RFC 9012 (Tunnel-encaps) replaced the RFC5566 and RFC 5512 Text from RFC9012 is: This specification obsoletes RFC 5566. This has the effect of, in turn, deprecating a number of code points defined in that document. In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry [IANA-BGP-TUNNEL-ENCAP], the following code points have been marked as deprecated: "Transmit tunnel endpoint" (type code 3), "IPsec in Tunnel-mode" (type code 4), "IP in IP tunnel with IPsec Transport Mode" (type code 5), and "MPLS-in-IP tunnel with IPsec Transport Mode" (type code 6). In the "BGP Tunnel Encapsulation Attribute Sub- TLVs" registry [IANA-BGP-TUNNEL-ENCAP], "IPsec Tunnel Authenticator" (type code 3) has been marked as deprecated. See Section 14.2.

We have 3 drafts under consideration (BESS and IDR) are considering what do about re-engaging the IPSEC tunnel. Adoption of IDR document is in process.

https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-edge-discovery/ (adoption request) https://datatracker.ietf.org/doc/draft-sajassi-bess-secure-evpn/ (individual draft)

[suehares]

I need to walk through with you what is missing in the I2NSF model for ipsec mode encaps or tunnels.

I2NSF Model: typedef ipsec-mode { type enumeration { enum transport { description "IPsec transport mode. No Network Address Translation (NAT) support."; } enum tunnel { description "IPsec tunnel mode."; } } description "Type definition of IPsec mode: transport or tunnel."; reference "Section 3.2 in RFC 4301."; } Groupings in model: grouping ipsec-policy-grouping { description "Holds configuration information for an IPsec SPD entry.";

grouping encap { description "This group of nodes allows to define the type of encapsulation in case NAT traversal is required and includes port information."; leaf espencap { type esp-encap; default none; description "ESP in TCP, ESP in UDP or ESP in TLS."; .... } grouping tunnel-grouping { description "The parameters required to define the IP tunnel endpoints when IPsec SA requires tunnel mode. The tunnel is defined by two endpoints: the local IP address and the remote IP address."; ..}

  grouping selector-grouping {
    description
      "This grouping contains the definition of a Traffic
      Selector, which is used in the IPsec policies and
      IPsec SAs.";

  grouping lifetime {
    description
      "Different lifetime values limited to an IPsec SA.";
    leaf time 

 grouping port-range  {
    description
      "This grouping defines a port range, such as
      expressed in RFC 4301. For example: 1500 (Start
      Port Number)-1600 (End Port Number).
      A port range is used in the Traffic Selector.";

============

IPSECme draft

1) https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/

This document defines configuration and operational parameters of IP traffic flow security (IP-TFS). IP-TFS, defined in [I-D.ietf-ipsecme-iptfs], defines a security association for tunnel mode IPsec with characteristics that improve traffic confidentiality and reduce bandwidth efficiency loss. These documents assume familiarity with IP security concepts described in [RFC4301].

This model uses the following model from I2NSF: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 (RFC -Auth-48 model)

[suehares]

RFC5566 describes the following BGP IPSec tunnel model modes: 3 Transmit tunnel endpoint [RFC5566] 4 IPsec in Tunnel-mode [RFC5566] 5 IP in IP tunnel with IPsec Transport Mode [RFC5566] 6 MPLS-in-IP tunnel with IPsec Transport Mode [RFC5566]

These tunnel model modes have been deprecated with RFC 9012.

This note is just to make sure this fact is available for our discussion today

[suehares]

  the text that the original information is querying about is the following text

          case ipsec {
               leaf sa {
                 type string;
                 description
                   "Security Association (SA) name.";
               }
               description
                 "Currently, the IPsec/IKE YANG model has no
                  grouping defined that this model can use. When
                  such a grouping is defined, this model can import
                  the grouping to add the key parameters
                  needed to kick of IKE.";
             }

[suehares]

Potential text

         case ipsec {
               leaf sa {
                 type string;
                 description
                   "Security Association (SA) name.";
               }
               description
                 "The current IPSec/IKE yang models related models are:  
                   ietf-i2nsf-ike  - which has a name for a pad (pad-entry), 
                      a connection (conn-entry), and child sa-groups (child-sa-info).
                   The name specified links to a security assocation (sa) name
                   In an IPSec transport connection over which the BGP runs, 
                  and allows the connection the necessary information to 
                  needed to kick of IKE.

                  This reference does not refer to the BGP tunnel encapsulation 
                  using IP sec under RFC9012. RFC9012 no longer supports 
                  IP-sec tunnel models, and obsoletes RFC5566. 
                  RFC5566 supported the following models: 
                  a) IP-Sec tunnel mode, b) IP in IP with IP sec transport 
                  c) MPLS in IP with IP sect transport. ";
             }

[suehares]

   Recommended text 
 case ipsec {
           leaf sa {
             type string;
             description
               "Security Association (SA) name.";
           }
           description
             "The current IPSec/IKE yang models related models are:  
               ietf-i2nsf-ike  - which has a name for a pad (pad-entry), 
                  a connection (conn-entry), and child sa-groups (child-sa-info).
               The name specified links to a security assocation (sa) name
               In an IPSec transport connection over which the BGP runs, 
              and allows the connection the necessary information to 
              needed to kick of IKE.

              This reference does not refer to the BGP tunnel encapsulation 
              using IP sec under RFC9012. RFC9012 no longer supports 
              IP-sec tunnel models, and obsoletes RFC5566."; 
         }

[jhaas-pfrc]

Per IDR discussion, we'll remove the current ipsec leaf. Vendors, particularly Juniper, can augment in a leaf that matches local semantics.

A separate issue will be opened for providing IETF model supported transport session with ipsec.