Re: [secdir] SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08

Mach Chen <mach.chen@huawei.com> Fri, 01 July 2016 00:48 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755B212D0B1; Thu, 30 Jun 2016 17:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.646
X-Spam-Level:
X-Spam-Status: No, score=-5.646 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, RP_MATCHES_RCVD=-1.426, 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 tpxGp3YTmX3Y; Thu, 30 Jun 2016 17:48:39 -0700 (PDT)
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 BD4D912D0B3; Thu, 30 Jun 2016 17:48:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRV89984; Fri, 01 Jul 2016 00:48:34 +0000 (GMT)
Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 1 Jul 2016 01:48:32 +0100
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Fri, 1 Jul 2016 08:48:27 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
Thread-Topic: SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
Thread-Index: AdHSVHw3wGPy2LWlRRa/K3WxEmXT2AAHEg9Q//+tnwD//2V7AIABacqA//76gQA=
Date: Fri, 1 Jul 2016 00:48:26 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC891F3@SZXEMA510-MBX.china.huawei.com>
References: <029601d1d259$9d2a1c40$d77e54c0$@huitema.net> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC88BD9@SZXEMA510-MBX.china.huawei.com> <05cc01d1d28a$a472ecd0$ed58c670$@huitema.net> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC88CD9@SZXEMA510-MBX.china.huawei.com> <CAA=duU3L5eJgbvayZ1fviXPS5iMjFXa1LqBaUPW_ghECn6FQZg@mail.gmail.com>
In-Reply-To: <CAA=duU3L5eJgbvayZ1fviXPS5iMjFXa1LqBaUPW_ghECn6FQZg@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.102.135]
Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC891F3SZXEMA510MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5775BDE3.0068, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: bc01f132eebbc0ed6d970ef9afe87297
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/EIWwjdwDG6edyHmu0R7BosdMKiQ>
Cc: "BRUNGARD, DEBORAH A \(ATTLABS\)" <db3546@att.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@ietf.org" <draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2016 00:48:42 -0000

Hi Andy,

Thanks for your guidance!

Yes, that’s the plan.

Best regards,
Mach

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Friday, July 01, 2016 1:10 AM
To: Mach Chen
Cc: Christian Huitema; iesg@ietf.org; secdir@ietf.org; draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@ietf.org; BRUNGARD, DEBORAH A (ATTLABS)
Subject: Re: SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08

Mach,

You should wait for Deborah’s go-ahead before doing an update, I think that she'll prefer that the update occur following the end of IETF last call.

Thanks,
Andy


On Thu, Jun 30, 2016 at 2:04 AM, Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>> wrote:
Hi Christian,

Thanks for your prompt response!

We will update the draft as agreed.

Best regards,
Mach

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@huitema.net<mailto:huitema@huitema.net>]
> Sent: Thursday, June 30, 2016 12:48 PM
> To: Mach Chen; iesg@ietf.org<mailto:iesg@ietf.org>; secdir@ietf.org<mailto:secdir@ietf.org>;
> draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@ietf.org<mailto:draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@ietf.org>
> Subject: RE: SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
>
> On Wednesday, June 29, 2016 7:39 PM, Mach Chen wrote:
> >
> > Hi Christian,
> >
> > Thanks for your review and comments!
>
> You are welcome.
>
> > Please see my replies inline...
> >
> > > -----Original Message-----
> > > From: Christian Huitema [mailto:huitema@huitema.net<mailto:huitema@huitema.net>]
> > > Sent: Thursday, June 30, 2016 6:57 AM
> > > To: iesg@ietf.org<mailto:iesg@ietf.org>; secdir@ietf.org<mailto:secdir@ietf.org>;
> > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@ietf.org<mailto:draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@ietf.org>
> > > Subject: SECDIR review of
> > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
> > >
> > > 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 document is ready with 2 nits.
> > >
> > > The document specifies an extension to the Label Distribution
> > > Protocol
> (LDP,
> > > RFC 5036) to provide bindings between Pseudo Wires (PW) and Label
> > > Switch Paths (LSP) established over MPLS-TP (RFC6773). The goal is
> > > to ensure
> that
> > > both directions of the PW are mapped to the same LSP, and thus avoid
> > > asymmetric routing. The document specifies additional LDP extensions
> > > to
> > carry
> > > the required information.
> > >
> > > The security section acknowledges one concern: that attackers could
> misuse
> > > the option to force a pseudo wire through an unnatural path, either
> > > as a
> > denial
> > > of service attack, or to facilitate traffic interception. The
> > > proposed
> > mitigation to
> > > that attack is essentially "careful Implementation", i.e. only
> > > accept
> binding
> > > requests where the LSP endpoints match the PW endpoints. Should a
> > mismatch
> > > occur, I assume that the endpoint will reject the proposed binding,
> > > as
> > specified
> > > in section 5, PSN Binding Operation for MS-PW.
> > >
> > > And here is one nit: I would like to see the verification behavior
> specified as
> > part
> > > of the binding operations, rather than merely mentioned in the
> > > security
> > section.
> >
> > OK, how about adding the following text?
> >
> > For SS-PW:
> > "In addition, if the received PSN tunnel/LSP end points do not match
> > the
> PW
> > end points, PE2 MUST reply with a Label Release message with status
> > code
> set
> > to "Reject - unable to use the suggested tunnel/LSPs" (TBD4) and the
> received
> > PSN Tunnel Binding TLV MUST also be carried."
>
> Yes.
>
> > For MS-PW:
> > "In addition, if the received PSN tunnel/LSP end points do not match
> > the
> PW
> > Segment end points, the receiving PE MUST reply with a Label Release
> > message with status code set to "Reject - unable to use the suggested
> > tunnel/LSPs" (TBD4) and the received PSN Tunnel Binding TLV MUST also
> > be carried."
>
> Yes, that works.
>
> > > Also, is there a specific error case for the security failure, or
> > > just
> the generic
> > > error message?
> >
> > Since this is a potential attack, seems it is safer not to deliver
> > more
> specific
> > reason to the attacker. I think the generic error message is sufficient