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

[Alissa Cooper <[e-mail]>]

Hi Sean,

> On Feb 12, 2019, at 9:25 PM, Sean Turner <[e-mail]> wrote:
> 
> 
> 
>> On Jan 23, 2019, at 14:52, Alissa Cooper <[e-mail]> 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
>