Subject: [mpls] LDP Security

From: Stewart Bryant <[email-masked]>
Date: Wed, 8 Nov 2017 17:27:39 +0000

To the SEC and RTG ADs,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working 
groups that develop the LDP protocol that LDP is no longer adequately 
secured. LDP currently relies on MD5 for cryptographic security of its 
messages, but MD5 is a hash function that is no longer considered to 
meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. 
Session communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the 
authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some to 
be too weak for this application.  It also points out that a similar TCP 
option with a stronger hashing algorithm (it cites SHA-1 as an example) 
could be deployed.  To our knowledge, no such TCP option has been 
defined and deployed.  However, we note that LDP can use whatever TCP 
message digest techniques are available, and when one stronger than MD5 
is specified and implemented, upgrading LDP to use it would be 
relatively straightforward."

We note that BGP has already been through this process, and replaced MD5 
with TCP-AO in RFC 7454. I would be logical to follow the same approach 
to secure LDP. However, as far as we are able to ascertain, there is 
currently no recommended, mandatory to implement, cryptographic function 
specified. We are concerned that without such a mandatory function, 
implementations will simply fall back to MD5 and we will be no further 
forward

We think that the best way forward is to publish a draft similar to RFC 
7454 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secure 
the TCP sessions carrying LDP in addition to the currently required TCP 
MD5 Signature Option. Furthermore, the TBD cryptographic mechanism must 
be implemented and provided to TCP-AO to secure LDP messages. The TBD 
mechanism is the preferred option, and MD5 is only to be used when TBD 
is unavailable."

