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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >
- [mpls] LDP Security Stewart Bryant
- Re: [mpls] LDP Security Eric Rescorla
- Re: [mpls] LDP Security Uma Chunduri
- Re: [mpls] LDP Security Eric Rescorla
- Re: [mpls] LDP Security Eric Gray
- Re: [mpls] LDP Security Eric Gray
- Re: [mpls] LDP Security Uma Chunduri
- Re: [mpls] LDP Security Eric Rescorla
- Re: [mpls] LDP Security Uma Chunduri
- Re: [mpls] LDP Security Eric Rescorla
- Re: [mpls] LDP Security Uma Chunduri
- Re: [mpls] LDP Security Eric Rescorla
- Re: [mpls] LDP Security Uma Chunduri
- Re: [mpls] LDP Security Susan Hares
- Re: [mpls] LDP Security Eric Rescorla
- Re: [mpls] LDP Security Kathleen Moriarty
- Re: [mpls] LDP Security Stewart Bryant
- Re: [mpls] LDP Security Eric Rescorla
- Re: [mpls] LDP Security Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [mpls] [tcpm] LDP Security Joe Touch
- Re: [mpls] [tcpm] LDP Security Jeff Tantsura
- Re: [mpls] LDP Security Susan Hares
- Re: [mpls] LDP Security t.petch
- Re: [mpls] [tcpm] LDP Security Joe Touch
- Re: [mpls] LDP Security Susan Hares
- Re: [mpls] [tcpm] LDP Security Susan Hares
- Re: [mpls] [tcpm] LDP Security Ignas Bagdonas
- Re: [mpls] [tcpm] LDP Security Joe Touch