Re: [mpls] LDP Security

Eric Rescorla <ekr@rtfm.com> Fri, 10 November 2017 07:16 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178D212EB68 for <mpls@ietfa.amsl.com>; Thu, 9 Nov 2017 23:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDzfK2FJOuTC for <mpls@ietfa.amsl.com>; Thu, 9 Nov 2017 23:16:08 -0800 (PST)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBD312EB71 for <mpls@ietf.org>; Thu, 9 Nov 2017 23:16:06 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id q1so7437018ywh.5 for <mpls@ietf.org>; Thu, 09 Nov 2017 23:16:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9H37yw4fcL6CsxOpblHeImKfp+2lbd+c/PW5qlGKr8A=; b=a+ULuRxxTiYinzDdokc7psk4BqRouVR/U4EXZLmuz5RK6FzrIptfgCIhcsd3YGynXd /h2aiN+7yNXvJuCcrx7/EzQOWCT0oMeIfnwPCVqY78PHUTWVlbTJ26GzzRdh5jhgKvZ0 Phdp1ATLjUnhAlqXpXpGqxDNe6EF7gJ0nNDxL/dzk4BkYNHSHra0H7qh3rJrvwe1Trm2 LvOLcGrtf5QfpqcqATeRLGD6y57pJ75flANHA8pnnqykR6wtb3o4a1rWxck4XI7MwHAK QcjfnZHvZU171FwsFAPX2bZXd3ajDE5jDcX0TY0ayoTjI9F+YSEZXsKe54nDE8GnG+bH 4ScQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9H37yw4fcL6CsxOpblHeImKfp+2lbd+c/PW5qlGKr8A=; b=LCwYRpVpEFXlK1MBD9nnpCv3K0oVxt0EH+KHvgpqpcMOqtFZJwxVa6HMHyfWfA671P JS86k/NcqKjLR6J2u4KuKqytAedx9jC++RThVqNGYOpCcn/932mv9Z4QaDjCv11Gyr1T NBGk5agym8oBcE2hx+4Xehs7KT1Gc/z0GjpjxXkDxb86rj/z5a5YzQsthuJoXCOanDXm mBXwXC2oraiPF6hH08c/1CFZLNx2Uy4PJvcKR+CQhjprhz0ARmLJHvRfqOfTl2k3aCNG uS/dFYoJgnK7hZAVx8wXzbaSuWkqfVKYKaq0VVYYnp/q3JEhugvUgOAEMFGOSKv1ZCdp b86w==
X-Gm-Message-State: AJaThX7kEsxXChAwWmH1wRe/8beMfHTYVh5TwZoWg7+Md7yvedg4moO3 EF19ki0iIpepZbPV7Ps1DZC5LrQUun9fZLguEUjJKQ==
X-Google-Smtp-Source: ABhQp+SBMvmPBlf+ZoJoQD4XSd1A0SmMklbkX89s2fM46YI7jmWODR++swcb7u5HVTOz29HHQEHla5nDivD1ge2sjJ4=
X-Received: by 10.129.26.208 with SMTP id a199mr2017597ywa.280.1510298166033; Thu, 09 Nov 2017 23:16:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Thu, 9 Nov 2017 23:15:25 -0800 (PST)
In-Reply-To: <b8e4f56f-c49b-23b3-72c2-58dbd1de3188@gmail.com>
References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <CAA=duU1qV-LiU5pR7VtLLVGtb-8nZHrnUqVyOKpST3-6Dr-Xgw@mail.gmail.com> <ce2c75b6-156d-da80-91d7-b7e6ba2059a0@gmail.com> <CAA=duU1xvV0genbR0CBx2rmpOWUkFmRJX3qrMEp21gTd1HOVww@mail.gmail.com> <f0d553da-0ac4-e794-5cd5-d9cc95063dc6@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <CABcZeBOr5x=98nXeBCT8O-wjk90ga1F3EVk2ktMYoAj9Q8tRkg@mail.gmail.com> <CABcZeBO6msQuxGLtWp4HDQAGtubOp-33Gt+uip5P3y2-icnRqg@mail.gmail.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <CABcZeBPK=ze90qa1qzMsUMVN_=5Pf85Nv6uanEvsV5nVR4v0HA@mail.gmail.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <CABcZeBO56DrS9EAUJ2WwD3ucR9+HvDem3AQVVe_CzY55TgXkQQ@mail.gmail.com> <002101d35919$c6295b90$527c12b0$@ndzh.com> <CABcZeBMqYCaq_g+dP_Q4rFjQgS_oG+iYtDg=qp1e9Rc4yZ9U9A@mail.gmail.com> <CAHbuEH4mewYdnuOvxRhfgsBBmf+goZt-iwdAge8GeLAcEBB9Fw@mail.gmail.com> <b8e4f56f-c49b-23b3-72c2-58dbd1de3188@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 09 Nov 2017 23:15:25 -0800
Message-ID: <CABcZeBObruJdH84PCDAXHkjsxEr2fWP1ES8siYbhr3R8LnfMWA@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, mpls@ietf.org, pals-chairs@tools.ietf.org, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>, pals@ietf.org, "<sec-ads@ietf.org>" <sec-ads@ietf.org>
Content-Type: multipart/alternative; boundary="001a1142d0d4b121a5055d9bb133"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/MbDp1XDuWj7nZEeTKHTtfp1Qkvo>
Subject: Re: [mpls] LDP Security
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Nov 2017 07:16:12 -0000

On Thu, Nov 9, 2017 at 3:02 PM, Stewart Bryant <stewart.bryant@gmail.com>
wrote:

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

FWIW, I agree that MD5 is a fine checksum.

-Ekr


>
> 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 <ekr@rtfm.com> 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 <shares@ndzh.com> 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:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
>>>> Sent: Wednesday, November 8, 2017 7:44 PM
>>>> To: Uma Chunduri
>>>> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org>;
>>>> mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org>
>>>>
>>>>
>>>> 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 <uma.chunduri@huawei.com>
>>>> wrote:
>>>>
>>>> From: Eric Rescorla [mailto:ekr@rtfm.com]
>>>> Sent: Wednesday, November 08, 2017 3:53 PM
>>>>
>>>>
>>>> To: Uma Chunduri <uma.chunduri@huawei.com>
>>>> Cc: Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org;
>>>> pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>;
>>>> mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org> <
>>>> sec-ads@ietf.org>
>>>> Subject: Re: [mpls] LDP Security
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <uma.chunduri@huawei.com>
>>>> wrote:
>>>>
>>>> In-line [Uma1]:
>>>>
>>>> --
>>>>
>>>> Uma C.
>>>>
>>>>
>>>>
>>>> From: Eric Rescorla [mailto:ekr@rtfm.com]
>>>> Sent: Wednesday, November 08, 2017 12:53 PM
>>>> To: Uma Chunduri <uma.chunduri@huawei.com>
>>>> Cc: Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org;
>>>> pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>;
>>>> mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org> <
>>>> sec-ads@ietf.org>
>>>>
>>>>
>>>> Subject: Re: [mpls] LDP Security
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <uma.chunduri@huawei.com>
>>>> 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:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
>>>> Sent: Wednesday, November 08, 2017 10:00 AM
>>>> To: Stewart Bryant <stewart.bryant@gmail.com>
>>>> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org>
>>>> <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; <
>>>> sec-ads@ietf.org>
>>>> <sec-ads@ietf.org>
>>>> 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-ik
>>>> ev2-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 <
>>>> stewart.bryant@gmail.com>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>