Re: [tcpm] [mpls] LDP Security

[Ignas Bagdonas <[e-mail]>]

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

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

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

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

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

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

Ignas


On 11/11/2017 03:11, Jeff Tantsura wrote:
> Joe,
>
> There’s no problem with updating, the problem is with adoption...
>
> Regards,
> Jeff
>
> On Nov 11, 2017, at 08:48, Joe Touch <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> Hi, all,
>>
>> I don't see a problem if there's a need for updating TCP-AO to 
>> include/require other algorithms. It was intended to be extensible.
>>
>> I agree with the issue of key management. There was some work on 
>> extensions to IKE to enable its use to manage TCP-AO parameters and 
>> keys, but it stalled twice:
>>
>> M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. 
>> Chunduri, A. Tian, J. Touch, “Negotiation for Keying Pairwise Routing 
>> Protocols in IKEv2 
>> <http://www.isi.edu/touch/pubs/draft-mahesh-karp-rkmp-05.txt>,” (RFC 
>> in progress), Nov. 2013.
>>
>> U. Chunduri, A. Tian, J. Touch, “Using IKEv2 with TCP-AO 
>> <http://www.isi.edu/touch/pubs/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt>,” 
>> (RFC in progress), Feb. 2014.
>>
>> AFAICT, that would go a long way towards addressing the issues with 
>> its use outside routing environments where keys are already 
>> considered sufficiently managed.
>>
>> However, the larger problem with TCP-AO is that there are no 
>> implementations available in end system OSes (AFAICT). Designing a 
>> new solution simply to avoid implementing an existing one would be a 
>> significant waste of time.
>>
>> Joe
>>
>>
>> On 11/10/2017 8:21 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>>
>>> +TCPM
>>>
>>> Please free to discuss changes to TCP-AO on the TCPM list, or speak 
>>> up at the upcoming TCPM meeting.
>>>
>>> The addition of SHA-256 has been discussed in TCPM already (see 
>>> draft-nayak-tcp-sha2-02), but so far there was not much energy and 
>>> no interest from potential TCP-AO implementers or users.
>>>
>>> Michael
>>>
>>> (TCPM co-chair)
>>>
>>> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Eric Rescorla
>>> *Sent:* Wednesday, November 08, 2017 7:00 PM
>>> *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 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 
>>> <[e-mail] <mailto:[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
>>>
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/mpls
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls