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

From: "Susan Hares" <[email-masked]>
Date: Sat, 8 Jan 2022 15:41:55 -0500

Jeff: 

Thank you for asking about the IPSEC Yang module.  

RFC 9061 defines two IPSEC related Yang modules.  The first module
(ietf-i2nsf-ikec) is a set of common definitions.  The second module
(ietf-i2nsf-ike) provides specific configuration for PAD, SPD (including
SA), connection set-up, and child-SA processes. These definitions are to be
an interface to security functions in a device. 

Section 5.1 provides the Yang for ietf-i2nsf-ikec including the definition
of transport and tunnel model.  

Section 5.2 provides the definition for PAD, SPD, connection, and child-SA
processing.  

Since the IPSEC experts worked on this module, it may be useful to check to
see if the transport and tunnel  mode definitions are useful.   BGP tunnels
(RFC 9012) or VPNS may use the tunnel mode.  

My reading of the second yang module (ietf-i2nsf-ike) is that it provide
configuration and operational state for the IPSEC security functions.  I
welcome other people's input. 

Perhaps a pointer to the connection structure would be sufficient for the
BGP peer.  

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, December 28, 2021 10:47 AM
To: idr@ietf. org
Subject: [Idr] BGP Yang - support for ipsec for BGP sessions?

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

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 8 Jan 2022 15:42:16 -0500

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:[email-masked]] 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) <[email-masked]> wrote:

From: Idr <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Tuesday, December 28, 2021 at 7:05 PM
To: Jeff Haas <[email-masked]>
Cc: IDR List <[email-masked]>
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 <[email-masked]> wrote:

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,

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

-- 

 <http://www.verizon.com/> Error! Filename not specified.

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

-- 

 <http://www.verizon.com/> 

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 Jan 2022 15:15:56 -0500

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 Jan 2022 17:48:54 -0500

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:[email-masked]] 
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,

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 Jan 2022 18:52:25 -0500

Sue,

On Tue, Jan 11, 2022 at 05:48:54PM -0500, Susan Hares wrote:
> 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.  

I'm not aware of general use of IKE for routing protocols.  That was a large
portion of the discussion of the KARP Working Group about using IPsec for
routing protocols - the bootstrapping issues of needing IP to be running and
routing before you might be able to leverage things like IKE.

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

I'm certainly willing to discuss the topic about how to improve these models
for use for routing applications with the other group.  Let's discuss that
later.

That said, the practical question I started with was what we should do about
the existing leaf in the BGP model.  IDR inherited that originally from the
OpenConfig model and they're not worrying about how it plumbed into other
bits of yang.  I believe they simply were providing the convenient hook for
my employer.

If no other implementation makes use of this feature, it's probably
reasonable for us to remove it from the core IDR BGP model for the time
being.  

Once we have a IPsec model suitable for integration with routing protocols,
it's reasonable to add it in.  We've structured the model such that it can
be augmented in at a later date without holding up publication of the core
model.

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

While the practice of having string based loosely coupled foreign keys in
YANG models happens, it's still necessary for them to describe how they are
intended to be used.  (Among other things, it avoids leafref considerations
for validation across models.)  Given our discussion, I don't think the leaf
as currently present in the IDR model fits well with the I2NSF model.
Guidance to change semantics to move to that at this time would be contrary
to the current way it's used for the one vendor in discussion. :-)

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

I'll read the draft in detail soon.  My cursory reading is that the
described mechanisms will probably carry operational state that a YANG model
may wish to carry.  However, the security considerations will likely mean
that the critical bits of state remain hidden.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 Jan 2022 20:02:04 -0500

Jeff: 

If I understand your recommendation, it is to leave the "SA" string hook
into the core BGP model.    If that helps merge into the current BGP
configuration (Juniper, etc. ), I fine with leaving it in.   

I agree that the creation of a routing capable Yang model based on RFC4301
rather than the RFC 9061 is a reasonable to leave to an extension to the BGP
base Yang model.   It can certain augment the base model.   

I hope this can close the issue on the BGP model. 

 Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Tuesday, January 11, 2022 6:52 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,

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Jan 2022 06:02:18 -0500

Sue,

> configuration (Juniper, etc. ), I fine with leaving it in.   

The opposite:
"If no other implementation makes use of this feature, it's probably
 reasonable for us to remove it from the core IDR BGP model for the time
 being."

The original purpose of this mail chain was to look for other vendors that
had similar configuration.  We've heard of none.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 12 Jan 2022 10:03:00 -0500

Jeff: 

Then leaving out the ipsec is fine.   We can always augment the BGP model
with the complete solution.

Let's put the IPSEC as an a "to-do" for an extended model. 

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Wednesday, January 12, 2022 6:02 AM
To: Susan Hares
Cc: 'Gyan Mishra'; 'Acee Lindem (acee)'; 'idr@ietf. org'
Subject: Re: [Idr] BGP Yang - support for ipsec for BGP sessions?

Sue,

The opposite:

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Jan 2022 11:33:32 -0500

Issue 167 opened to track the enhancement.

-- Jeff

> On Jan 12, 2022, at 10:03 AM, Susan Hares <[email-masked]> wrote:
> 
> Jeff: 
>