We are not an experts on this part of the stack, but it seems that TCP 
security negotiation is still work in progress. If we are wrong, then we 
need to include a requirement that such negotiation is also required. In 
the absence of a negotiation protocol, however, we need to leave this as 
a configuration process until such time as the negotiation protocol work 
is complete. On completion of a suitable negotiation protocol we need to 
issue a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an 
indefinite lifetime, and that implementation should note the IETF 
anticipates updating the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it 
can reasonably be implemented on a typical router route processor, and 
which will provide adequate security without significantly degrading the 
convergence time of an LSR. Without a function that does not 
significantly impact router convergence we simply close one 
vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we  need 
to ask the security area for a review of our proposed approach, and help 
correcting any misunderstanding of the security issues or our 
misunderstanding of the existing security mechanisms. We also need the 
recommendations of a suitable security function (TBD in the above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Nov 2017 09:59:44 -0800

Hi Stewart

Thanks for your note.

My overall sense of the state of play is, I think much like yours.

TCP-MD5 is inadequate in two major respects:
- It uses weak algorithms
- It has a bad negotiation/setuop story (manual key management)

TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedies
the algorithm
issue but not the key management issue [0]. We haven't made much progress
on the key
management story, and that seems to be a major impediment to deploying
either of these
technologies (which I am given to understand don't see a lot of use). We
should probably
talk in Singapore about that, but that's not going to get better any time
soon.

In the interim, I think the text you have is OK, and "TBD" should read
"SHA-256", with
the fallback being SHA-256 -> SHA-1 -> MD5.

-Ekr

[0] Technically It has better support for rollover, but this is not a huge
improvement.
[1] tcpcrypt is kind of orthogonal here as it's unauthenticated but
opportunistic.  That said,
it would provide defense against attackers who gain access to the link
after connection
setup and doesn't require configuration.

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <[email-masked]>
wrote:

> messages, but MD5 is a hash function that is no longer considered to meet
> current security requirements.
>
> "[RFC2385] asserts that MD5 authentication is now considered by some to be
> too weak for this application.  It also points out that a similar TCP
> could be deployed.  To our knowledge, no such TCP option has been defined
> and deployed.  However, we note that LDP can use whatever TCP message
> digest techniques are available, and when one stronger than MD5 is
> specified and implemented, upgrading LDP to use it would be relatively
> straightforward."
>
> with TCP-AO in RFC 7454. I would be logical to follow the same approach to
> secure LDP. However, as far as we are able to ascertain, there is currently
> no recommended, mandatory to implement, cryptographic function specified.
> We are concerned that without such a mandatory function, implementations
> will simply fall back to MD5 and we will be no further forward
>
> the TCP sessions carrying LDP in addition to the currently required TCP MD5
> Signature Option. Furthermore, the TBD cryptographic mechanism must be
> implemented and provided to TCP-AO to secure LDP messages. The TBD
> mechanism is the preferred option, and MD5 is only to be used when TBD is
> unavailable."
>
> the absence of a negotiation protocol, however, we need to leave this as a
> configuration process until such time as the negotiation protocol work is
> complete. On completion of a suitable negotiation protocol we need to issue
> a further update requiring its use.
>
> The TBD default security function will need to be chosen such that it can
> reasonably be implemented on a typical router route processor, and which
> will provide adequate security without significantly degrading the
> convergence time of an LSR. Without a function that does not significantly
> impact router convergence we simply close one vulnerability and open
> another.
>

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 8 Nov 2017 19:57:29 +0000

Hi Stewart,

I would note https://tools.ietf.org/html/rfc6952 - where LDP security is analyzed from all aspects.

Eric,

Quick comments below [Uma]:

--
Uma C.

From: mpls [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <[email-masked]>
Cc: [email-masked]; [email-masked]; <[email-masked]> <[email-masked]>; [email-masked]; [email-masked]; <[email-masked]> <[email-masked]>
Subject: Re: [mpls] LDP Security

Hi Stewart

Thanks for your note.

TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedies the algorithm
Issue

[Uma]: Yes, if we go with RFC 5926 mandatory list..

but not the key management issue [0]. We haven't made much progress on the key
management story, and that seems to be a major impediment to deploying either of these
technologies (which I am given to understand don't see a lot of use).

[Uma]: True.
               But I would indicate some effort done few years back regarding key management for pair wise routing protocols (BGP, LDP, PCEP, MSDP ..).
               One such proposal is by extending IKEv2 to negotiate TCP-AO MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05
               This also requires some more work with TCP-AO; me & Joe put together https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt
           Note the above didn’t progress in the concluded KARP WG (not fully sure the reasons on why).

We should probably talk in Singapore about that, but that's not going to get better any time soon.

In the interim, I think the text you have is OK, and "TBD" should read "SHA-256", with
the fallback being SHA-256 -> SHA-1 -> MD5.

[Uma]: While the list can be extended - I didn’t see SHA256 in the mandatory list in RFC 5926 for MAC.

-Ekr

[0] Technically It has better support for rollover, but this is not a huge improvement.
[1] tcpcrypt is kind of orthogonal here as it's unauthenticated but opportunistic.  That said,
it would provide defense against attackers who gain access to the link after connection
setup and doesn't require configuration.

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:
To the SEC and RTG ADs,

There is a concern shared among the security community and the working groups that develop the LDP protocol that LDP is no longer adequately secured. LDP currently relies on MD5 for cryptographic security of its messages, but MD5 is a hash function that is no longer considered to meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Session communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some to be too weak for this application.  It also points out that a similar TCP option with a stronger hashing algorithm (it cites SHA-1 as an example) could be deployed.  To our knowledge, no such TCP option has been defined and deployed.  However, we note that LDP can use whatever TCP message digest techniques are available, and when one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward."

We note that BGP has already been through this process, and replaced MD5 with TCP-AO in RFC 7454. I would be logical to follow the same approach to secure LDP. However, as far as we are able to ascertain, there is currently no recommended, mandatory to implement, cryptographic function specified. We are concerned that without such a mandatory function, implementations will simply fall back to MD5 and we will be no further forward

We think that the best way forward is to publish a draft similar to RFC 7454 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secure the TCP sessions carrying LDP in addition to the currently required TCP MD5 Signature Option. Furthermore, the TBD cryptographic mechanism must be implemented and provided to TCP-AO to secure LDP messages. The TBD mechanism is the preferred option, and MD5 is only to be used when TBD is unavailable."

We are not an experts on this part of the stack, but it seems that TCP security negotiation is still work in progress. If we are wrong, then we need to include a requirement that such negotiation is also required. In the absence of a negotiation protocol, however, we need to leave this as a configuration process until such time as the negotiation protocol work is complete. On completion of a suitable negotiation protocol we need to issue a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an indefinite lifetime, and that implementation should note the IETF anticipates updating the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it can reasonably be implemented on a typical router route processor, and which will provide adequate security without significantly degrading the convergence time of an LSR. Without a function that does not significantly impact router convergence we simply close one vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we  need to ask the security area for a review of our proposed approach, and help correcting any misunderstanding of the security issues or our misunderstanding of the existing security mechanisms. We also need the recommendations of a suitable security function (TBD in the above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Nov 2017 12:52:40 -0800

On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <[email-masked]>
wrote:

> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Wednesday, November 08, 2017 10:00 AM
> *To:* Stewart Bryant <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; <[email-masked]> <
> [email-masked]>; [email-masked]; [email-masked]; <[email-masked]>
> <[email-masked]>
> *Subject:* Re: [mpls] LDP Security
>
>
>
> Hi Stewart
>
>
>
> Thanks for your note.
>
>
>
>                But I would indicate some effort done few years back
> regarding key management for pair wise routing protocols (BGP, LDP, PCEP,
> MSDP ..).
>
>                One such proposal is by extending IKEv2 to negotiate TCP-AO
> MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html/
> draft-mahesh-karp-rkmp-05
>
>                This also requires some more work with TCP-AO; me & Joe put
> together https://www.ietf.org/archive/id/draft-chunduri-karp-using-
> ikev2-with-tcp-ao-06.txt
>

Yeah, I know that people tried to do this, but my impression was it kinda
didn't progress much.

> mandatory list in RFC 5926 for MAC.

Generally we're trying to move away from SHA-1 towards SHA-256.

-Ekr

---

From: Eric Gray <[email-masked]>
Date: Wed, 8 Nov 2017 21:34:20 +0000

Stewart,

	LDP uses the same security measures that were available in BGP implementations at the time of LDP specification, for reasons that were pretty obvious to anyone who implemented LDP based on BGP.

	I can think of no reason why any more complicated approach might be required than you have suggested, based on the evolution of BGP.

--
Eric

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, November 08, 2017 12:28 PM
To: [email-masked]; <[email-masked]> <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [mpls] LDP Security

To the SEC and RTG ADs,

I am sending the following message on behalf of the MPLS and the PALS WG Chairs.

"Implementations conforming to this RFC MUST implement TCP-AO to secure the TCP sessions carrying LDP in addition to the currently required TCP
MD5 Signature Option. Furthermore, the TBD cryptographic mechanism must be implemented and provided to TCP-AO to secure LDP messages. The TBD mechanism is the preferred option, and MD5 is only to be used when TBD is unavailable."

Best regards

The MPLS WG Chairs
The PALS WG Chairs

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

---

From: Eric Gray <[email-masked]>
Date: Wed, 8 Nov 2017 22:01:02 +0000

Eric,

                This becomes another argument to follow BGP in resolving the issues.  The push from customers to fix the problem is essentially the same and resolving the problem for BGP will almost certainly resolve it for LDP as well.

--
Eric

Sent: Wednesday, November 08, 2017 1:00 PM

Hi Stewart

Thanks for your note.

TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedies the algorithm
issue but not the key management issue [0]. We haven't made much progress on the key
management story, and that seems to be a major impediment to deploying either of these
technologies (which I am given to understand don't see a lot of use). We should probably
talk in Singapore about that, but that's not going to get better any time soon.

-Ekr

Best regards

The MPLS WG Chairs
The PALS WG Chairs

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 8 Nov 2017 23:50:24 +0000

In-line [Uma1]:
--
Uma C.

From: Eric Rescorla [mailto:[email-masked]]
Sent: Wednesday, November 08, 2017 12:53 PM
To: Uma Chunduri <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; [email-masked]; [email-masked]; <[email-masked]> <[email-masked]>; [email-masked]; [email-masked]; <[email-masked]> <[email-masked]>
Subject: Re: [mpls] LDP Security

On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stewart,

Eric,

--
Uma C.

From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] LDP Security

Hi Stewart

Thanks for your note.

[Uma]: True.

Yeah, I know that people tried to do this, but my impression was it kinda didn't progress much.

[Uma1]: Couple of things:

1.       Nothing to be done (from spec pov of course): Use TCP-AO (instead of current MD5) with the RFC 5926 mandated MACs/KDFs – so the ‘TBD’ in Stewart suggesting below is already there.

2.       As #1 too is not good enough from your above note - do SHA-256 and live with it (no algorithm agility). Still a security benefit in one way from existing stuff or even  #1.

3.       Do key management and “theoretically” get all we wanted….

We have been here multiple times; because #1 itself is not *mostly* deployed (neither in BGP nor in LDP) if there is any appetite for #2 and #3 for practical deployments. But still it may be good to do #2 any ways.

-Ekr

-Ekr

Best regards

The MPLS WG Chairs
The PALS WG Chairs

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Nov 2017 15:52:51 -0800

On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <[email-masked]>
wrote:

> In-line [Uma1]:
>
> --
>
> Uma C.
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Wednesday, November 08, 2017 12:53 PM
> *To:* Uma Chunduri <[email-masked]>
> *Cc:* Stewart Bryant <[email-masked]>; [email-masked];
> [email-masked]; <[email-masked]> <[email-masked]>;
> [email-masked]; [email-masked]; <[email-masked]> <[email-masked]>
>
> 1.       *Nothing to be done (from spec pov of course):* Use TCP-AO
> (instead of current MD5) with the RFC 5926 mandated MACs/KDFs – so the
> ‘TBD’ in Stewart suggesting below is already there.
>
> 2.       As #1 too is not good enough from your above note - do SHA-256
> and live with it (no algorithm agility). Still a security benefit in one
> way from existing stuff or even  #1.
>
I'm not sure why you say "no algorithm agility". You'd be using AO, just
with a different algorithm than SHA-1. AES-CMAC is still fine as far as I
know.

-Ekr

> We have been here multiple times; because #1 itself is not **mostly**
> deployed (neither in BGP nor in LDP) if there is any appetite for #2 and #3
> for practical deployments. But still it may be good to do #2 any ways.
>
>
>
>
>
> -Ekr
>
>
>
>
>
> -Ekr
>
>
>
>
>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 9 Nov 2017 00:14:12 +0000

Sent: Wednesday, November 08, 2017 3:53 PM

On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <[email-masked]<mailto:[email-masked]>> wrote:
In-line [Uma1]:
--
Uma C.

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 08, 2017 12:53 PM
To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>

Eric,

--
Uma C.

Hi Stewart

Thanks for your note.

[Uma]: True.

2.       As #1 too is not good enough from your above note - do SHA-256 and live with it (no algorithm agility). Still a security benefit in one way from existing stuff or even  #1.
I'm not sure why you say "no algorithm agility". You'd be using AO, just with a different algorithm than SHA-1. AES-CMAC is still fine as far as I know.
[Uma2]: Sure, you have it, if you use AO;
                 But then  I am not getting how we can mandate one MUST implement algorithm as suggested below TBD  would actually work  (especially - *if* #1 is already deployed somewhere?)
                 Perhaps staying with #1 is the best bet or do negotiation through #3, with already mandated and additional stuff.

-Ekr

-Ekr

-Ekr

Best regards

The MPLS WG Chairs
The PALS WG Chairs

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Nov 2017 16:44:28 -0800

I don't understand what you're getting at here. Yes, if people have TCP-AO
then presumably they have SHA-1.

But now we're talking about requiring people to have TCP-AO in this case,
so we should try to move them to SHA-256 at the time we require AO.

-Ekr

On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri <[email-masked]>
wrote:

> *Sent:* Wednesday, November 08, 2017 3:53 PM
>
>                  But then  I am not getting how we can mandate one MUST
> implement algorithm as suggested below TBD  would actually work
>  (especially - **if** #1 is already deployed somewhere?)
>
>                  Perhaps staying with #1 is the best bet or do negotiation
> through #3, with already mandated and additional stuff.
>
>
>
> -Ekr
>
>
>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 9 Nov 2017 01:09:00 +0000

>But now we're talking about requiring people to have TCP-AO in this case, so we should try to move them to SHA-256 at the time we require AO.

As discussed this is non-existent as far as AO is concerned (as of today); so if we ought to mandate this with TBD language as indicated- first this has to be added and assume no body deployed AO.

--
Uma C.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Nov 2017 17:13:37 -0800

On Wed, Nov 8, 2017 at 5:09 PM, Uma Chunduri <[email-masked]>
wrote:

>
>
> >But now we're talking about requiring people to have TCP-AO in this
> case, so we should try to move them to SHA-256 at the time we require AO.
>
>
>
> As discussed this
>

What is "this"?

-Ekr

> is non-existent as far as AO is concerned (as of today); so if we ought to
> mandate this with TBD language as indicated- first this has to be added and
> assume no body deployed AO.
>
>
>
>
>
> --
>
> Uma C.
>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 9 Nov 2017 01:16:30 +0000

Sent: Wednesday, November 08, 2017 5:14 PM

As discussed this

What is "this"?

SHA-256 usage as a potential MAC or/and KDF for AO.

-Ekr

is non-existent as far as AO is concerned (as of today); so if we ought to mandate this with TBD language as indicated- first this has to be added and assume no body deployed AO.

--
Uma C.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 9 Nov 2017 00:15:34 -0500

Eric: 

BGP and LDP would be more secure if TCP-AO deployed with all BGP and LDP – but there are issues with customer pick-up and deployment of these protocols on many networks.  I wished we had TCP-AO when BGP started, but we did not. 

Some of the least secure BGP is in data centers – where the DC providers say “It’s all under one administration”.  Another problem is on private lines.    We should chat about the networks each of these protocols are actually deployed on.   If you have any insight on a way to encourage adoption, I’d love to hear it. Require TCP-AO does not really mean anything if providers and Data Centers do not adopt it.  

Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to getting people to TCP-AO.   

Sue 

From: mpls [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 8, 2017 7:44 PM
To: Uma Chunduri
Cc: [email-masked]; [email-masked]; <[email-masked]>; [email-masked]; [email-masked]; <[email-masked]>
Subject: Re: [mpls] LDP Security

I don't understand what you're getting at here. Yes, if people have TCP-AO then presumably they have SHA-1.

-Ekr

On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri <[email-masked]> wrote:

 

On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <[email-masked]> wrote:

In-line [Uma1]:

--

Uma C.

From: Eric Rescorla [mailto: <mailto:[email-masked]> [email-masked]] 
Sent: Wednesday, November 08, 2017 12:53 PM
To: Uma Chunduri < <mailto:[email-masked]> [email-masked]>
Cc: Stewart Bryant < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; < <mailto:[email-masked]> [email-masked]> < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; < <mailto:[email-masked]> [email-masked]> < <mailto:[email-masked]> [email-masked]>

 

On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <[email-masked]> wrote:

Hi Stewart,

I would note  <https://tools.ietf.org/html/rfc6952> https://tools.ietf.org/html/rfc6952 - where LDP security is analyzed from all aspects. 

Eric,

--

Uma C.

Hi Stewart

Thanks for your note.

Issue

[Uma]: True. 

 

-Ekr

 

-Ekr

-Ekr

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <[email-masked]> wrote:

To the SEC and RTG ADs,

Best regards

The MPLS WG Chairs
The PALS WG Chairs

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Nov 2017 11:09:33 -0800

Yeah, I agree. I don't really have any good ideas how to get people to do
AO. Based on comments I've heard, providers don't see a lot of value,
rightly or wrongly....

-Ekr

On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares <[email-masked]> wrote:

> Eric:
>
>
>
> BGP and LDP would be more secure if TCP-AO deployed with all BGP and LDP –
> but there are issues with customer pick-up and deployment of these
> protocols on many networks.  I wished we had TCP-AO when BGP started, but
> we did not.
>
>
>
> Some of the least secure BGP is in data centers – where the DC providers
> say “It’s all under one administration”.  Another problem is on private
> lines.    We should chat about the networks each of these protocols are
> actually deployed on.   If you have any insight on a way to encourage
> adoption, I’d love to hear it. Require TCP-AO does not really mean anything
> if providers and Data Centers do not adopt it.
>
>
>
> *Sent:* Wednesday, November 8, 2017 7:44 PM
> *To:* Uma Chunduri
> *Cc:* [email-masked]; [email-masked]; <[email-masked]>;
> [email-masked]; [email-masked]; <[email-masked]>
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 9 Nov 2017 15:09:08 -0500

> AO. Based on comments I've heard, providers don't see a lot of value,

I know Alia has been talking about a possible Linux implementation to
drive the way.  I agree with EKR on other points and have been
following along.

Best,
Kathleen
>> but there are issues with customer pick-up and deployment of these protocols
>> on many networks.  I wished we had TCP-AO when BGP started, but we did not.
>>
>>
>>
>> Cc: [email-masked]; [email-masked]; <[email-masked]>;
>> Cc: Stewart Bryant <[email-masked]>; [email-masked];
>> Cc: Stewart Bryant <[email-masked]>; [email-masked];
>> Cc: [email-masked]; [email-masked]; <[email-masked]>
>> <[email-masked]>; [email-masked]; [email-masked]; <[email-masked]>
>> <[email-masked]>
>> MKTs (which can give rekey & algo. agility) -
>> https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05
>>
>> together
>> https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt
>>
>> 1.       Nothing to be done (from spec pov of course): Use TCP-AO (instead
>> of current MD5) with the RFC 5926 mandated MACs/KDFs – so the ‘TBD’ in
>> Stewart suggesting below is already there.
>>
>> and live with it (no algorithm agility). Still a security benefit in one way
>> from existing stuff or even  #1.
>>
>> implement algorithm as suggested below TBD  would actually work  (especially
>> - *if* #1 is already deployed somewhere?)
>>
>> We have been here multiple times; because #1 itself is not *mostly*
>> too weak for this application.  It also points out that a similar TCP option
>> with a stronger hashing algorithm (it cites SHA-1 as an example) could be
>> deployed.  To our knowledge, no such TCP option has been defined and
>> deployed.  However, we note that LDP can use whatever TCP message digest
>> techniques are available, and when one stronger than MD5 is specified and
>> implemented, upgrading LDP to use it would be relatively straightforward."
>>
>> no recommended, mandatory to implement, cryptographic function specified. We
>> are concerned that without such a mandatory function, implementations will
>> simply fall back to MD5 and we will be no further forward
>>
>> implemented and provided to TCP-AO to secure LDP messages. The TBD mechanism
>> is the preferred option, and MD5 is only to be used when TBD is
>> unavailable."
>>
>> need to include a requirement that such negotiation is also required. In the
>> absence of a negotiation protocol, however, we need to leave this as a

-- 

Best regards,
Kathleen

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 Nov 2017 23:02:08 +0000

Another data point is that for a long time operators only turned on MD5 
for the
link state protocols to get a better checksum, not because they perceived
a threat.

There is security at different levels, for example MACsec, which has the 
advantage
of securing the customer traffic from pervasive monitoring as well as 
securing the
routing layer. Additionally it is common for customer traffic gets put 
straight
into MPLS and so cannot be used as an attack vector.

- Stewart

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Nov 2017 23:15:25 -0800

> link state protocols to get a better checksum, not because they perceived

FWIW, I agree that MD5 is a fine checksum.

-Ekr

>>>> protocols
>>>> case,
>>>> I would note https://tools.ietf.org/html/rfc6952 - where LDP security
>>>> is
>>>> analyzed from all aspects.
>>>>
>>>>
>>>>
>>>> Eric,
>>>>
>>>>
>>>>
>>>> but not the key management issue [0]. We haven't made much progress on
>>>> the
>>>> key
>>>>
>>>> (especially
>>>> be
>>>> option
>>>> to
>>>> MD5
>>>> mechanism
>>>> can
>>>> significantly

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Fri, 10 Nov 2017 16:21:52 +0000

+TCPM

Please free to discuss changes to TCP-AO on the TCPM list, or speak up at the upcoming TCPM meeting.

The addition of SHA-256 has been discussed in TCPM already (see draft-nayak-tcp-sha2-02), but so far there was not much energy and no interest from potential TCP-AO implementers or users.

Michael

(TCPM co-chair)

Sent: Wednesday, November 08, 2017 7:00 PM

Hi Stewart

Thanks for your note.

-Ekr

Best regards

The MPLS WG Chairs
The PALS WG Chairs

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Fri, 10 Nov 2017 16:21:52 +0000

+TCPM

Michael

(TCPM co-chair)

Hi Stewart

Thanks for your note.

-Ekr

Best regards

The MPLS WG Chairs
The PALS WG Chairs

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Nov 2017 16:48:12 -0800

Hi, all,

I don't see a problem if there's a need for updating TCP-AO to
include/require other algorithms. It was intended to be extensible.

I agree with the issue of key management. There was some work on
extensions to IKE to enable its use to manage TCP-AO parameters and
keys, but it stalled twice:

M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. Chunduri,
A. Tian, J. Touch, “Negotiation for Keying Pairwise Routing Protocols in
IKEv2 <http://www.isi.edu/touch/pubs/draft-mahesh-karp-rkmp-05.txt>,”
(RFC in progress), Nov. 2013.

U. Chunduri, A. Tian, J. Touch, “Using IKEv2 with TCP-AO
<http://www.isi.edu/touch/pubs/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt>,”
(RFC in progress), Feb. 2014.

AFAICT, that would go a long way towards addressing the issues with its
use outside routing environments where keys are already considered
sufficiently managed.

However, the larger problem with TCP-AO is that there are no
implementations available in end system OSes (AFAICT). Designing a new
solution simply to avoid implementing an existing one would be a
significant waste of time.

Joe

On 11/10/2017 8:21 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> The addition of SHA-256 has been discussed in TCPM already (see
> draft-nayak-tcp-sha2-02), but so far there was not much energy and no
> interest from potential TCP-AO implementers or users.
>
>  
>
> Michael
>
> (TCPM co-chair)
>
>  
>
>  
>
> *Sent:* Wednesday, November 08, 2017 7:00 PM
> *Cc:* [email-masked]; [email-masked]; <[email-masked]>
> <[email-masked]>; [email-masked]; [email-masked];
> <[email-masked]> <[email-masked]>
> We should probably
> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     To the SEC and RTG ADs,
>
>     There is a concern shared among the security community and the
>     working groups that develop the LDP protocol that LDP is no longer
>     adequately secured. LDP currently relies on MD5 for cryptographic
>     security of its messages, but MD5 is a hash function that is no
>     longer considered to meet current security requirements.
>
>     In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element
>     2. Session communication carried by TCP the following statements
>     is made:
>
>     "LDP specifies use of the TCP MD5 Signature Option to provide for
>     the authenticity and integrity of session messages.
>
>     "[RFC2385] asserts that MD5 authentication is now considered by
>     some to be too weak for this application.  It also points out that
>     a similar TCP option with a stronger hashing algorithm (it cites
>     SHA-1 as an example) could be deployed.  To our knowledge, no such
>     TCP option has been defined and deployed.  However, we note that
>     LDP can use whatever TCP message digest techniques are available,
>     and when one stronger than MD5 is specified and implemented,
>     upgrading LDP to use it would be relatively straightforward."
>
>     We note that BGP has already been through this process, and
>     replaced MD5 with TCP-AO in RFC 7454. I would be logical to follow
>     the same approach to secure LDP. However, as far as we are able to
>     ascertain, there is currently no recommended, mandatory to
>     implement, cryptographic function specified. We are concerned that
>     without such a mandatory function, implementations will simply
>     fall back to MD5 and we will be no further forward
>
>     We think that the best way forward is to publish a draft similar
>     to RFC 7454 that contains the following requirement:
>
>     "Implementations conforming to this RFC MUST implement TCP-AO to
>     secure the TCP sessions carrying LDP in addition to the currently
>     required TCP MD5 Signature Option. Furthermore, the TBD
>     cryptographic mechanism must be implemented and provided to TCP-AO
>     to secure LDP messages. The TBD mechanism is the preferred option,
>     and MD5 is only to be used when TBD is unavailable."
>
>     We are not an experts on this part of the stack, but it seems that
>     TCP security negotiation is still work in progress. If we are
>     wrong, then we need to include a requirement that such negotiation
>     is also required. In the absence of a negotiation protocol,
>     however, we need to leave this as a configuration process until
>     such time as the negotiation protocol work is complete. On
>     completion of a suitable negotiation protocol we need to issue a
>     further update requiring its use.
>
>     The TBD default security function will need to be chosen such that
>     it can reasonably be implemented on a typical router route
>     processor, and which will provide adequate security without
>     significantly degrading the convergence time of an LSR. Without a
>     function that does not significantly impact router convergence we
>     simply close one vulnerability and open another.
>
>     As experts on the LDP protocol, but not on security mechanisms,
>     we  need to ask the security area for a review of our proposed
>     approach, and help correcting any misunderstanding of the security
>     issues or our misunderstanding of the existing security
>     mechanisms. We also need the recommendations of a suitable
>     security function (TBD in the above text).
>
>     Best regards
>
>     The MPLS WG Chairs
>     The PALS WG Chairs
>
>  
>
>
>
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 11 Nov 2017 11:11:57 +0800

Joe,

There’s no problem with updating, the problem is with adoption...

Regards,
Jeff

> On Nov 11, 2017, at 08:48, Joe Touch <[email-masked]> wrote:
> 
> Hi, all,
> 
> I don't see a problem if there's a need for updating TCP-AO to include/require other algorithms. It was intended to be extensible.
> 
> I agree with the issue of key management. There was some work on extensions to IKE to enable its use to manage TCP-AO parameters and keys, but it stalled twice:
> 
> M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. Chunduri, A. Tian, J. Touch, “Negotiation for Keying Pairwise Routing Protocols in IKEv2,” (RFC in progress), Nov. 2013.
> 
> U. Chunduri, A. Tian, J. Touch, “Using IKEv2 with TCP-AO,” (RFC in progress), Feb. 2014.
> 
> AFAICT, that would go a long way towards addressing the issues with its use outside routing environments where keys are already considered sufficiently managed.
> 
> However, the larger problem with TCP-AO is that there are no implementations available in end system OSes (AFAICT). Designing a new solution simply to avoid implementing an existing one would be a significant waste of time.
> Joe
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 10 Nov 2017 22:58:59 -0500

Kathleen and Eric: 

I agree that getting linux implementations with TCP-AO is one avenue to drive things into product.   Any ideas on getting more deployment for routing security - is really important.   Pushing both small and large gains (TCP-AO, registration) will help us continually increase the security.   

Sue 

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Thursday, November 9, 2017 3:09 PM
To: Eric Rescorla
Cc: Susan Hares; Uma Chunduri; [email-masked]; [email-masked]; <[email-masked]>; mpls-chairs; [email-masked]; <[email-masked]>
Subject: Re: [mpls] LDP Security

On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla <[email-masked]> wrote:
> Yeah, I agree. I don't really have any good ideas how to get people to 
> do AO. Based on comments I've heard, providers don't see a lot of 
> value, rightly or wrongly....

I know Alia has been talking about a possible Linux implementation to drive the way.  I agree with EKR on other points and have been following along.

Best,
Kathleen
>> BGP and LDP would be more secure if TCP-AO deployed with all BGP and 
>> LDP – but there are issues with customer pick-up and deployment of 
>> these protocols on many networks.  I wished we had TCP-AO when BGP started, but we did not.
>>
>>
>>
>> Some of the least secure BGP is in data centers – where the DC 
>> providers say “It’s all under one administration”.  Another problem is on private
>> adoption, I’d love to hear it. Require TCP-AO does not really mean 
>> anything if providers and Data Centers do not adopt it.
>>
>>
>>
>> is analyzed from all aspects.
>>
>>
>>
>> Eric,
>>
>>
>>
>> regarding key management for pair wise routing protocols (BGP, LDP, 
>> PCEP, MSDP ..).
>>
>>                One such proposal is by extending IKEv2 to negotiate 
>> TCP-AO MKTs (which can give rekey & algo. agility) -
>>                This also requires some more work with TCP-AO; me & 
>> Joe put together 
>> of current MD5) with the RFC 5926 mandated MACs/KDFs – so the ‘TBD’ 
>> in Stewart suggesting below is already there.
>>
>> and live with it (no algorithm agility). Still a security benefit in 
>> one way from existing stuff or even  #1.
>>
>> I'm not sure why you say "no algorithm agility". You'd be using AO, 
>> just with a different algorithm than SHA-1. AES-CMAC is still fine as 
>> far as I know.
>>
>>                  But then  I am not getting how we can mandate one 
>> MUST implement algorithm as suggested below TBD  would actually work  
>> (especially
>>                  Perhaps staying with #1 is the best bet or do 
>> negotiation through #3, with already mandated and additional stuff.
>>
>>
>>
>> -Ekr
>>
>>
>>
>> deployed (neither in BGP nor in LDP) if there is any appetite for #2 
>> and #3 for practical deployments. But still it may be good to do #2 any ways.
>>
>>
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>> <[email-masked]>
>> wrote:
>>
>> To the SEC and RTG ADs,
>>
>> "[RFC2385] asserts that MD5 authentication is now considered by some 
>> to be too weak for this application.  It also points out that a 
>> similar TCP option with a stronger hashing algorithm (it cites SHA-1 
>> as an example) could be deployed.  To our knowledge, no such TCP 
>> option has been defined and deployed.  However, we note that LDP can 
>> use whatever TCP message digest techniques are available, and when 
>> one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward."
>>
>> We note that BGP has already been through this process, and replaced 
>> MD5 with TCP-AO in RFC 7454. I would be logical to follow the same 
>> approach to secure LDP. However, as far as we are able to ascertain, 
>> there is currently no recommended, mandatory to implement, 
>> cryptographic function specified. We are concerned that without such 
>> a mandatory function, implementations will simply fall back to MD5 
>> and we will be no further forward
>>
>> required TCP MD5 Signature Option. Furthermore, the TBD cryptographic 
>> mechanism must be implemented and provided to TCP-AO to secure LDP 
>> messages. The TBD mechanism is the preferred option, and MD5 is only 
>> to be used when TBD is unavailable."
>>
>> TCP security negotiation is still work in progress. If we are wrong, 
>> then we need to include a requirement that such negotiation is also 
>> required. In the absence of a negotiation protocol, however, we need 
>> to leave this as a configuration process until such time as the 
>> negotiation protocol work is complete. On completion of a suitable 
>> negotiation protocol we need to issue a further update requiring its use.
>>
>> can reasonably be implemented on a typical router route processor, 
>> and which will provide adequate security without significantly 
>> degrading the convergence time of an LSR. Without a function that 
>> does not significantly impact router convergence we simply close one 
>> As experts on the LDP protocol, but not on security mechanisms, we  
>> need to ask the security area for a review of our proposed approach, 
>> and help correcting any misunderstanding of the security issues or 
>> our misunderstanding of the existing security mechanisms. We also 
>> need the recommendations of a suitable security function (TBD in the above text).
>>
>> Best regards
>>
>> The MPLS WG Chairs
>> The PALS WG Chairs
>>
>>
>>
>>
>>
>>
>>
>>
>
>

-- 

Best regards,
Kathleen

---

From: "t.petch" <[email-masked]>
Date: Sat, 11 Nov 2017 12:40:15 -0000

----- Original Message -----
From: "Susan Hares" <[email-masked]>
Sent: Saturday, November 11, 2017 3:58 AM

> Kathleen and Eric:
>
> I agree that getting linux implementations with TCP-AO is one avenue
to drive things into product.   Any ideas on getting more deployment for
routing security - is really important.   Pushing both small and large
gains (TCP-AO, registration) will help us continually increase the
security.

After a lifetime of trying to forestall disasters, and failing, only to
have clients say afterwards 'I wish we had listened to you', my
conclusion is that the disaster has to happen first; only then will
users be motivated enough to incur the cost, the hassle of changing
their ways.

I see this with systems and networks, and I hear of just such a case
which led to the present level of security being added to BGP.

What we should - must - do is ensure that when disaster strikes, and
users are motivated, then the specifications are ready; two stalled
I-Ds, as was mentioned up-thread, is not ready.

Tom Petch

> I know Alia has been talking about a possible Linux implementation to
drive the way.  I agree with EKR on other points and have been following
along.
> >> Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared
to
> >> getting people to TCP-AO.
> >>
> >> Sue
> >>
https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with-
> >> tcp-ao-06.txt
> >> We should probably talk in Singapore about that, but that's not
going
> >> to get better any time soon.
> >>
> >> [0] Technically It has better support for rollover, but this is not
a
> >> huge improvement.
> >> <[email-masked]>  wrote:
> >>
> >> To the SEC and RTG ADs,
> >>
PALS
> >> WG Chairs.
2.
the
> >> "[RFC2385] asserts that MD5 authentication is now considered by
some
> >> one stronger than MD5 is specified and implemented, upgrading LDP
to use it would be relatively straightforward."
> >> We note that BGP has already been through this process, and
replaced
> >> required TCP MD5 Signature Option. Furthermore, the TBD
cryptographic
> >> TCP security negotiation is still work in progress. If we are
wrong,
> >> The TBD default security function will need to be chosen such that
it

---

From: Joe Touch <[email-masked]>
Date: Sat, 11 Nov 2017 08:06:25 -0800

> There’s no problem with updating, the problem is with adoption...

Sure, but I hope designing a new solution isn't assumed to be the best
way to achieve that. tcpinc showed that it's easy to get it wrong (it
may provide help to TCP content, but "TCP security" it isn't).

Joe

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 11 Nov 2017 14:53:27 -0500

Tom:

+1.    Wise words.  My father-in-law gave this same advice to the researchers at Corning.  Their projects - such as fiber optics went from "prototypes" to massive deployments with aid from standards + appropriate fixes.    

Sue 

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Saturday, November 11, 2017 7:40 AM
To: Susan Hares; 'Kathleen Moriarty'; 'Eric Rescorla'
Cc: [email-masked]; [email-masked]; [email-masked]; 'mpls-chairs'; [email-masked]; [email-masked]
Subject: Re: [mpls] LDP Security

----- Original Message -----
From: "Susan Hares" <[email-masked]>
Sent: Saturday, November 11, 2017 3:58 AM

to drive things into product.   Any ideas on getting more deployment for
routing security - is really important.   Pushing both small and large
gains (TCP-AO, registration) will help us continually increase the security.

After a lifetime of trying to forestall disasters, and failing, only to have clients say afterwards 'I wish we had listened to you', my conclusion is that the disaster has to happen first; only then will users be motivated enough to incur the cost, the hassle of changing their ways.

I see this with systems and networks, and I hear of just such a case which led to the present level of security being added to BGP.

What we should - must - do is ensure that when disaster strikes, and users are motivated, then the specifications are ready; two stalled I-Ds, as was mentioned up-thread, is not ready.

Tom Petch

> I know Alia has been talking about a possible Linux implementation to
drive the way.  I agree with EKR on other points and have been following along.
to
going
a
PALS
2.
the
some
replaced
cryptographic
wrong,
it

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 11 Nov 2017 15:45:56 -0500

Joe: 

No - the mentioning of deployment issues was just background on discussion and an expression of my personal angst on this topic. 

Sue Hares 
-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Saturday, November 11, 2017 11:06 AM
To: Jeff Tantsura
Cc: [email-masked]; Eric Rescorla; [email-masked]; [email-masked]; <[email-masked]>; [email-masked]; [email-masked]; <[email-masked]>
Subject: Re: [mpls] [tcpm] LDP Security

> There’s no problem with updating, the problem is with adoption...

Sure, but I hope designing a new solution isn't assumed to be the best way to achieve that. tcpinc showed that it's easy to get it wrong (it may provide help to TCP content, but "TCP security" it isn't).

Joe

---

From: Ignas Bagdonas <[email-masked]>
Date: Mon, 13 Nov 2017 09:24:00 +0000

An operator’s view here. Addressing multiple points in a single message 
here.

Yes, the issue is with adoption. It is not being adopted because the 
problem solution does not necessary address the actual problem.

Taking BGP as an example (and most of this applies to LDP as well) – we 
need to differentiate what security means in BGP context. Is it BGP 
transport security – the confidentiality of BGP messages exchanged 
between the peers (which MD5 or AO can address), or BGP information 
security – whether the peer is authorized to advertise a prefix and with 
what attributes (to which the presence or absence of MD5 and AO is 
orthogonal).

Any cryptographically strong security mechanism is not a substitute for 
practical operational hygiene. If you have right confidentiality 
mechanism for BGP transport but do not implement proper edge filtering – 
you will run into problems. Not because there will be a compromise of 
BGP session transport, but because there will be a variety of DoS forms 
on the BGP component itself and the platform on which it is running. 
Proper edge filtering plus TTL validation is good enough and simple 
enough to be universally deployed, and MD5 option is used to validate 
that you are indeed speaking to the same peer to which you were speaking 
before the maintenance window, it is a form of a strong checksum. AO or 
BGP over TLS (dare I to say that :-) ) does nothing to address the BGP 
information security aspects of who is or is not allowed to advertise 
certain types of BGP routing information – which is the source of 
virtually all of practical (and successful) attacks happening in BGP 
context. This is the reason why AO or some other strong cryptographic 
mechanism for BGP transport session is not on the top of the list of 
operational worries, if at that list at all. RPKI family of solutions 
tries to address the BGP information security part. It tries, not 
necessary addresses it in a practical way. But that is above the session 
level security problems.

Any cryptographically strong security mechanism is not a substitute for 
proper network design. Taking the DC example, if the attack vector is 
based on the tenant’s ability to interfere with BGP sessions used for 
controlling the topology that does not belong to the tenant – that is a 
broken network design, and it should be fixed first before trying to fix 
BGP itself. BGP is not at fault here, the design of the network that 
does not allow for sufficient isolation between entities is. No protocol 
is able to fix the design problems by itself.

This does not mean that AO or some other transport security mechanism is 
not relevant or not needed. At least the solution for key rollover that 
is better than manual synchronization over phone is definitely of value.

Ignas

On 11/11/2017 03:11, Jeff Tantsura wrote:
> On Nov 11, 2017, at 08:48, Joe Touch <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi, all,
>>
>> M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. 
>> Chunduri, A. Tian, J. Touch, “Negotiation for Keying Pairwise Routing 
>> Protocols in IKEv2 
>> <http://www.isi.edu/touch/pubs/draft-mahesh-karp-rkmp-05.txt>,” (RFC 
>> in progress), Nov. 2013.
>>
>> AFAICT, that would go a long way towards addressing the issues with 
>> its use outside routing environments where keys are already 
>> considered sufficiently managed.
>>
>> implementations available in end system OSes (AFAICT). Designing a 
>> new solution simply to avoid implementing an existing one would be a 
>>> draft-nayak-tcp-sha2-02), but so far there was not much energy and 
>>> no interest from potential TCP-AO implementers or users.
>>>
>>> Michael
>>>
>>> (TCPM co-chair)
>>>
>>> a huge improvement.
>>>     working groups that develop the LDP protocol that LDP is no
>>>     longer adequately secured. LDP currently relies on MD5 for
>>>     cryptographic security of its messages, but MD5 is a hash
>>>     function that is no longer considered to meet current security
>>>     requirements.
>>>
>>>     In RFC5036 (published 2007) Section 5.1 (Spoofing) , List
>>>     element 2. Session communication carried by TCP the following
>>>     statements is made:
>>>
>>>     "LDP specifies use of the TCP MD5 Signature Option to provide
>>>     for the authenticity and integrity of session messages.
>>>
>>>     some to be too weak for this application.  It also points out
>>>     that a similar TCP option with a stronger hashing algorithm (it
>>>     cites SHA-1 as an example) could be deployed.  To our knowledge,
>>>     no such TCP option has been defined and deployed. However, we
>>>     note that LDP can use whatever TCP message digest techniques are
>>>     available, and when one stronger than MD5 is specified and
>>>     replaced MD5 with TCP-AO in RFC 7454. I would be logical to
>>>     follow the same approach to secure LDP. However, as far as we
>>>     are able to ascertain, there is currently no recommended,
>>>     mandatory to implement, cryptographic function specified. We are
>>>     concerned that without such a mandatory function,
>>>     implementations will simply fall back to MD5 and we will be no
>>>     further forward
>>>
>>>     secure the TCP sessions carrying LDP in addition to the
>>>     currently required TCP MD5 Signature Option. Furthermore, the
>>>     TBD cryptographic mechanism must be implemented and provided to
>>>     TCP-AO to secure LDP messages. The TBD mechanism is the
>>>     preferred option, and MD5 is only to be used when TBD is
>>>     unavailable."
>>>
>>>     We are not an experts on this part of the stack, but it seems
>>>     that TCP security negotiation is still work in progress. If we
>>>     are wrong, then we need to include a requirement that such
>>>     negotiation is also required. In the absence of a negotiation
>>>     protocol, however, we need to leave this as a configuration
>>>     process until such time as the negotiation protocol work is
>>>     complete. On completion of a suitable negotiation protocol we
>>>     need to issue a further update requiring its use.
>>>
>>>     Additionally we should note that no cryptographic mechanism has
>>>     an indefinite lifetime, and that implementation should note the
>>>     IETF anticipates updating the default cryptographic mechanism
>>>     over time.
>>>
>>>     The TBD default security function will need to be chosen such
>>>     that it can reasonably be implemented on a typical router route
>>>     significantly degrading the convergence time of an LSR. Without
>>>     a function that does not significantly impact router convergence
>>>     we simply close one vulnerability and open another.
>>>
>>>     approach, and help correcting any misunderstanding of the
>>>     security issues or our misunderstanding of the existing security
>> [email-masked] <mailto:[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Nov 2017 06:10:21 -0800

On 11/13/2017 1:24 AM, Ignas Bagdonas wrote:
>
> An operator’s view here. Addressing multiple points in a single
> message here.
>
> Taking BGP as an example (and most of this applies to LDP as well) –
> we need to differentiate what security means in BGP context. Is it BGP
> security – whether the peer is authorized to advertise a prefix and
> with what attributes (to which the presence or absence of MD5 and AO
> is orthogonal).
>
I had thought it was widely understood that there are two components to
protecting BGP:

        - TCP-AO - to protect the TCP connections from attack and
authenticate the endpoint pairs
        - BGPsec - to validate the authenticity of relayed prefix
advertisements and ensure its legitimacy

Is there a third aspect that isn't included here that you feel is
missing? Or do you feel one of these inadequate in performing *the
function it is designed for*?

Joe