Re: [mpls] LDP Security

["Susan Hares" <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, November 9, 2017 3:09 PM
To: Eric Rescorla
Cc: Susan Hares; Uma Chunduri; [e-mail]; [e-mail]; <[e-mail]>; mpls-chairs; [e-mail]; <[e-mail]>
Subject: Re: [mpls] LDP Security

On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla <[e-mail]> 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 <[e-mail]> 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:[e-mail]] On Behalf Of Eric Rescorla
>> Sent: Wednesday, November 8, 2017 7:44 PM
>> To: Uma Chunduri
>> Cc: [e-mail]; [e-mail]; <[e-mail]>; 
>> [e-mail]; [e-mail]; <[e-mail]>
>>
>>
>> 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 
>> <[e-mail]>
>> wrote:
>>
>> From: Eric Rescorla [mailto:[e-mail]]
>> Sent: Wednesday, November 08, 2017 3:53 PM
>>
>>
>> To: Uma Chunduri <[e-mail]>
>> Cc: Stewart Bryant <[e-mail]>; [e-mail]; 
>> [e-mail]; <[e-mail]> <[e-mail]>; 
>> [e-mail]; [e-mail]; <[e-mail]> 
>> <[e-mail]>
>> Subject: Re: [mpls] LDP Security
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri 
>> <[e-mail]>
>> wrote:
>>
>> In-line [Uma1]:
>>
>> --
>>
>> Uma C.
>>
>>
>>
>> From: Eric Rescorla [mailto:[e-mail]]
>> Sent: Wednesday, November 08, 2017 12:53 PM
>> To: Uma Chunduri <[e-mail]>
>> Cc: Stewart Bryant <[e-mail]>; [e-mail]; 
>> [e-mail]; <[e-mail]> <[e-mail]>; 
>> [e-mail]; [e-mail]; <[e-mail]> 
>> <[e-mail]>
>>
>>
>> Subject: Re: [mpls] LDP Security
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri 
>> <[e-mail]>
>> 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:[e-mail]] On Behalf Of Eric Rescorla
>> Sent: Wednesday, November 08, 2017 10:00 AM
>> To: Stewart Bryant <[e-mail]>
>> Cc: [e-mail]; [e-mail]; <[e-mail]> 
>> <[e-mail]>; [e-mail]; [e-mail]; 
>> <[e-mail]> <[e-mail]>
>> 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 
>> <[e-mail]>
>> 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