Re: [Pals] [mpls] LDP Security

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Uma Chunduri-3

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:[hidden email]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <[hidden email]>
Cc: [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
Subject: Re: [mpls] LDP Security

 

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

 

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

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

 


_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Eric Gray (LO/EUS)
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:[hidden email]] On Behalf Of Stewart Bryant
Sent: Wednesday, November 08, 2017 12:28 PM
To: [hidden email]; <[hidden email]> <[hidden email]>
Cc: [hidden email]; [hidden email]; [hidden email]; [hidden email]
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.

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


_______________________________________________
mpls mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Eric Gray (LO/EUS)
In reply to this post by Uma Chunduri-3

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

 

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

 

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

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

 


_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Uma Chunduri-3
In reply to this post by Uma Chunduri-3

In-line [Uma1]:

--

Uma C.

 

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

 

 

 

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

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:[hidden email]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <[hidden email]>
Cc: [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
Subject: Re: [mpls] LDP Security

 

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

 

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

 

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

 

 

 

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.

 

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

 

[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

 

 

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

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

 

 


_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Eric Rescorla-3


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

In-line [Uma1]:

--

Uma C.

 

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


Subject: Re: [mpls] LDP Security

 

 

 

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

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:[hidden email]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <[hidden email]>
Cc: [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
Subject: Re: [mpls] LDP Security

 

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

 

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

 

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

 

 

 

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.

 

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

 

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

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
 

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

 

 

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

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

 

 



_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Eric Rescorla-3
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 <[hidden email]> wrote:

From: Eric Rescorla [mailto:[hidden email]]
Sent: Wednesday, November 08, 2017 3:53 PM


To: Uma Chunduri <[hidden email]>
Cc: Stewart Bryant <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
Subject: Re: [mpls] LDP Security

 

 

 

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

In-line [Uma1]:

--

Uma C.

 

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


Subject: Re: [mpls] LDP Security

 

 

 

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

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:[hidden email]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <[hidden email]>
Cc: [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
Subject: Re: [mpls] LDP Security

 

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

 

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

 

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

 

 

 

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.

 

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

 

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

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

 

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

 

 

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

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

 

 

 



_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Eric Rescorla-3

On Wed, Nov 8, 2017 at 5:09 PM, Uma Chunduri <[hidden email]> 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.



_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Uma Chunduri-3

 

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

 

 

On Wed, Nov 8, 2017 at 5:09 PM, Uma Chunduri <[hidden email]> 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"?

 

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.

 


_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Susan Hares-4
In reply to this post by Eric Rescorla-3

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:[hidden email]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 8, 2017 7:44 PM
To: Uma Chunduri
Cc: [hidden email]; [hidden email]; <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]>
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.

 

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

From: Eric Rescorla [mailto:[hidden email]]
Sent: Wednesday, November 08, 2017 3:53 PM


To: Uma Chunduri <[hidden email]>
Cc: Stewart Bryant <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
Subject: Re: [mpls] LDP Security

 

 

 

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

In-line [Uma1]:

--

Uma C.

 

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


Subject: Re: [mpls] LDP Security

 

 

 

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

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:[hidden email]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <[hidden email]>
Cc: [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
Subject: Re: [mpls] LDP Security

 

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

 

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

 

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

 

 

 

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.

 

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

 

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

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

 

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

 

 

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

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

 

 

 

 


_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Eric Rescorla-3
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 <[hidden email]> 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.  

 

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:[hidden email]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 8, 2017 7:44 PM
To: Uma Chunduri
Cc: [hidden email]; [hidden email]; <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]>


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.

 

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

From: Eric Rescorla [mailto:[hidden email]]
Sent: Wednesday, November 08, 2017 3:53 PM


To: Uma Chunduri <[hidden email]>
Cc: Stewart Bryant <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
Subject: Re: [mpls] LDP Security

 

 

 

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

In-line [Uma1]:

--

Uma C.

 

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


Subject: Re: [mpls] LDP Security

 

 

 

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

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:[hidden email]] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <[hidden email]>
Cc: [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
Subject: Re: [mpls] LDP Security

 

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

 

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

 

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

 

 

 

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.

 

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

 

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

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

 

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

 

 

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

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

 

 

 

 



_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Stewart Bryant-2
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


On 09/11/2017 20:09, Kathleen Moriarty wrote:

> On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla <[hidden email]> 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
>> -Ekr
>>
>>
>> On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares <[hidden email]> 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.
>>>
>>>
>>>
>>> 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:[hidden email]] On Behalf Of Eric Rescorla
>>> Sent: Wednesday, November 8, 2017 7:44 PM
>>> To: Uma Chunduri
>>> Cc: [hidden email]; [hidden email]; <[hidden email]>;
>>> [hidden email]; [hidden email]; <[hidden email]>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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 <[hidden email]>
>>> wrote:
>>>
>>> From: Eric Rescorla [mailto:[hidden email]]
>>> Sent: Wednesday, November 08, 2017 3:53 PM
>>>
>>>
>>> To: Uma Chunduri <[hidden email]>
>>> Cc: Stewart Bryant <[hidden email]>; [hidden email];
>>> [hidden email]; <[hidden email]> <[hidden email]>;
>>> [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
>>> Subject: Re: [mpls] LDP Security
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <[hidden email]>
>>> wrote:
>>>
>>> In-line [Uma1]:
>>>
>>> --
>>>
>>> Uma C.
>>>
>>>
>>>
>>> From: Eric Rescorla [mailto:[hidden email]]
>>> Sent: Wednesday, November 08, 2017 12:53 PM
>>> To: Uma Chunduri <[hidden email]>
>>> Cc: Stewart Bryant <[hidden email]>; [hidden email];
>>> [hidden email]; <[hidden email]> <[hidden email]>;
>>> [hidden email]; [hidden email]; <[hidden email]> <[hidden email]>
>>>
>>>
>>> Subject: Re: [mpls] LDP Security
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <[hidden email]>
>>> wrote:
>>>
>>> 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:[hidden email]] On Behalf Of Eric Rescorla
>>> Sent: Wednesday, November 08, 2017 10:00 AM
>>> To: Stewart Bryant <[hidden email]>
>>> Cc: [hidden email]; [hidden email]; <[hidden email]>
>>> <[hidden email]>; [hidden email]; [hidden email]; <[hidden email]>
>>> <[hidden email]>
>>> Subject: Re: [mpls] LDP Security
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> [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).
>>>
>>>
>>>
>>> Yeah, I know that people tried to do this, but my impression was it kinda
>>> didn't progress much.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Generally we're trying to move away from SHA-1 towards SHA-256.
>>>
>>>
>>>
>>> [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.
>>>
>>> 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
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> [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 <[hidden email]>
>>> wrote:
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>

_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

Re: [Pals] [mpls] LDP Security

Susan Hares-4
In reply to this post by Eric Rescorla-3
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:[hidden email]]
Sent: Thursday, November 9, 2017 3:09 PM
To: Eric Rescorla
Cc: Susan Hares; Uma Chunduri; [hidden email]; [hidden email]; <[hidden email]>; mpls-chairs; [hidden email]; <[hidden email]>
Subject: Re: [mpls] LDP Security

On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla <[hidden email]> 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

>
> -Ekr
>
>
> On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares <[hidden email]> 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.
>>
>>
>>
>> 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:[hidden email]] On Behalf Of Eric Rescorla
>> Sent: Wednesday, November 8, 2017 7:44 PM
>> To: Uma Chunduri
>> Cc: [hidden email]; [hidden email]; <[hidden email]>;
>> [hidden email]; [hidden email]; <[hidden email]>
>>
>>
>> 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.
>>
>>
>>
>> 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
>> <[hidden email]>
>> wrote:
>>
>> From: Eric Rescorla [mailto:[hidden email]]
>> Sent: Wednesday, November 08, 2017 3:53 PM
>>
>>
>> To: Uma Chunduri <[hidden email]>
>> Cc: Stewart Bryant <[hidden email]>; [hidden email];
>> [hidden email]; <[hidden email]> <[hidden email]>;
>> [hidden email]; [hidden email]; <[hidden email]>
>> <[hidden email]>
>> Subject: Re: [mpls] LDP Security
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri
>> <[hidden email]>
>> wrote:
>>
>> In-line [Uma1]:
>>
>> --
>>
>> Uma C.
>>
>>
>>
>> From: Eric Rescorla [mailto:[hidden email]]
>> Sent: Wednesday, November 08, 2017 12:53 PM
>> To: Uma Chunduri <[hidden email]>
>> Cc: Stewart Bryant <[hidden email]>; [hidden email];
>> [hidden email]; <[hidden email]> <[hidden email]>;
>> [hidden email]; [hidden email]; <[hidden email]>
>> <[hidden email]>
>>
>>
>> Subject: Re: [mpls] LDP Security
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri
>> <[hidden email]>
>> wrote:
>>
>> 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:[hidden email]] On Behalf Of Eric Rescorla
>> Sent: Wednesday, November 08, 2017 10:00 AM
>> To: Stewart Bryant <[hidden email]>
>> Cc: [hidden email]; [hidden email]; <[hidden email]>
>> <[hidden email]>; [hidden email]; [hidden email];
>> <[hidden email]> <[hidden email]>
>> Subject: Re: [mpls] LDP Security
>>
>>
>>
>> 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
>>
>>
>>
>> [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).
>>
>>
>>
>> Yeah, I know that people tried to do this, but my impression was it
>> kinda didn't progress much.
>>
>>
>>
>>
>>
>>
>>
>> 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.
>>
>>
>>
>> Generally we're trying to move away from SHA-1 towards SHA-256.
>>
>>
>>
>> [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.
>>
>> 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
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>> [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
>> <[hidden email]>
>> wrote:
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>
>



--

Best regards,
Kathleen

_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals