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

From: Jeffrey Haas <[email-masked]>
Date: Tue, 28 Dec 2021 10:47:01 -0500

[Reference: https://github.com/mjethanandani/ietf-bgp-yang/issues/59 <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: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Dec 2021 21:38:00 +0000

Hi Jeff,

Agree that comments should explicitly say transport mode SA and there should be a reference to base RFC for IPsec Transport mode with TCP.

Thanks,
Acee

From: Idr <[email-masked]> on behalf of Jeff Haas <[email-masked]>
Date: Tuesday, December 28, 2021 at 10:48 AM
To: IDR List <[email-masked]>
Subject: [Idr] BGP Yang - support for ipsec for BGP sessions?

[Reference: https://github.com/mjethanandani/ietf-bgp-yang/issues/59]

Thanks,

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 28 Dec 2021 16:47:58 -0500

Acee,

Certainly that's one way to move forward.  As seen in the Issue, Sue has been doing some investigation whether there's other IETF YANG work covering ipsec that might let us provide a more solid and general model to refer to - perhaps as a leafref.

That said, if it's only Juniper doing this, one of the options becomes simply removing it from the IETF model.  Or, perhaps optimistically, we finish the work even if there's only one implementation so that others know what support for this mode would look like.

If you could ask around at your employer as to what is supported, that'd be helpful.

Thanks.

-- Jeff

> On Dec 28, 2021, at 4:38 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Jeff, 
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Dec 2021 21:59:18 +0000

Hi Jeff,
I know the Cisco IOS-XE implementation doesn’t support IPsec transport mode configuration in BGP. I can check on the others.
Thanks,
Acee

From: Jeff Haas <[email-masked]>
Date: Tuesday, December 28, 2021 at 4:48 PM
To: Acee Lindem <[email-masked]>
Cc: IDR List <[email-masked]>
Subject: Re: [Idr] BGP Yang - support for ipsec for BGP sessions?

Acee,

Thanks.

-- Jeff

On Dec 28, 2021, at 4:38 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeff,

Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Jeff Haas <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 28, 2021 at 10:48 AM
To: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] BGP Yang - support for ipsec for BGP sessions?

Thanks,

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Dec 2021 19:04:26 -0500

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.

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 29 Dec 2021 00:21:01 +0000

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/

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.

Kind Regards

Gyan

On Tue, Dec 28, 2021 at 10:47 AM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
[Reference: https://github.com/mjethanandani/ietf-bgp-yang/issues/59]

Thanks,

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

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Dec 2021 19:37:47 -0500

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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: tom petch <[email-masked]>
Date: Wed, 29 Dec 2021 08:46:47 +0000

From: Idr <[email-masked]> on behalf of Jeffrey Haas <[email-masked]>
Sent: 28 December 2021 21:47

Acee,

<tp>

Jeff

I have reviewed a few YANG modules in my time and the one most relevant to IPsec tha I know of is RFC9061.  Since Sue chairs that WG she is doubtless familiar with it.

The I-D drew some criticism from another WG for its structuring, that its modules were not suitable for re-use and it was restructured to make that easier.  I have seen no signs of life in the YANG direction from the WG that asked for the restructuring.  More generally, I think that the idea that one WG might provide modules that others might find useful is wishful thinking.  I look at the ongoing BFD saga as an example of what might happen when it does and am quite thankful that we do not have a similar situation with, say, TCP or cryptographic algorithms or ... The I2NSF modules which are in or around IETF Last Call could have used many such - indeed one of the art reviewers suggested that surely this must have been done already - errr, no, not in the IETF of the 2020s..

Tom Petch 

Thanks.

-- Jeff

Hi Jeff,

Thanks,
Acee

Thanks,