Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)

Dhruv Dhody <dhruv.dhody@huawei.com> Fri, 12 July 2019 05:21 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C0C12011B; Thu, 11 Jul 2019 22:21:19 -0700 (PDT)
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 Q0lJzFfR5rVu; Thu, 11 Jul 2019 22:21:18 -0700 (PDT)
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 0688A120077; Thu, 11 Jul 2019 22:21:18 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1C3125F689B4028B9086; Fri, 12 Jul 2019 06:21:16 +0100 (IST)
Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 12 Jul 2019 06:21:15 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.50]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 10:51:07 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>, "draft-ietf-pce-association-group@ietf.org" <draft-ietf-pce-association-group@ietf.org>
Thread-Topic: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)
Thread-Index: AQHVN7vDP2UCLdb6vUWsgqzU5XStAabFMoewgABqFACAANJ18A==
Date: Fri, 12 Jul 2019 05:21:06 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8DB1ABDB@BLREML503-MBX.china.huawei.com>
References: <156283069004.32356.1196331021996927206.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8DB1A500@BLREML503-MBX.china.huawei.com> <20190711220105.GB16418@kduck.mit.edu>
In-Reply-To: <20190711220105.GB16418@kduck.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.149.39]
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/pce/j-2OxYzXc7dnENeuxYRjVqzX_50>
Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 05:21:20 -0000

Hi Ben, 

> > >    If a PCE peer is unwilling or unable to process the ASSOCIATION
> > >    object, it MUST return a PCErr message with the Error-Type "Not
> > >    supported object" and follow the relevant procedures described in
> > >    [RFC5440].  [...]
> > >
> > > Does this imply that the P flag in the common header should always
> > > be set for ASSOCIATION objects?
> > >
> > [[Dhruv Dhody]] No, that was not the intention. I have made this
> > change -
> >
> >    If a PCEP speaker does not recognize the ASSOCIATION object in the
> >    stateful message, it will return a PCErr message with Error-Type
> >    "Unknown Object" as described in [RFC5440].  In case of PCReq
> >    message, the PCE would react based on the P flag as per [RFC5440].
> >
> >    If a PCE peer is unwilling or unable to process the ASSOCIATION
> >    object in the stateful message, it MUST return a PCErr message with
> >    the Error-Type "Not supported object" and follow the relevant
> >    procedures described in [RFC5440].  In case of PCReq message, the PCE
> >    would react based on the P flag as per [RFC5440].
> 
> I think I may have just confused myself previously; feel free to rever
> this change if you don't think it's helpful.
> 

[[Dhruv Dhody]] The extra text for PCReq doesn't hurt. So I would let the update stay. 

> > > Section 8
> > >
> > >    attack vector.  An attacker could report too many associations in
> an
> > >    attempt to load the PCEP peer.  The PCEP peer responds with PCErr
> > > as
> > >
> > > "report" in the sense of causing the peer to create state to track
> them?
> > >
> > [[Dhruv Dhody]] Yes, basically to overwhelm the peer.
> 
> Okay. I might suggest "attempt to create" instead of "report", but I
> recognize that there are reasons to use "report" in the context of PCRpt.
> 
[[Dhruv Dhody]] Ack. 

Working Copy: https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-10.txt
Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-association-group-09&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-10.txt

Thanks for your detailed reviews. 

Dhruv

> Thanks for all the updates!
> 
> -Ben
>