Subject: [RTG-DIR] RtgDir review: draft-ietf-sidrops-rtr-keying-01

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

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.

   (2) I also find 'sub-methods' to describe the two different mechanism (or
   models) as incorrect.
   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?

   (3) Introduction mentions only Section 8, suggest to include some more text
   that describes the flow of the document to increase the readability.

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

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

   (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/
   - section 5
     s/transmits the AS it has chosen or the router/transmits the AS
it has chosen on the router/
   - section 7
     s/certs-ony/certs-only
   - 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.

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

---

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

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

Would just saying “two methods” as opposed to “two sub-methods” work for you?

>   operator-driven to be used with utmost care and only when router-driven is

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

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

>   says subject name and serial number for the router. We should link these

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.

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

>     s/a BGP Identifier of 0 may be used/a BGP Identifier of 0 MAY be used/

sure

> it has chosen on the router/

good catch

>     s/certs-ony/certs-only

ditto

>         key, or whether they wish to bring the router offline to address the

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 ;)

>         routers SHOULD be removed the router to ensure only those authorized

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: Dhruv Dhody <[email-masked]>
Date: Tue, 18 Dec 2018 23:16:28 +0530

Hi Sean, Randy,

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

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

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

> Would just saying “two methods” as opposed to “two sub-methods” work for you?

[Dhruv]: Yes.

> 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 co…

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

>    Section 8 describes another method that requires more

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

>    and serial number (i.e., the 32-bit BGP Identifier) for the router.

[Dhruv]: That works great!

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

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

>    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

---

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