Re: [Sidrops] Alissa Cooper's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Fri, 22 February 2019 16:21 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F90130F73; Fri, 22 Feb 2019 08:21:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_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=cooperw.in header.b=gkcKQGJ3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=8BkWjFrE
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 aiuLtr2SU_wS; Fri, 22 Feb 2019 08:21:09 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AA3130F06; Fri, 22 Feb 2019 08:21:09 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 62D0023A30; Fri, 22 Feb 2019 11:21:08 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 22 Feb 2019 11:21:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=e Wf9Hk9oMUDKr/vFRjGdvzY164CpJ1AnOHFJ2tpvqkA=; b=gkcKQGJ3+yn6zWkZg hoPepB4UJQRSViQq0GYeYks7ezN8X42TlUtapTYK5Er3SkiI5PQhvHdAcwuE8scF wN4mdsClMqXzPBquteU0Ffu3LVwk5ae+bRssUKNBm9wsAbsuvNu/Yq0Dg2ZAgb5C X27TPvc+fA67Z/rghkM63iA3+p7w2wtExr87z2eFpo40e+QlmMDFLyyDECjSFSor tgiTsHKI3BzCIVuhX9/YHl8qIJBcKC4kaCTm77Rx+b38+MnCGKVeuFB3Qd51nrKa AK/cB7xyUELFvL8Y4V8UKs6dzs60PwGldc3Ik5MHlWF5KLU89Vs5sHzoOfxz2lnp Zc/sQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=eWf9Hk9oMUDKr/vFRjGdvzY164CpJ1AnOHFJ2tpvq kA=; b=8BkWjFrEdJ5Ta8F0YaprPd5zCTCdsDtpSEIw+z+VZobZQ1lBWxhr5xibk kQNfQL4VHr2J4DcDKdqKrNhZSb6HIphURtXHNKDXUmKOANyeL8EmxxOr7v0ytzIC 5eNwJPl2ucyu+O+/6Hv+D+W837g46Ef+diVrN09wvzKfHNLx1UCUBXPlbiMb8byD luM6tmM41fmkWegN6ON6crsLC2Kt9hFv0pGZ8/clPg214mSWpYKjrzzV3GMvZq6a ojt6azlldfFWH/sLKBSl4TiqLrWf23TFKMPIz1JTFEpUindiJtUX/+BjPNmemvAY x1p393fuGc94a5q+1hfUrOVQGPQlA==
X-ME-Sender: <xms:cyFwXLwWpAFY4_q58wQRCU0s2bDS01K_vpn5Mc3s-nSmeSn0mmF4HA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddruddtgdekleculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrieejnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy: <xmx:cyFwXPE1YcnUEY8Xlp0bv3H4L507V3u80tGmWRvCvU1bliF1ndc-QQ> <xmx:cyFwXLyhbejDCK5SNxeV4GMmGmAg0iMl1yPqIdjlEhrn-eJGIwkiWQ> <xmx:cyFwXCPKdysTv5p-QPYhuu70q0Vn9Ecz5U8VD3Ohte_yc6HvGDimEg> <xmx:dCFwXN07T0S5A6qwywD-XWneCBCYIkby27BqNVZh3I-AdLgWQO31Ag>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.67]) by mail.messagingengine.com (Postfix) with ESMTPA id D3A83E4210; Fri, 22 Feb 2019 11:21:06 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <9AAC1676-E54A-4049-8AC7-BFC257E4A692@sn3rd.com>
Date: Fri, 22 Feb 2019 11:21:05 -0500
Cc: The IESG <iesg@ietf.org>, draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <15766BFC-B054-4748-B4D8-45C6EC15F521@cooperw.in>
References: <154827316130.7453.12140820828793016275.idtracker@ietfa.amsl.com> <9AAC1676-E54A-4049-8AC7-BFC257E4A692@sn3rd.com>
To: Sean Turner <sean@sn3rd.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/I2S-orTF2CMm0DxUccddSQ46Zfk>
Subject: Re: [Sidrops] Alissa Cooper's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2019 16:21:14 -0000

Hi Sean,

> On Feb 12, 2019, at 9:25 PM, Sean Turner <sean@sn3rd.com> wrote:
> 
> 
> 
>> On Jan 23, 2019, at 14:52, Alissa Cooper <alissa@cooperw.in> wrote:
>> 
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-sidrops-rtr-keying-03: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> As this is a BCP, I don't understand why transport encryption of the private
>> key is not normatively required. Could you explain?
> 
> I guess there are a couple of issues here:
> 
> 1. deployment - I think there are two cases we need to consider: a) router is plugged into rack and managed over the LAN via the networked administration interface (i.e., RJ45), but there are also times when the operator sits down with box that’s not network connected and jacks into the router via the “craft port”.  The former case sure, you’d want to mandate it, but in the later is it a MUST?
> 
> 2. Object level security (which I think BenC also commented on): I would love to have object security, but the key needed to decrypt the encrypted needs to get onto the router before the encrypted key does.  We could do something PBE-based maybe or rely on the manufacturers having burned some key into the box that we can use.  Unfortunately, this bootstrapping problem isn’t new and not solved well - we didn’t attempt to do it here.
> 
> 2. Transport encryption (which I think ekr also commented on as being underspecified): The draft does include the following:
> 
>  Operators are free to use either the router-driven or operator-driven
>  method as supported by the platform.  Regardless of the method
>  chosen, operators first establish a protected channel between the
>  management system and the router.  How this protected channel is
>  established is router-specific and is beyond scope of this document.
> Though other configuration mechanisms might be used, e.g.  NetConf
>  (see [RFC6470]), the protected channel between the
>  management platform and the router is assumed to be an SSH-protected
>  CLI.  See Appendix A for security considerations for this protected
>  channel.
> 
> So transport security is required unless you got a really good reason not to do it - like maybe you’re plugged directly into the router and the router’s just being brought to life.  Since both you and ekr had the same kind of DISCUSS I will try to address it in that thread.  Maybe it’s as easy as explaining the two cases and providing requirements for the networked protocol.

I think such an explanation would suffice for me. My naive reading of this assumed that “transit” and “transport” imply a connection between two nodes that aren’t necessarily under the control of the same human at the time of the transfer, and a network-connected router.

Thanks,
Alissa

> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Given that this document is ostensibly specifying a "best" current practice, I
>> would have expected a clearer expression of preference for the router-driven
>> method over the operator-driven method, e.g., something like BGPsec-speaking
>> routers MUST implement the router-driven method and MAY implement the
>> operator-driven method. Or if there is some exception case that makes that MUST
>> problematic, it would at least be good to emphasize which one of these is
>> actually "best" from a security perspective, even though the other one is being
>> specified and we know will be used.
> 
> The way I was looking at “best" is that there are a set of routers that do what they do; some do operator-driven and some do router-driven (and some support advanced deployment scenarios).  Further, these routers are probably already out in the field and getting BGPsec bolted on so what operations the router supports it supports.  And, it wasn't clear to me that picking one over the really made sense.
> 
>> Nit in Section 1:
>> 
>> s/gritty details/details of the BGPsec protocol/
> 
> fixed
> 
> spt
>