Re: [Idr] BGP Yang - support for ipsec for BGP sessions?

[Susan Hares <[e-mail]>]

Jeff:

I agree with you that it is a partial fit for both the 5.3.1 SAD entry.   If someone does use IKE, I think it is a partial fit (see section 5.2.1).   The purpose behind suggesting we look at the Yang module was because it is a partial fit.  

RFC4301 was simplified because they focused on hosts communication with endpoints or policy wild cards based on the IP flow for the security device.  Because RFC4301 had the full support,  I suggest we send the mismatch message to  the authors of RFC9061 and I2nsf chairs (Yaov Nir and Linda Dunbar). Yaov is a security expert.  Linda has been part of the BGP IPSEC discussions.  

They made a choice to simplify the RFC4301 model for their focus.   With our questions, they may be willing to revise RFC-9061  'ietf-i2nsf-ike' Module and 'ietf-i2nsf-ikeless' models.  If not, we can kick it up to the security ADs to determine how they want to handle this issue.  

Do you want me to dig into the RFC4301 text and try to send the message to the authors of RFC903?  Or this message may be sufficient if time is of the essense. 

At the same time, I note that in the ikeless model the SAD is indexed by name (string) and the spd is index by name (string).   The use of string for the SA and the SPD is appropriate in the BGP model until we determine if this string needs to link the two models together.   

 If you want to see other BGP based examples, look at draft-sajassi-bess-secure-evpn-05.  This draft proposes  download the original information from the RR.  There is not a yang model to manage this proposed feature. 

Sue 


-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Tuesday, January 11, 2022 3:16 PM
To: Susan Hares
Cc: 'Gyan Mishra'; 'Acee Lindem (acee)'; 'idr@ietf. org'
Subject: Re: [Idr] BGP Yang - support for ipsec for BGP sessions?

Sue,

I'll start by saying I'm neither an ipsec expert, and finish by saying my
review of the RFC 9061 YANG modules is somewhat cursory.  I'll frame my
reply in the original context of "Juniper uses an SA-name to select its
ipsec transport mode protection for BGP".

RFC 9061's ietf-i2nsf-ikeless module's sad container has part of the rough
shape one might like to try to satisfy the Juniper use case.  However,
there's some mismatch in desired properties that means that module is not a
full fit for it.  The core issue is discussed in §5.3.1:

: For simplicity, each IPsec SA (sad-entry) contains one Traffic Selector,
: instead of a list of them. The reason is that actual kernel implementations
: only admit a single Traffic Selector per IPsec SA.

In the Juniper implementation, the security-association is effectively a
template that may be leveraged by some number of clients.[1]  So, this is
one part of the mismatch.

The other difficulty is that a traffic-selector requires endpoint
provisioning for validity. (mandatory)  This means that the model has an
interesting dependency ordering problem:
- BGP is typically configured with only the destination address for the
  neighbor.
- The local address may be determined when a session has started.
- If you had the neighbor's config state using the sad-entry name as a
  leafref, it's necessary to have previously configured the sad-entry... but
  the full set of information couldn't have existed at that time.

Implementations rely on some level of wildcard configuration in order to
deal with these scenarios.

Again, this is from cursory review.  Perhaps a full i2nsf model example
might show us how to deal with the "chicken and the egg" issue I think I'm
seeing?

-- Jeff

[1] https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/ref/statement/security-association-edit-security-ipsec.html

