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

From: Randy Bush <[email-masked]>
Date: Fri, 14 Dec 2018 03:57:00 -0800

i will leave other issues for sean, who is both more expert and more
patient :)

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

we do not tell operators how to run their networks.  for examplem many
will choose operator driven because it allows them to quickly swap new
gear for a failed device without backflow into the rpki.

randy

---

From: Sean Turner <[email-masked]>
Date: Tue, 18 Dec 2018 11:27:26 -0500

Hi!

> On Dec 14, 2018, at 05:41, Dhruv Dhody <[email-masked]> 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.

>   (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?

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

>   (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.

>   (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.

>   (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.

>   (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.

spt

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Dec 2018 08:30:43 -0800

>    those authorized for that router have access.

why are we going into ops practice which is not directly relevant?

randy

---

From: Job Snijders <[email-masked]>
Date: Tue, 18 Dec 2018 17:32:31 +0100

> why are we going into ops practice which is not directly relevant?

I'd just remove the section about employees, this seems to be going a
bit into the weeds.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Dec 2018 08:37:23 -0800

> I'd just remove the section about employees, this seems to be going a

was polling other authors

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Dec 2018 08:55:35 -0800

> was polling other authors

keyur walked up to my desk and agrees with removal.  sean?

randy

---

From: Sean Turner <[email-masked]>
Date: Tue, 18 Dec 2018 12:39:59 -0500

> On Dec 18, 2018, at 11:55, Randy Bush <[email-masked]> wrote:
> 
>>>>> How about:
>>>>> 

I am fine with that. 

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 18 Dec 2018 18:16:01 -0500

Stay tuned for a new version.

spt

> On Dec 18, 2018, at 12:46, Dhruv Dhody <[email-masked]> wrote:
> 
> 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 <[email-masked]> wrote:
>> 
>> Hi!
>> 
> [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.
> 
>> 
> [Dhruv]: Yes.
> [Dhruv]: Thanks for the explanation, I will watch out for what the
> IESG thinks about this.
> 
>> 
> [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.
> 
> [Dhruv]: That works great!
> 
> [Dhruv]: AS's EE threw me off, use of Operator's EE makes sense!
> 
> [Dhruv]: Since the consenses seems to be removal of this text, (in
> case it matters) thats fine with me as well :)
> 
> Thanks!
> Dhruv
> 
>> spt
>>

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 14 Dec 2018 16:11:22 +0530

Hello,

Summary:

Comments:

Major Issues:

   No major issues found.

Minor Issues:

Nits:

   - section 4

   - section 10
     Does not parse -

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 18 Dec 2018 23:16:28 +0530

Hi Sean, Randy,

[Dhruv]: Yes.

Thanks!
Dhruv