Re: [mpls] LDP Security

Uma Chunduri <uma.chunduri@huawei.com> Wed, 08 November 2017 23:50 UTC

Return-Path: <uma.chunduri@huawei.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 541CD12778E; Wed, 8 Nov 2017 15:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AncWLaEE2lCO; Wed, 8 Nov 2017 15:50:35 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BF6127010; Wed, 8 Nov 2017 15:50:33 -0800 (PST)
Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZK78312; Wed, 08 Nov 2017 23:50:32 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 23:50:30 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 15:50:25 -0800
From: Uma Chunduri <uma.chunduri@huawei.com>
To: Eric Rescorla <ekr@rtfm.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>
Thread-Topic: [mpls] LDP Security
Thread-Index: AQHTWLbyOfMae53/m0ycVXrEQ0bS1aMLS2UA//+SrUCAAJ2kAP//pwtQ
Date: Wed, 08 Nov 2017 23:50:24 +0000
Message-ID: <25B4902B1192E84696414485F5726854135191D6@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> <CABcZeBO6msQuxGLtWp4HDQAGtubOp-33Gt+uip5P3y2-icnRqg@mail.gmail.com>
In-Reply-To: <CABcZeBO6msQuxGLtWp4HDQAGtubOp-33Gt+uip5P3y2-icnRqg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.246.168]
Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F5726854135191D6sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5A039848.00F5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 14d312b36b9605c70916f063eabc04c2
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/qWakqDatBJRUO4I0R01kBm1tmW8>
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: Wed, 08 Nov 2017 23:50:38 -0000

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<mailto: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<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<mailto:stewart.bryant@gmail.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; pals-chairs@tools.ietf.org<mailto:pals-chairs@tools.ietf.org>; <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>> <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; pals@ietf.org<mailto:pals@ietf.org>; <sec-ads@ietf.org<mailto:sec-ads@ietf.org>> <sec-ads@ietf.org<mailto: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.

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