Re: [mpls] [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05

Mach Chen <mach.chen@huawei.com> Mon, 18 February 2019 10:11 UTC

Return-Path: <mach.chen@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 A8B23130EEF; Mon, 18 Feb 2019 02:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 Wrqx0-ZKzI1m; Mon, 18 Feb 2019 02:11:38 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2734A130EEC; Mon, 18 Feb 2019 02:11:38 -0800 (PST)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5B44719CC5C6C19F10FE; Mon, 18 Feb 2019 10:11:36 +0000 (GMT)
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Feb 2019 10:11:35 +0000
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Mon, 18 Feb 2019 18:11:24 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Linda Dunbar <linda.dunbar@huawei.com>, "secdir@ietf.org" <secdir@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" <draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05
Thread-Index: AQHUkY+Xr7eIQ7lWe0az4uRG6fBCdqV9d+SwgERX9oCAHShNQIADyugAgALw4PA=
Date: Mon, 18 Feb 2019 10:11:24 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE29288DC3E@dggeml510-mbx.china.huawei.com>
References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2927B2883@dggeml510-mbx.china.huawei.com> <20190126211729.GJ49072@kduck.mit.edu> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE292889888@dggeml510-mbx.china.huawei.com> <20190216202815.GD82217@kduck.mit.edu>
In-Reply-To: <20190216202815.GD82217@kduck.mit.edu>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.194.201]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/5lbYj1ULA0NB_gXGERlkE_AJORY>
Subject: Re: [mpls] [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 18 Feb 2019 10:11:41 -0000

Hi Benjamin,

> -----Original Message-----
> From: Benjamin Kaduk [mailto:kaduk@mit.edu]
> Sent: Sunday, February 17, 2019 4:28 AM
> To: Mach Chen <mach.chen@huawei.com>
> Cc: Linda Dunbar <linda.dunbar@huawei.com>om>; secdir@ietf.org;
> mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org;
> ietf@ietf.org
> Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-
> multipath-05
> 
> Hi Mach,
> 
> My apologies as well for the delay.
> 
> On Thu, Feb 14, 2019 at 03:02:07AM +0000, Mach Chen wrote:
> > Hi Benjamin,
> >
> > Sorry for the delayed response!
> >
> > Please see my response inline...
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk [mailto:kaduk@mit.edu]
> > > Sent: Sunday, January 27, 2019 5:17 AM
> > > To: Mach Chen <mach.chen@huawei.com>
> > > Cc: Linda Dunbar <linda.dunbar@huawei.com>om>; secdir@ietf.org;
> > > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org;
> > > ietf@ietf.org
> > > Subject: Re: [secdir] Secdir last call review of
> > > draft-ietf-mpls-lsp-ping-lag-
> > > multipath-05
> > >
> > > On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote:
> > > > Hi Linda,
> > > >
> > > > Thanks for the review!
> > > >
> > > > Some responses inline...
> > > >
> > > > > -----Original Message-----
> > > > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Linda
> > > > > Dunbar
> > > > > Sent: Wednesday, December 12, 2018 4:24 AM
> > > > > To: secdir@ietf.org
> > > > > Cc: mpls@ietf.org;
> > > > > draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org;
> > > > > ietf@ietf.org
> > > > > Subject: Secdir last call review of
> > > > > draft-ietf-mpls-lsp-ping-lag-multipath-05
> > > > >
> > > > > Reviewer: Linda Dunbar
> > > > > Review result: Ready
> > > > >
> > > > > I have reviewed this document as part of the security
> > > > > directorate's ongoing effort to review all IETF documents being
> > > > > processed by the IESG.  These comments were written primarily
> > > > > for the benefit of the security area directors.  Document
> > > > > editors and WG chairs should treat these comments just like any
> other last call comments.
> > > > >
> > > > > The summary of the review is Ready with comment
> > > > >
> > > > > The described mechanism for LSP Multipath Ping is very clear.
> > > > > The Security Consideration re-uses the description of RFC8029,
> > > > > which is very comprehensive.
> > > > > It would be better if the draft describes how to prevent
> > > > > intermediate LSRs in between the Initiating LSR and Responding
> > > > > LSR from mis-using the detailed link information (e.g.
> > > > > forwarding to
> > > somewhere else).
> > > >
> > > > The Echo Request and Reply messages are directly exchanged between
> > > > the
> > > Initiating LSR and the Responding LSR, those intermediate LSRs just
> > > forward the messages as normal packets, they will not see the
> > > detailed link information unless if they inspect and do DPI on every
> > > packet forwarded by them.
> > > >
> > > > The detailed link information is supplied to the Initiating LSR
> > > > for using, the
> > > intermediate LSRs will not try to use it even if they received the
> > > information, because there is no corresponding Echo Request to the
> received Echo Reply.
> > >
> > > The intermediate LSRs still will have access to the plaintext
> > > information, even if in normal operation they do not need to act upon
> that information.
> > > Generally in this sort of situation we will either explicitly state
> > > that the intermediate nodes must be trusted to not abuse the
> > > information in question, or provide some mechanism for end-to-end
> > > confidentiality protection.
> >
> > "Intermediate nodes must be trusted to not abuse the information" is
> normally assumed. For the intermediate nodes, there is no different
> between the Echo Reply messages and any other data traffic, control
> messages. They just forward the Echo Reply messages as normal packets.  I
> am not sure it needs to explicitly state this.  Do you suggest to add such a
> statement in the security consideration section?
> 
> The concern is not about the normal operation, but rather about abnormal
> operation, e.g., if an intermediate node gets compromised by an attacker.
> We need to document the new abilities an attacker gets, when comparing
> the original case of "an attacker compromises an intermediate node that is
> using MPLS without this mechanism" to the new case of "an attacker
> compromises an intermediate node that is using MPLS with this mechanism".
> So, while I do suggest adding a statement to the security considerations
> section, the statement I want does not relate to the normal operation case
> (when intermediate nodes ignore the contents of the message).

OK, will add such a statement in the security considerations section. 

> 
> > >
> > > Also (noting that I only skimmed the document so this may not make
> > > sense), the security considerations seem to suggest using an IP ACL
> > > for determining which messages are trusted; IP ACLs are generally
> > > not recommended in favor of cryptographic mechanisms at this point.
> >
> > IP ACLs was introduced in RFC 8029 and is reused in this document,
> > it's
> 
> I did not find a clear and explicit declaration in RFC 8029 of the concept of an
> IP ACL; I assume you are referring to:
> 
>    To protect against unauthorized sources using MPLS echo request
>    messages to obtain network information, it is RECOMMENDED that
>    implementations provide a means of checking the source addresses of
>    MPLS echo request messages against an access list before accepting
>    the message.

Yes, this is that I am referring to.

> 
> I do not think anyone is going to say "do not filter based on IP source
> address", but there would be general skepticism about relying upon it as a
> sole security mechanism.
> 
> > just one of the security mechanisms. This document is an extension to
> 
> (Could you remind me of the other mechanisms?  I don't think I have a good
> handle on them.)

You are right, for protecting against unauthorized sources, IP ACL is the only way proposed in RFC 8029 and this document. 

> 
> > RFC 8029, as stated in this document, all security considerations
> > defined in RFC 8029 apply to this document. Do you have any specific
> > suggestion to the current security consideration?
> 
> I am mostly just lamenting the state of affairs; this is a sufficiently
> incremental change that it is inappropriate to require dramatic changes in the
> security mechanisms.

I agree with you. Does it mean that you are OK with the current security considerations, given that a statement regarding the intermediate node's process will be added.

Best regards,
Mach

> 
> -Ben