Re: [Pals] [mpls] LDP Security
Eric Rescorla <ekr@rtfm.com> Wed, 08 November 2017 20:53 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B403129BEF for <pals@ietfa.amsl.com>; Wed, 8 Nov 2017 12:53:28 -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 gCPonmLSP081 for <pals@ietfa.amsl.com>; Wed, 8 Nov 2017 12:53:25 -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 D23BD129BF0 for <pals@ietf.org>; Wed, 8 Nov 2017 12:53:22 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id k3so3469863ywk.8 for <pals@ietf.org>; Wed, 08 Nov 2017 12:53:22 -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=GBXv3fjmoifgs2bTfFEd/Y+Z6YL2UrfYuI4s5yqrBw8=; b=t9afKuIHH0xfXCZsDraQLqnC8UDzB6lyjQbR12SxEn2H72abuK647uxxN0Nzeu+36J iWYQX8jtkCXC+CR7VxgZx4M0e/R+OW0o+OoKT1c7nuvOBno0P7ocmKPKJgtv/cOEXX3D fezp2IfosYk40PDAUm2f+720ItTfVVFuGYF4yoRy/G9VpvGgJp23/aWtxUdxyhUkuid1 ym3ETGdQkr8FRLUpGuhV5FoRLwEDbCAq27T/fGrOu4v3AxT0P7biZ4n7ogp2Lol4Wmhd oNsdWLV/BiXrbRLd0eV1006g9V/uagCCY+wHoXarjcNTmn/UQBQ5TCSIxSh41U4uYg9H qQYw==
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=GBXv3fjmoifgs2bTfFEd/Y+Z6YL2UrfYuI4s5yqrBw8=; b=JXukr/db6zDXj/DpWeAicPnVnuVheDAV35mqIIDGWB/nyWen2i0UrqfScnUDWRD8fD zHWJ+Xf3hoEEUJgbHfuogmsxaL2QqlV4J4mMMl2LzUy+w73C54ALpO5wSI9Fi0zecJtu ELmu7EqNbGc2R1wgexWHBvGIRcg6/ZbXGhLXLPUYMubhA5IBECd9RSvJWHdEsPB+Knrn OcyKnOaDCtJ/c30sI3y44/X0RqBK2pfTV5W09SAyWT9aL5REJlrL2VXbfolG4tbK3ZRu 7LpxSfZk9hP7lB94e+Mm01+VxfmpP6/QMkvRm6odV1CRzxZfgx3tyhgrACOSxNQxzoNt zCUw==
X-Gm-Message-State: AJaThX4E4VtQJhOjCgf/KOanpywD91scDNfRYeURDwevVWPicfmuerYW 1iMW6MRvvfEdJrXCrY0NC+IVGBSWuCgI37zeKOlN+Q==
X-Google-Smtp-Source: ABhQp+TCdFSl2i3LKNcwwoMuBZchMlbEkjP9uBKDp83NWSZKlal1p87d0lC53vxI4gRJ4ntGn/KzmnlLTvl7nwNzCoE=
X-Received: by 10.37.209.208 with SMTP id i199mr1213171ybg.339.1510174401937; Wed, 08 Nov 2017 12:53:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 12:52:40 -0800 (PST)
In-Reply-To: <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.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> <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 08 Nov 2017 12:52:40 -0800
Message-ID: <CABcZeBO6msQuxGLtWp4HDQAGtubOp-33Gt+uip5P3y2-icnRqg@mail.gmail.com>
To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, "mpls@ietf.org" <mpls@ietf.org>, "pals-chairs@tools.ietf.org" <pals-chairs@tools.ietf.org>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "pals@ietf.org" <pals@ietf.org>, "<sec-ads@ietf.org>" <sec-ads@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05e1a6c6da8d055d7ee0eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/OIpc21SReDqil9Vx6NPzqI60hzk>
Subject: Re: [Pals] [mpls] LDP Security
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2017 20:53:28 -0000
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. -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 > > >
- [Pals] LDP Security Stewart Bryant
- Re: [Pals] LDP Security Eric Rescorla
- Re: [Pals] [mpls] LDP Security Uma Chunduri
- Re: [Pals] [mpls] LDP Security Eric Rescorla
- Re: [Pals] [mpls] LDP Security Eric Gray
- Re: [Pals] [mpls] LDP Security Eric Gray
- Re: [Pals] [mpls] LDP Security Uma Chunduri
- Re: [Pals] [mpls] LDP Security Eric Rescorla
- Re: [Pals] [mpls] LDP Security Uma Chunduri
- Re: [Pals] [mpls] LDP Security Eric Rescorla
- Re: [Pals] [mpls] LDP Security Uma Chunduri
- Re: [Pals] [mpls] LDP Security Eric Rescorla
- Re: [Pals] [mpls] LDP Security Uma Chunduri
- Re: [Pals] [mpls] LDP Security Susan Hares
- Re: [Pals] [mpls] LDP Security Eric Rescorla
- Re: [Pals] [mpls] LDP Security Kathleen Moriarty
- Re: [Pals] [mpls] LDP Security Stewart Bryant
- Re: [Pals] [mpls] LDP Security Eric Rescorla
- Re: [Pals] [mpls] LDP Security Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [Pals] [mpls] LDP Security Susan Hares
- Re: [Pals] [mpls] [tcpm] LDP Security Jeff Tantsura
- Re: [Pals] [tcpm] [mpls] LDP Security Joe Touch
- Re: [Pals] [mpls] LDP Security t.petch
- Re: [Pals] [mpls] LDP Security Susan Hares
- Re: [Pals] [tcpm] [mpls] LDP Security Joe Touch
- Re: [Pals] [mpls] [tcpm] LDP Security Susan Hares
- Re: [Pals] [mpls] [tcpm] LDP Security Ignas Bagdonas
- Re: [Pals] [mpls] [tcpm] LDP Security Joe Touch