Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 12 February 2019 01:02 UTC

Return-Path: <kaduk@mit.edu>
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 9C7BD1276D0; Mon, 11 Feb 2019 17:02:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 GmCu34Jf_LyF; Mon, 11 Feb 2019 17:02:55 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790101.outbound.protection.outlook.com [40.107.79.101]) (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 A5ECC1311F4; Mon, 11 Feb 2019 17:02:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UQqHRtoqCz129JGUI0ogb0613nddN1XXau/Su4vas2o=; b=fq2ixwwYOzpFxQfuWcHXYo0SBNP/2O1ZEgOA81vID3Qx52O0IwMXYqSA5Tlxa/2k4yUG6KjbP7BtAGfomhnnhLYcoOvAPc87mzj9H9DHm7iObx/97wR2+TSAHGxCLbZAseeslHU7gilyhD20yhHstjPn+teww5kURiC9yuzsJJM=
Received: from DM5PR0102CA0008.prod.exchangelabs.com (2603:10b6:4:9c::21) by SN6PR01MB4496.prod.exchangelabs.com (2603:10b6:805:e1::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Tue, 12 Feb 2019 01:02:53 +0000
Received: from CO1NAM03FT021.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::208) by DM5PR0102CA0008.outlook.office365.com (2603:10b6:4:9c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16 via Frontend Transport; Tue, 12 Feb 2019 01:02:53 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT021.mail.protection.outlook.com (10.152.80.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Tue, 12 Feb 2019 01:02:52 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1C12mO5020731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Feb 2019 20:02:50 -0500
Date: Mon, 11 Feb 2019 19:02:48 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-pce-segment-routing@ietf.org" <draft-ietf-pce-segment-routing@ietf.org>, Dhruv Dhody <dhruv.ietf@gmail.com>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Message-ID: <20190212010248.GQ56447@kduck.mit.edu>
References: <154362042021.27428.14843328031369141534.idtracker@ietfa.amsl.com> <BL0PR02MB4868D21341B671EEB1E34E7084B80@BL0PR02MB4868.namprd02.prod.outlook.com> <20190106003943.GF28515@kduck.kaduk.org> <BL0PR02MB4868A466BC15948F809E209784640@BL0PR02MB4868.namprd02.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BL0PR02MB4868A466BC15948F809E209784640@BL0PR02MB4868.namprd02.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(396003)(39860400002)(2980300002)(52314003)(189003)(37854004)(199004)(86362001)(246002)(33656002)(561944003)(104016004)(55016002)(478600001)(1076003)(26826003)(2906002)(356004)(786003)(316002)(93886005)(88552002)(229853002)(46406003)(36906005)(58126008)(16586007)(6916009)(54906003)(106002)(76176011)(126002)(336012)(446003)(426003)(8936002)(14444005)(26005)(186003)(97756001)(6246003)(4326008)(956004)(8676002)(305945005)(23726003)(47776003)(486006)(53416004)(50466002)(476003)(75432002)(7696005)(106466001)(11346002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB4496; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT021; 1:rNu8Km/5eEbSeLahOxMj0X/vZiodJqXd+arbvS0aQ2EI+NsQ8Wq7UIeK3zj6ufPvA8FxASPLRubmgEMnaSaKnb0FYXxWbAEmzMh2UFc/prCFsg0oLyXJA+jtj81Icqnb12JVuIF99ymEIrWI/cbGyg==
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: f377b672-b75b-4e61-2943-08d69085d0ec
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:SN6PR01MB4496;
X-MS-TrafficTypeDiagnostic: SN6PR01MB4496:
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4496; 20:Cg+uYSaX7yUpDbAVHIT0DIilXMVwbbcOkFAKXSvLLE4lPZ1s+jB14Xkd+619oZ4VmnZ192Ev/BwrnC86TR3xH7AgdKzRrqk175IkmNkeqbS0PXuj0HsxOEgPnV/a/Io/WMAQasV3ysUvag+MhCDcOU+EHPL/v1Il/nJ15tzkssp9zlOdUiVkB5O/UEBA9DQPh3Bo/24m+6KDXn/4hZGo4CrIClm7IFmopDP7iVxXVfDbfxMaCDugPJRLNEGOCXdRurTHBCpjdxbCTtPx804t6YvTHbYk8X0Bq9OVBVKp6L/B5rLO73/J8F5EdemhzpPM3PENXp16hEgaYmeXM4898LHd02e785VlBQmZX0A2gt+YBp2qAOW3OwTvnDme0p48hlaY+NnUFpeBA6ShoY7JVKganDJMQ4eYvJ93Clk5gPcba5vjQiw5u5y72AIkUk4iGoqMqqMXdHO+/yYKHCfDxUZO+FkzntHze6bV7NLTNsHgLdW0JTFH+AnMU9oeyxRnfDX1e9+d639r8iMwZfeMVKLxTzVNvEtlStQws9hIrYDL7MnNDKHh/1Uk9WSnQVZvr8VyDYj0LoyZeVPhGT2rVIYsam0PI+OgaZw3njVVvF8=
X-Microsoft-Antispam-PRVS: <SN6PR01MB44967D1BE30A4BF8B7033CBDA0650@SN6PR01MB4496.prod.exchangelabs.com>
X-Forefront-PRVS: 0946DC87A1
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4496; 23:mR2uw+jzqDnxcCZoDBDdSZ78nhUMW8t31MZ39KLH2T8EoEClVD384FnvVALYeyljAd1HnVj9K9LNME7ru5cVxQU0MX1wN8AowBaA/Vmqhe70Vv85G+Vygx3XsZ+UOx09xPPHU5wHPijhiq4KXR/R+ZRaUvo6Z90fID4dbDPTBtVvDK+9XuWeClKxxAaXhuijcmPHYanuTMhBWYWUa/AB9G/SgDeT353OXUE/qqmnq1Sofv/plliabAAyFYQncnVAkZEbGRtf1nvuHBzzx1dguOuT46HYlIze6KiN497PwejeJOm2p/SgEwn7TnUUaC6bkcxQmQH30ByoumAg8oy4pso1CmlrZ8yUJioud5hI8OuXnwz4mTrbq6LmPU3pkDLZUUqmlgOwlWJcH9tC66m1jx0janY9FnTvm89CmHq9BwFWjD+x0EA6Yf1XZJcLEG8mcYrFP4dq7np/ciXWrsv+9qqWa66qIM2te2FerDQ0kAL6NZnVkufOSJNe+g5xPCtyMtumOi7CTxDIg7KIbAvON91QNY2kdKz70dIrhS9qvsbFGYtX8Ryfd3p6vBhwUqEz6ZtKS1UoNwnGAKSupKIzBQHSmGOI50PBzGBdsqd3PT9dvWXwuX7lh8tzDr3e4PVwVqoIia4S2ghU0E+qjz8e48b5yuEwHYdU0UUioB2bfIELLU7PUpoRp9Xe8Ki7lFkpeHWn38wBvZY6YoKTD4v2+maX9l0Yeo719JztN/p2ZK/KsGtB7MeoMU1Ab4XfBqXd9Wc/8CQUa7f7322dGkAtsSRrV9uYQ98b1Z6oHawTTkKvAfh/cT9M61sH9JsshUGXsRxoqg2wjDA4ooJVtDcxrIbeDstzSiI4NUkDDayCklQRHEBtfxinl6OmuiB69+DEu/i485boGnjdJMhs8/Na39bUteCArhAGXtWBugucj6Bk76KG/PqhDIFDr/3EcoZCYBFrgeO/erE97PFtBC6UB27+nyyu0Q0wetn3LMeu0aVOlaGJxpdhq+71jCtVUcyjKvVOC1wVlR05mLDucnaze/yiicjIS7R2jw1/hRiZRQyFHt5ADgjRHQ6pYOK7KQIPEWtQqJDxaQRPFJZTO89sBN9As3BsDrs/4jNRShAxHZdXF7v2/pv5jMPE2voUsC1o9Yr+vixqxGQCMcdm6AvuPw/lQFFGRBC99VnrK4MHUO6RNgDBHPt51DMo/ENCVUgjm6Psx750hxqKmxCOyd3bCn1OHPF426xfiMEvLTYtuHMoBZJNYWzhjxjgLLp/6evyDKShsmnaRFD/umKpTD7y1g==
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: GMgbEpyR6cFfbZyETOh9UjmNNMNjJcmB7CS5lBdQ8WgES9P2j1WcC2UNa+TkDXoX6DnaRORAmU0ALl3kcdHqkbaTFbYrO7C9u1hdxZlwxgBuu7g5O0poHs9JPEOUnE5cm760+aEvo7+SCDVGFba2w4nyrEQp0jn3XOa1FZqbufBPF7hUl3RS33sOlRUy9jodWtCkdicO5PmVUonhEj0l3i5Cukp2x4upZxXoX9Tpk24w7ntJaap0GuveEEHaY3yelC+1019apWaNXVit3YaQrKAxExvcZQ9c6giQQnaTnFyhIidqy1rWbhJr9yu4yGGNiXBe14jtaTmDZHDb3xPDxDKL5jNaTZxx7WHragbkSgZpDskAxHEuswShJP83YhkBx3pHhvVLwSjJzGHIXEmrsiTw/bwPLPvb3zJc3YtbGlw=
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2019 01:02:52.4707 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f377b672-b75b-4e61-2943-08d69085d0ec
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB4496
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/ukzVslAG15ggamva_T9LQABHLcg>
Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-segment-routing-14: (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: Tue, 12 Feb 2019 01:02:59 -0000

Hi Jon,

On Mon, Feb 11, 2019 at 06:57:55PM +0000, Jonathan Hardwick wrote:
> Hi Benjamin
> 
> As I was preparing the next revision of this document, I realised I'd forgotten to reply to your email.  (I thought I had replied, but I can find no evidence that I did so!)

I have been guilty of the same more times than I can count; what matters is
that we get the work done, really.

> Anyway, I think we have converged.  Please see my proposals below, and apologies for my tardiness.

Indeed we have converged.

> Cheers
> Jon
> 
> ----
> > Isn't the 'F' bit fully redundant with NT?
> > 
> > [Jon] The F bit determines whether NAI is appended, or not.  NT gives the type of the NAI that is appended.  The NT field has no meaning if F=0.
> 
> My (implicit) proposal was to assign a value for the NT field that means "no NAI is present", and to treat that value of NT as meaning that F=0, with any other value of NT meaning F=1, in which case the F bit does not add any new information.
> 
> [Jon2] Understood. Unfortunately, we have to make a pragmatic decision here as implementations are already fielded.  I have changed the text to say this to clarify.
> 
> NEW
>    NAI Type (NT):  Indicates the type and format of the NAI contained in
>       the object body, if any is present.  If the F bit is set to zero
>       (see below) then the NT field has no meaning and MUST be ignored
>       by the receiver.
> END NEW

Thanks.  (It is wholly unsurprising that making actual wire-level changes
here is to be avoided unless absolutely necessary, and this definitely does
not qualify as absolutely necessary.)

> ----
> > It's interesting that the routing protocols' MSD value supersedes the PCE-obtained one, given that all three (IS-IS, OSPF, and BGP-LS) documents have text to the effect of "PCEP provides a way to get this, but if PCEP is not used you can use our thing", which a naive reader would take to mean that PCEP is intended to be the primary distribution mechanism.
> > 
> > [Jon] Probably needs to be fixed in the other documents.  PCEP is a fairly blunt tool for specifying the MSD, which it can only do per node.  The IGPs can do better by specifying the MSD per network interface.
> 
> Ah.  Unfortunately, at least the IS-IS document is already published as an RFC (8491) and thus immutable.  (I didn't check the others.)  I don't know whether it would be appropriate to add this explanation into this document since the other documents cannot (all) be changed.
> 
> [Jon2] I've reworded the text to make the relationship between PCEP and the IGPs clearer:
> 
> NEW
>    Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV
>    indicates the SID/label imposition limit for the PCC node.  It is
>    anticipated that, in many deployments, the PCCs will have network
>    interfaces that are homogeneous with respect to MSD (that is, each
>    interface has the same MSD).  In such cases, having a per-node MSD on
>    the PCEP session is sufficient; the PCE SHOULD interpret this to mean
>    that all network interfaces on the PCC have the given MSD.  However,
>    the PCE MAY also learn a per-node MSD and a per-interface MSD from
>    the routing protocols, as specified in: [RFC8491]; [RFC8476];
>    [I-D.ietf-idr-bgp-ls-segment-routing-msd].  If the PCE learns the
>    per-node MSD of a PCC from a routing protocol, then it MUST ignore
>    the per-node MSD value in the SR-PCE-CAPABILITY sub-TLV and use the
>    per-node MSD learned from the routing protocol instead.  If the PCE
>    learns the MSD of a network interface on a PCC from a routing
>    protocol, then it MUST use the per-interface MSD instead of the MSD
>    value in the SR-PCE-CAPABILITY sub-TLV when it computes a path that
>    uses that interface.
> END NEW

That is very helpful, at least to me; thank you.

> 
> ----
> > I don't think it's a good idea to just refer to "the security 
> > mechanisms of [RFC 5440] and [RFC8281]", since there are qualitative 
> > differences between the TCP authentication schemes and the full-on 
> > encryption provided by TLS and IPsec.  (Also, what exactly are the 
> > security mechanisms of RFC8281 supposed to be -- a quick look only 
> > sees the new guidance to apply resource
> > limits?)  The second paragraph only requires integrity protection to avoid the vulnerability mentioned there, but the third paragraph requires confidentiality protection to preent the attack.
> > 
> > [Jon] RFC 8281 pulls in RFC 8231 in its security section, as you note 
> > above.  RFC 8231 says
> > 
> >    As a general precaution, it is RECOMMENDED that these PCEP extensions
> >    only be activated on authenticated and encrypted sessions across PCEs
> >    and PCCs belonging to the same administrative authority, using
> >    Transport Layer Security (TLS) [PCEPS], as per the recommendations
> >    and best current practices in [RFC7525].
> 
> That still doesn't seem to give the reader much guidance about which cases require encryption and which cases can safely proceed with just integrity protection (even though I'm happy to see the general recommendation to use TLS!).
> 
> [Jon2] OK, I understand. The strong steer is that TLS should be used all the time, but we haven't mandated it, so you are right, more guidance should be given.  I think your analysis is correct, so I've changed the text in the second and third paragraphs as follows.
> 
> NEW
>    Note that this specification enables a network controller to
>    instantiate a path in the network without the use of a hop-by-hop
>    signaling protocol (such as RSVP-TE).  This creates an additional
>    vulnerability if the security mechanisms of [RFC5440], [RFC8231] and
>    [RFC8281] are not used.  If there is no integrity protection on the
>    session, then an attacker could create a path which is not subjected
>    to the further verification checks that would be performed by the
>    signaling protocol.
> 
>    Note that this specification adds the MSD field to the OPEN message
>    (see Section 4.1.2) which discloses how many MPLS labels the sender
>    can push onto packets that it forwards into the network.  If the
>    security mechanisms of [RFC8231] and [RFC8281] are not used with
>    strong encryption, then an attacker could use this new field to gain
>    intelligence about the capabilities of the edge devices in the
>    network.
> END NEW

Thanks!

-Benjamin