Re: [Pals] [mpls] LDP Security

[Kathleen Moriarty <[e-mail]>]

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