Return-Path: 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 25C9C12D18D; Thu, 30 Jun 2016 10:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RICZz3xaKuy7; Thu, 30 Jun 2016 10:10:36 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 0AA9312B053; Thu, 30 Jun 2016 10:10:36 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id u201so74418324oie.0; Thu, 30 Jun 2016 10:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Ow2NgO0BBnzZfgwJjbwQPTN+jjR+6Jx3+NfCHXpbsg=; b=kdnsRU/UvC1ywxts8kpQQjss/kWKpWlsQNjP86mVlMC25c0NJNVRLAu7vBRCFamaX3 mVFTUdqNBO6TAecupv6vGppgsn5LVI7v4JJOxrlQXlKWlTcW/lr7uIKAQkRqiBXhgqz1 CSHKN77A8Y5F5SdCHVxrm7vxQJsJmLBwokZ3ElL+8Tp95y+O8NwYunpeDpYcK64vw+w5 wtA//9KRuMxPidDDCuYtc3Li7CAEh5CIfzAPqnfFbhmIrcbh0ThC1fTvf1UCCd8T/tYo CNtYuiTttu1ZNVkkZQGp7Qzg1hKRg6ggnFN8ZTITkGXzZ8oc4uNzbhanQFTC6TG9HUzO VeqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Ow2NgO0BBnzZfgwJjbwQPTN+jjR+6Jx3+NfCHXpbsg=; b=Ddy32AFnTRL9cV/Kz0ffwBCVBh3Y8O/T5CIvmdyUXep0AEoBILphE3GpGXmjx1clTI qkiOTRhBWhCFqtbHd6/Ld8lEn9aMmrFKnBGtld6cMVMuYYqTgkByZhBbBAS09DvAZ9U8 ABxVFM/vgfD3RbmoeaTxE+EyPoyEAKjUeMzm/CqZld2Gw2ifkyPYA7JmhldaQSau+KI6 322P9ha4bfw/Tv2WcrwiqMlXlmgIlURmFnJkAAxH2F06cA8Fxpv+sWKbfMIywZlYSHOY ufY6DN/8WOmZVNvetfgjXZamzAls1ILzCb4LwK6evbSI/IS/d90zc9YAGO9bl7e30dQi EOIw== X-Gm-Message-State: ALyK8tLWoelOynNmfpJ2hMvRZOqqxjrnSCDUTrT9qcHiGCQTmLeYPgXLl2UHt8s4XXCHtD1T1Xr4jYdHHjMWsQ== X-Received: by 10.157.23.232 with SMTP id j95mr9873395otj.109.1467306635365; Thu, 30 Jun 2016 10:10:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.43.6 with HTTP; Thu, 30 Jun 2016 10:10:15 -0700 (PDT) In-Reply-To: References: <029601d1d259$9d2a1c40$d77e54c0$@huitema.net> <05cc01d1d28a$a472ecd0$ed58c670$@huitema.net> From: "Andrew G. Malis" Date: Thu, 30 Jun 2016 13:10:15 -0400 Message-ID: To: Mach Chen Content-Type: multipart/alternative; boundary=94eb2c09ae1ac71d25053681f25f Archived-At: Cc: "BRUNGARD, DEBORAH A \(ATTLABS\)" , "iesg@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 17:10:38 -0000 --94eb2c09ae1ac71d25053681f25f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mach, You should wait for Deborah=E2=80=99s go-ahead before doing an update, I th= ink 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 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] > > Sent: Thursday, June 30, 2016 12:48 PM > > To: Mach Chen; iesg@ietf.org; secdir@ietf.org; > > 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] > > > > Sent: Thursday, June 30, 2016 6:57 AM > > > > To: iesg@ietf.org; secdir@ietf.org; > > > > 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 lik= e > > > > 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 avoi= d > > > > asymmetric routing. The document specifies additional LDP extension= s > > > > 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 sufficie= nt > --94eb2c09ae1ac71d25053681f25f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mach,

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

Thanks,
Andy


On Thu, Jun 30, 2016 at 2:04 AM, Mach Ch= en <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]
> Sent: Thursday, June 30= , 2016 12:48 PM
> To: Mach Chen; iesg@ietf.org; secdir@ietf.org;
> 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-ls= p-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]
> > > Sent: Thursday, June 30, 2016 6:57 AM
> > > To: iesg@ietf.org; secdir@ietf.org;
> > > 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 direct= orate's
> ongoing
> > > effort to review all IETF documents being processed by the I= ESG.
> > > These comments were written primarily for the benefit of the=
> > > security area
> > directors.
> > > Document editors and WG chairs should treat these comments j= ust like
> > > any other last call comments.
> > >
> > > The document is ready with 2 nits.
> > >
> > > The document specifies an extension to the Label Distributio= n
> > > Protocol
> (LDP,
> > > RFC 5036) to provide bindings between Pseudo Wires (PW) and = Label
> > > Switch Paths (LSP) established over MPLS-TP (RFC6773). The g= oal is
> > > to ensure
> that
> > > both directions of the PW are mapped to the same LSP, and th= us avoid
> > > asymmetric routing. The document specifies additional LDP ex= tensions
> > > to
> > carry
> > > the required information.
> > >
> > > The security section acknowledges one concern: that attacker= s 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. Th= e
> > > proposed
> > mitigation to
> > > that attack is essentially "careful Implementation"= ;, i.e. only
> > > accept
> binding
> > > requests where the LSP endpoints match the PW endpoints. Sho= uld a
> > mismatch
> > > occur, I assume that the endpoint will reject the proposed b= inding,
> > > as
> > specified
> > > in section 5, PSN Binding Operation for MS-PW.
> > >
> > > And here is one nit: I would like to see the verification be= havior
> specified as
> > part
> > > of the binding operations, rather than merely mentioned in t= he
> > > security
> > section.
> >
> > OK, how about adding the following text?
> >
> > For SS-PW:
> > "In addition, if the received PSN tunnel/LSP end points do n= ot match
> > the
> PW
> > end points, PE2 MUST reply with a Label Release message with stat= us
> > 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 n= ot match
> > the
> PW
> > Segment end points, the receiving PE MUST reply with a Label Rele= ase
> > 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 failur= e, or
> > > just
> the generic
> > > error message?
> >
> > Since this is a potential attack, seems it is safer not to delive= r
> > more
> specific
> > reason to the attacker. I think the generic error message is suff= icient

--94eb2c09ae1ac71d25053681f25f--