Subject: [Idr] Securing BGP sessions (Issue#41)

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 10 Dec 2019 16:34:31 -0800

This is the second thread in the list of issues that were discussed in IETF 106 w.r.t. to BGP YANG model. This particular thread is to discuss the issue of defining how BGP sessions are going to be secured.

As stated in Singapore, the model is being defined to secure BGP sessions using 
- TCP AO
- TCP MD5
- IPSec

In case there was a question of why MD5, it is because there are existing implementations that are choosing to stay with MD5, regardless of the issues that have been raised about MD5. The model therefore has to support such implementations.

The model will use the ietf-key-chain model’s (RFC 8177) key-chain-ref to refer to an instance of the key chain. By doing that it will make use of the key rollover capability defined in that model, and for static key configuration by setting the end time to infinite in the key chain. The BGP model will leave the case of IPSec as TBD for now, and fill it when/if the IPSec YANG model is defined.

Questions/Concerns?

Mahesh Jethanandani
[email-masked]

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 10 Dec 2019 16:50:36 -0800

+1

I believe the below clearly represent what has been discussed in Singapore.

Cheers,
Jeff
On Dec 10, 2019, 4:34 PM -0800, Mahesh Jethanandani <[email-masked]>, wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jared Mauch <[email-masked]>
Date: Tue, 10 Dec 2019 19:51:18 -0500

> On Dec 10, 2019, at 7:34 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 

Some comments here:

I think of the above options the only two that are available are TCP-MD5 and IPSEC.  IPSEC doesn’t have use in the (public) internet space, but this doesn’t mean people don’t use it internally or elsewhere.. I just haven’t found any of these people in real life.

TCP-AO seems like it’s viable but as I mentioned in one of the security area meetings at IETF-101, the current operational requirements are generally stability for 180-1800 days of a BGP session (or longer).  People hate it when their BGP sessions go down and their routes go away as a result so there’s a lot of steps necessary to upgrade both sides once they support something like TCP-AO.

Also operators have a hard enough time keeping the static keys configured as they often outlast the lifetime of the engineer at the company and most key rotation systems (eg: IPSec on routers don’t often expose them in a way that survive device migrations, and key management/export are poor or non-existent, so people only use them internally vs externally facing …) don’t work well or require time sync in a way that if the fail will drop the TCP session and BGP goes down as well.

The other thing is most people just want transport integrity, not privacy.

- Jared

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 Dec 2019 01:10:08 +0000

Hi Mahesh, 
I assume by IPsec, you mean transport mode IPsec. For IPsec protection of BGP, where are the details specified? 
Thanks,
Acee

On 12/10/19, 7:35 PM, "Idr on behalf of Mahesh Jethanandani" <[email-masked] on behalf of [email-masked]> wrote:

    

    Questions/Concerns?
    
    Mahesh Jethanandani
    [email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 10 Dec 2019 17:18:48 -0800

Hi Acee,

> On Dec 10, 2019, at 5:10 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Mahesh, 
> I assume by IPsec, you mean transport mode IPsec.

Yes. The assumption is that the underlying transport is secured using IPsec, and the model provides (if needed) key parameters needed to kick off the IKE to setup the SA in IPsec.

HTH.

> For IPsec protection of BGP, where are the details specified? 
> Thanks,
> Acee
> 

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 10 Dec 2019 17:21:40 -0800

> On Dec 10, 2019, at 4:51 PM, Jared Mauch <[email-masked]> wrote:
> 
> 
> 

Not securing the BGP session is certainly an option.

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 Dec 2019 01:29:17 +0000

Hi Mahesh, 

On 12/10/19, 8:19 PM, "Mahesh Jethanandani" <[email-masked]> wrote:

    Hi Acee,

    
    HTH.

Well it doesn't help at all.... Normally, the usage of IPsec (AH, ESP, algorithms, key exchange, etc.) would be specified in some document. For example, IPsec usage by OSPFv3 is specified in RFC 4552. Granted, it is a lot simpler for BGP than OSPFv3 since BGP is strictly P2P but specification would still seem to necessary. 

Thanks,
Acee

    Mahesh Jethanandani
    [email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 10 Dec 2019 17:40:47 -0800

> On Dec 10, 2019, at 5:29 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Mahesh, 
> 

You are right. It should be some document. That document in my mind is the YANG model for IPsec/IKE, something we need to ask the SEC ADs about. You would agree that what needs to be defined is not BGP specific, and therefore does not belong in the BGP model.

Much like TCP-AO and TCP-MD5 I expect this other document to define a grouping that the BGP model imports and uses to define what is needed to setup IPsec.

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 13 Dec 2019 18:47:55 +0000

Hi Mahesh, 

On 12/10/19, 8:41 PM, "Mahesh Jethanandani" <[email-masked]> wrote:

    

Actually I disagree with you - TCP MD5 and TCP-AO are more than adequately documented. 

   MD5 - https://datatracker.ietf.org/doc/rfc2385/
   TCP-AO - https://datatracker.ietf.org/doc/rfc5925/

It is only IPsec transport mode that isn't described. Also, I don't know of anyone who supports this so I'm wondering why it is in the discussion for this version of the BGP YANG model.

Thanks,
Acee

    Cheers.

    Mahesh Jethanandani
    [email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 13 Dec 2019 15:09:32 -0800

Hi Acee,

> On Dec 13, 2019, at 10:47 AM, Acee Lindem (acee) <[email-masked]> wrote:
>> 
>> 
>   MD5 - https://datatracker.ietf.org/doc/rfc2385/ <https://datatracker.ietf.org/doc/rfc2385/>
>   TCP-AO - https://datatracker.ietf.org/doc/rfc5925/ <https://datatracker.ietf.org/doc/rfc5925/>

What you are pointing to me is the document that describes how the two technologies can be used to secure BGP. I am aware of those RFCs. The document I am looking for is a YANG model that defines a grouping for MD5 and TCP-AO that the BGP model can import and use. 

> It is only IPsec transport mode that isn't described. Also, I don't know of anyone who supports this so I'm wondering why it is in the discussion for this version of the BGP YANG model.

I will let Jeff comment on this.

Cheers.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 13 Dec 2019 15:55:08 -0800

Hi Acee,

I realize that the last e-mail did not help. So let me see if this is any better.

If I understand you correctly, you are suggesting that securing BGP with MD5 and TCP-AO is adequately documented, and I agree. We just need a YANG model (in a different document) that defines groupings for them such that the BGP model can use them. BTW, work has started in TCPM to define just that model, just that it is still an I-D, and not a WG document. That puts BGP YANG model in a downrev with that draft. If at the time of publication, the draft has not made progress, IDR will have to make a decision of whether they want to keep that dependency or push support for secure sessions out into a -bis document.

To the question of IPsec, and whether we should support it or not, as I said, I will let Jeff comment. But what kind of documentation are you hoping for? Isn’t it just a question of giving IKE the parameters it needs to setup a IPsec tunnel? If we decide to support it, i2nsf WG has been working on an IKE model, as I just learnt, complete with re-keying, which with a few changes could be used by the BGP model.

Cheers.

> On 12/10/19, 8:41 PM, "Mahesh Jethanandani" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Dec 2019 16:19:07 -0500

Mahesh,

> Not securing the BGP session is certainly an option.

What's intended here by Jared, I think, is that AH without ESP is fine.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Dec 2019 16:23:12 -0500

> I will let Jeff comment on this.

In Junos,

Transport mode for ipsec for BGP:

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/ipsec-sa-edit-protocols-bgp.html
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ip_security.html

While it's a valid observation that ISPs don't typically deploy IPsec at
ASBRs, this type of security is often used for BGP IPsec VPNs.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 19 Dec 2019 01:05:00 +0000

Normally for routing protocols, authentication is a much stronger requirement than confidentiality. However, in this case IPsec is simply being used for transmission error detection. 
Thanks,
Acee

On 12/17/19, 2:59 PM, "Jeffrey Haas" <[email-masked]> wrote:

    Mahesh,

    
    -- Jeff