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

Sean Turner <> Wed, 13 February 2019 02:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17C5F130EE7 for <>; Tue, 12 Feb 2019 18:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kYo_9joiOrKy for <>; Tue, 12 Feb 2019 18:25:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BE40130F00 for <>; Tue, 12 Feb 2019 18:25:54 -0800 (PST)
Received: by with SMTP id p25so659603qtb.3 for <>; Tue, 12 Feb 2019 18:25:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZN2UK7freEl7awJgLpWrsqpY0rRji0NcehE0VWiwtAc=; b=YhKOZop2hEbSR6U5QPQhAcpwUNmSXRPc/cPvcXCcS9CkfHdqCB5eCIejaoq5YCEn4O 8NmDpb6ThlRdzNeNuMfdyDu2OFuyMxQVhRnU9SuAWvDYEw3sAd4KhEgtQeaj7ybFpkjJ UVd6Y/xFjgjScPbC2aM4DzXGs1Oa0E3feaCBM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZN2UK7freEl7awJgLpWrsqpY0rRji0NcehE0VWiwtAc=; b=e+xusgrn7fO+OsiZ84173EkL9xg301KJQ5dSebhAECiJfpxCly7k6UTys8XmsrnAq6 Ug6yZlNmtf0CwX/cdf9cxFl9tnP4R1+/u7Ufr+heVQ6aLiBhN/3kbtXQGJBmydHE2mWc MgrY4zcO2qplxX6rJaMIiCUzGEM8dxzpryNcM+rA9Bga2ApXqEFlHubCrHbTaAH+Xum7 fjmEi2GmbBZr3sN627vWEsx3sPX/e9p+rzeJOs0I6v1iZbtheGRR4zRDAJc3sedU6iQp BetWe3Xoe2xfMzx+D0rztxh35Rzd8l6rSr7vKCN0IV8tjDl+F9r7kyYngmRmYWLsNyxl wo0Q==
X-Gm-Message-State: AHQUAuZ2j2+iiuZgM5Bg/Y6tVat8OfRlTpsKONi5s4rZaAehIkAx1ML3 u3maupgtBIDmPW1BVs6X/s8Db3iMI3Y=
X-Google-Smtp-Source: AHgI3IYqQkSjj/TDQIIh0HN6Yr0+eBpqBajGstyeKW2lA18KL3pSTw5HpJ6eSC6JlqnVwCl2Imn2bg==
X-Received: by 2002:a0c:92ec:: with SMTP id c41mr5174617qvc.158.1550024752983; Tue, 12 Feb 2019 18:25:52 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id b22sm8339880qtc.23.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:25:52 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Sean Turner <>
In-Reply-To: <>
Date: Tue, 12 Feb 2019 21:25:51 -0500
Cc: The IESG <>,, Chris Morrow <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Alissa Cooper <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [Sidrops] Alissa Cooper's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Feb 2019 02:25:59 -0000

> On Jan 23, 2019, at 14:52, Alissa Cooper <> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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

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.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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/