Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01

[Dhruv Dhody <[e-mail]>]

Hi Sean, Randy,

Thanks for your patience and taking my comments into consideration.
See inline below -

On Tue, Dec 18, 2018 at 9:57 PM Sean Turner <[e-mail]> wrote:
>
> Hi!
>
> > On Dec 14, 2018, at 05:41, Dhruv Dhody <[e-mail]> wrote:
> >
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this
> > draft. The Routing Directorate seeks to review all routing or
> > routing-related drafts as they pass through IETF last call and IESG
> > review, and sometimes on special request. The purpose of the review is
> > to provide assistance to the Routing ADs. For more information about
> > the Routing Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >
> > Although these comments are primarily for the use of the Routing ADs,
> > it would be helpful if you could consider them along with any other
> > IETF Last Call comments that you receive, and strive to resolve them
> > through discussion or by updating the draft.
> >
> > Document: draft-ietf-sidrops-rtr-keying-01
> > Reviewer: Dhruv Dhody
> > Review Date: 14 Dec 2018
> > IETF LC End Date: Unknown
> > Intended Status: Standard
> >
> > Summary:
> >
> >   I have some minor concerns about this document that I think should be
> >   resolved before publication.
> >
> > Comments:
> >
> >   This document describe the provisioning of BGPsec-speaking routers with the
> >   appropriate public-private key-pairs. It describes two ways - Router Driven
> >   and Operator Driven of doing this. This document does not provide any
> >   protocol extensions.
> >
> >   Thank you for including Appendix B, it helped a lot.
> >
> > Major Issues:
> >
> >   No major issues found.
> >
> > Minor Issues:
> >
> >   (1) I am not sure about the status of the document. Since this document
> >   does not define any protocol extensions, this document reads to me as
> >   Informational or BCP. I am quite sure this is going to be asked during IESG
> >   reviews, it would be good idea to discuss and conclude on this early on.
>
> You’re right this doesn’t define any protocol so standards track might not be the way to go, but it was BCP earlier in its lifetime.  The SIDR WG decided to make it standard track.  To be entirely honest here (and I really hate to be writing this), I could argue any of the options, but I am really just hoping to be told what it should be by the IESG.

[Dhruv]: Lets leave it to the IESG then, and in case other authors
have a preference maybe adding a justification in the writup could
help the reviewers.

>
> >   (2) I also find 'sub-methods' to describe the two different mechanism (or
> >   models) as incorrect.
>
> Would just saying “two methods” as opposed to “two sub-methods” work for you?
>

[Dhruv]: Yes.

> >   Also, did the authors/WG consider making Router-driven as default and
> >   operator-driven to be used with utmost care and only when router-driven is
> >   not possible?
>
> See Randy’s response.  I should add that there was at least one person in the WG who thought that router-drive and operator-driven were fraught with danger so that’s why we have s8. We basically couldn’t agree which one was the MTI so we just left it alone because … well see Randy’s response :/

[Dhruv]: Thanks for the explanation, I will watch out for what the
IESG thinks about this.

>
> >   (3) Introduction mentions only Section 8, suggest to include some more text
> >   that describes the flow of the document to increase the readability.
>
> The penultimate paragraph in s1 talks about the rest of the document and specifically calls out s8 because it’s the one section that doesn’t quite fit.  The rest of the document talks about the router and operator driven methods and s8 describes another method where it is more automated. Could we maybe just tweak the last sentence to say:
>
>    Section 8 describes another method that requires more
>    capable routers.
>

[Dhruv]: That helps. Maybe go one step further with -

   Section 2 to Section 7 describes the various steps involved for an operator
   to use the two methods to provision new and existing routers.  The methods
   described involve the operator configuring the two end points (i.e.,
   the management station and the router) and acting as the
   intermediary.  Section 8 describes another method that requires more
   capable routers.

> >   (4) Section 4/5 used AS number and the BGP Identifier; where as Appendix B
> >   says subject name and serial number for the router. We should link these
> >   somehow.
>
> Yes we should; what goes in the subject and serial number field come from RFC8209 s3.1.1.  Let’s change Appendix B to:
>
>    But before sending it, you need to also send the CA
>    the subject name (i.e., “ROUTER-“ followed by the AS Number)
>    and serial number (i.e., the 32-bit BGP Identifier) for the router.
>

[Dhruv]: That works great!

> >   (5) Section 5.2.1 has 'AS's End Entity (EE) private key' and AS's EE
> >   certificate(s); This is not clear, is this 'AS's key and certificate'
> >   belongs to the management station? Can you add a sentence clarifying this.
>
> So what’s going on here is that the operator has generated the key pair and it needs to get that back to the router.  The first paragraph tells you how to get the private key back with the ability to verify that the operator actually sent it to the router.  The second paragraph is about verifying the signature on the CMS wrapper that encapsulates the private key - and to do that you need the operator’s certificate and any other certificate.  I see changing it to Operator’s EE private key and Operator’s EE certificate as clarifying this because we don’t use AS EE anywhere else in the document.
>

[Dhruv]: AS's EE threw me off, use of Operator's EE makes sense!

> >   (6) It feels like, this document uses SHOULD as a default level. I am not
> >   sure if that is right in every instance of its use.
> >
> > Nits:
> >
> >   - section 4
> >     s/a BGP Identifier of 0 may be used/a BGP Identifier of 0 MAY be used/
>
> sure
>
> >   - section 5
> >     s/transmits the AS it has chosen or the router/transmits the AS
> > it has chosen on the router/
>
> good catch
>
> >   - section 7
> >     s/certs-ony/certs-only
>
> ditto
>
> >   - section 9
> >     Took me a while to parse this, might be helpful to make a list or
> >     rephrase -
> >
> >         When an active router key is to be revoked, the process of requesting
> >         the CA to revoke, the process of the CA actually revoking the
> >         router's certificate, and then the process of re-keying/renewing the
> >         router's certificate, (possibly distributing a new key and
> >         certificate to the router), and distributing the status, takes time
> >         during which the operator must decide how they wish to maintain
> >         continuity of operations, with or without the compromised private
> >         key, or whether they wish to bring the router offline to address the
> >         compromise.
>
> I agree this is pretty wordy, but since you did get through it I am hoping to relying on the RFC-editor and their excellent copy-editing skills ;)
>
> >   - section 10
> >     Does not parse -
> >
> >         ..employees that no longer need access to a
> >         routers SHOULD be removed the router to ensure only those authorized
> >         have access to a router.
>
> How about:
>
>    employees that no longer need access to a router SHOULD
>    have their access rights removed for that router to ensure only
>    those authorized for that router have access.
>

[Dhruv]: Since the consenses seems to be removal of this text, (in
case it matters) thats fine with me as well :)

Thanks!
Dhruv

> spt
>