On Sat, Jan 08, 2022 at 03:42:16PM -0500, Susan Hares wrote:
> Based on Jeff, Gyan and Acee’s comments – I have few wider questions. 
> 
>  
> 
> If IPSEC is used to provide secure transport/tunnel (MD5 authentication + secure IP + encryption)  specific to a peer,  it seems to point to a BGP peer configuration for the transport/tunnel.  Based on Juniper + Gyan’s comment, this BGP peer configuration process could link to IPSEC security yang structure  
> 
>   
> 
> If IPSEC is automatically sets up a tunnel on an interface, this seems to point to an security function definition (ietf-i2nsf-ike module) definitions.  This seems to me to be outside the BGP realm based on the interface used.   The sanity of the authentication, encryption, hashing, and management depends on tunnels. 
> 
>  
> 
> If the BGP tunnels (RFC9012 + extensions) are configuring  IPSEC connection structures for tunnels, where does this configuration lie?  Is this structure a BGP main module structure, a RFC9012 Yang module, or something else?  
> 
>  
> 
> What prevents these 3 options from conflicting in implementations?
> 
>  
> 
> These are not the only three cases.  The BESS Draft  <https://datatracker.ietf.org/doc/draft-sajassi-bess-secure-evpn/> aft-sajassi-bess-secure-evpn-05.txt suggest a different combination of this for EVPN.   
> 
>  
> 
> It would be good to know how these interact in today’s implementations.   
> 
>  
> 
> Sue 
> 
>  
> 
>  
> 
> From: Idr [mailto:[e-mail]] On Behalf Of Gyan Mishra
> Sent: Tuesday, December 28, 2021 7:38 PM
> To: Acee Lindem (acee)
> Cc: idr@ietf. org
> Subject: Re: [Idr] BGP Yang - support for ipsec for BGP sessions?
> 
>  
> 
>  
> 
>  
> 
> On Tue, Dec 28, 2021 at 7:21 PM Acee Lindem (acee) <[e-mail]> wrote:
> 
>  
> 
>  
> 
> From: Idr <[e-mail]> on behalf of Gyan Mishra <[e-mail]>
> Date: Tuesday, December 28, 2021 at 7:05 PM
> To: Jeff Haas <[e-mail]>
> Cc: IDR List <[e-mail]>
> Subject: Re: [Idr] BGP Yang - support for ipsec for BGP sessions?
> 
>  
> 
> Hi Jeff
> 
>  
> 
> SA is a security association between the IPSEC Net to Net VPN router tunnel endpoints that defines encryption algorithm and AH and/or ESP and key exchange.  
> 
>  
> 
> I think Junipers implementation the way I read is a Net to Net VPN between two routers and routing protocol BGP is included in the IPSEC ACL defining the interesting traffic transport tunnel mode.  That is what the direct association to peering sessions essentially putting the peers inside the tunnel instead of outside the tunnel.
> 
>  
> 
> Transport mode and tunnel mode are two separate encapsulations. There is no tunnel for the former. AFAIK, “traffic transport tunnel mode” doesn’t exist as a standard. 
> 
>  
> 
> See https://www.rfc-editor.org/rfc/rfc4301.html#section-3.3
> 
>  
> 
> As an example of transport mode IPsec, see https://datatracker.ietf.org/doc/rfc4552/
> 
>  Gyan> Understood.  I was referring to IPSEC tunnel itself not a physical tunnel VTI in tunnel mode,  which still has the two router endpoints based on the encryption domain whether it’s tunnel or transport mode is irrelevant.  
> 
> Thanks,
> 
> Acee
> 
>  
> 
> Cisco XE can perform the exact same permitting BGP in the IPSEC ACL for Net to Net VPN so BGP session is encrypted within the transport tunnel.  So the BGP session is inside the tunnel and not outside the tunnel.
> 
>  
> 
> I don’t think IPSEC for BGP should be included in the BGP Yang mode as we are not encrypting the peer itself as we need a Security Zone  which is part of the IPSEC framework not BGP.  
> 
>  
> 
> If a vendor had a knob that could encrypt the TCP session similar to per peer level password authentication then I agree that it should be included.
> 
>  
> 
> IPv6 unlike IPv4 has IPSEC security mandated in the IPv6 specification via AH and ESP  Extension Headers but is not automatically implemented and requires IKE configuration.
> 
>  
> 
> So for IPv6 as well I don’t believe any vendor supports BGP IPSEC peering.
> 
>  
> 
> Kind Regards 
> 
>  
> 
> Gyan
> 
>  
> 
> On Tue, Dec 28, 2021 at 10:47 AM Jeffrey Haas <[e-mail]> wrote:
> 
> [Reference: https://github.com/mjethanandani/ietf-bgp-yang/issues/59]
> 
>  
> 
> The underlying modeling question here was originally, "what does the sa name mean".  But the real question here is perhaps, "What implementations of BGP support ipsec for BGP sessions?"
> 
>  
> 
> Juniper's implementation supports as part of BGP configuration direct association for transport mode ipsec for individual peering sessions.  Of course, even without such configuration, if ipsec is used to protect connectivity between the endpoints in tunnel mode, BGP just uses that automatically.
> 
>  
> 
> Does anyone else's implementation have similar functionality?  If so, please provide a pointer to your configuration so we can decide what to do with the IETF model for this option.
> 
>  
> 
> Thanks,
> 
>  
> 
> - Jeff with his BGP YANG author hat on...
> 
>  
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> 
> -- 
> 
>  <http://www.verizon.com/> Error! Filename not specified.
> 
> Gyan Mishra
> 
> Network Solutions Architect 
> 
> Email [e-mail]
> 
> M 301 502-1347
> 
>  
> 
> -- 
> 
>  <http://www.verizon.com/> 
> 
> Gyan Mishra
> 
> Network Solutions Architect 
> 
> Email [e-mail]
> 
> M 301 502-1347
> 
>  
>