Re: [mpls] LDP Security

Eric Rescorla <ekr@rtfm.com> Thu, 09 November 2017 19:10 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 24B5E12951C for <mpls@ietfa.amsl.com>; Thu, 9 Nov 2017 11:10:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 9Mi8q4LLGfIv for <mpls@ietfa.amsl.com>; Thu, 9 Nov 2017 11:10:18 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 F33E7129521 for <mpls@ietf.org>; Thu, 9 Nov 2017 11:10:14 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id i198so6205485ywe.7 for <mpls@ietf.org>; Thu, 09 Nov 2017 11:10:14 -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=aZ8EIByYnQBBR3oE8p1KV4Dhw4JoBysuLhEM80kt044=; b=fwmNWySR7vGmthTP9CnJgCUm3/Icy8NBGDeX4iheWzOHLsqT35bTsoARX2r9tALgjt RFvrceTtYHJH+TrcDqedw4py2m/enRLLT5YTBg81UM6cXP9cuW30l8M4zcGgeWevkqqG F649HkE9jCcX74OVjvekaG0U6+ihcYfrtb/oxsp+ufgwUTxGpIb+QhsiWUE6heiw1KrQ stTagftdXc7ZMt6LKxg3FPnuZuvndR13M2g7WETydJiHfAQK+4dLOsVOycVLZB/E7oje YsOztCn1oXsTOkoCNwSZi9mPo9L0L1SvyAusJKD+lTUGI3n0zYR+ijUni9t7BxTmikoP VXZQ==
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=aZ8EIByYnQBBR3oE8p1KV4Dhw4JoBysuLhEM80kt044=; b=HPaGRIOjJGf3EaysTdMhFM+SzUIe6wVOJmo85aseUKASLvZ3kPqJQG8S4eyGST8bXZ nrhO+5jpJgr9j67I7dsMNm6CpRzLWvbAoIfR9zCWdLjDMpgm4u24BgvAdqb9wm1mwcC4 oRRHlVgkhRqVmr3jxAQw9G65kw01CNEWEDNguw7ukBI/+v1FUgFOngO7oe7gtq1dXKyp rpNeFsZ8TQjhvzdO2INBK8uEJqmKuJQh8/FLF4+gRbvuh2ypGPmCoios5OpU2X/3EHEN 5vyWlIangQA91iOUYLTsZCb8iOZ4GwRW61+3uXV8ukM2ed+xQBBuU9MaDrmIMzxRnz2d goVA==
X-Gm-Message-State: AJaThX5e99UZ1OtEoZ7XhFqJfZnXMUt4/OzYqBX9cSvm6oeMtNxrDGzO CeMYhnGable+GvM5c5pEx17Q1IAtMPEvf0e4k8b/Ow==
X-Google-Smtp-Source: ABhQp+SrCmrm5XvVNo3+tZg6gndXvDC4SUq19MleqUhNI4uREHXnWRdFNiRldmTS6L4cbBKkr5NrwHe2hp0xNP3MWuU=
X-Received: by 10.129.108.3 with SMTP id h3mr1065022ywc.327.1510254613983; Thu, 09 Nov 2017 11:10:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Thu, 9 Nov 2017 11:09:33 -0800 (PST)
In-Reply-To: <002101d35919$c6295b90$527c12b0$@ndzh.com>
References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <d3b28075-d8c0-c677-1f4b-6ad5ee5539ca@gmail.com> <CAA=duU2PzZLymVZk-PR9B94Pj1WMsHe+TTv51Ukef2MaSg-DbA@mail.gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <CAA=duU2YLjSg8Q5PDT+u9cxn9u2xsiPu-imBJrnyL3bfkQFW7A@mail.gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <CAA=duU3nJsS86udidgkH9jhB9ZD+xaRa2A4MniAVL1BpGE78ZQ@mail.gmail.com> <cf0cb5a4-cc21-97e1-1c26-38974bf9c0be@pi.nu> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <CAA=duU2R9kBMWnRdwPPO49LF1Jc1tyrxvwkyTgaE6SC6jsVruw@mail.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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 9 Nov 2017 11:09:33 -0800
Message-ID: <CABcZeBMqYCaq_g+dP_Q4rFjQgS_oG+iYtDg=qp1e9Rc4yZ9U9A@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: Uma Chunduri <uma.chunduri@huawei.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>
Content-Type: multipart/alternative; boundary="001a114d9a28c9a6e2055d918dba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ucZuczQBnu6uaEp5O6eNNIAqzpU>
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: Thu, 09 Nov 2017 19:10:22 -0000

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