Subject: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017

From: Christopher Morrow <[email-masked]>
Date: Mon, 2 Oct 2017 23:14:20 -0400

WG Folk,
I thought I had sent this note our previously, but... better late then
never sent:

Please consider this the WGLC for:
  https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-13

Abstract:
  "BGPsec-speaking routers are provisioned with private keys in order to
   sign BGPsec announcements.  The corresponding public keys are
   published in the global Resource Public Key Infrastructure, enabling
   verification of BGPsec messages.  This document describes two methods
   of generating the public-private key-pairs: router-driven and
   operator-driven."

Please send along comments/complaints/issues/kudos (to the authors), to the
list and I'll see you all in ~14 or so days.

Thanks!
-chris
co-chair

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 5 Oct 2017 14:27:43 +0200

Hi,

This looks reasonable to me, but I can’t speak really to the router implementation - being neither a network operator nor a router vendor. As a CA operator I note that the draft is not restrictive about exactly how the RPKI CA gets the CSR, and the signed certificate is returned. That’s a good thing to me at this point, so I would say ship it. But I believe it would be good to keep this in mind in the sidr-ops WG - if this proves operationally difficult then it may be something to discuss further later.

Tim

> On 3 Oct 2017, at 05:14, Christopher Morrow <[email-masked]> wrote:
> 
> WG Folk,
> I thought I had sent this note our previously, but... better late then never sent:
> 
> Please send along comments/complaints/issues/kudos (to the authors), to the list and I'll see you all in ~14 or so days.
> 
> Thanks!
> -chris
> co-chair
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sean Turner <[email-masked]>
Date: Thu, 5 Oct 2017 11:36:53 -0700

Always happy to see the “ship it” response to a WGLC :)

Note that we weren’t restrictive on purpose.   There’s a whole bunch of ways how the CSR could get delivered based on where it was made and it would be silly for us to have said you must do it this way. 

spt

> On Oct 5, 2017, at 05:27, Tim Bruijnzeels <[email-masked]> wrote:
> 
> Hi,
>

---

From: Di Ma <[email-masked]>
Date: Sat, 7 Oct 2017 10:02:51 +0800

I think this document is ready to go through IESG review.

Ship it.

Di

> 在 2017年10月6日，02:36，Sean Turner <[email-masked]> 写道：
>

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Thu, 12 Oct 2017 21:43:43 +0000

Hi,

I  believe this draft is important. Said that, I also believe that it needs some more work before it is ready to advance to IESG review.

Sriram and I were reading the draft carefully and after some discussion, I added our findings into the document itself.

For easier reading, I added the comments as attachment in pdf form.

The main issues we identified were in sections 5, 6, and 8 of the document.

The sections 5 and 6 are not easy to understand and the flow is somewhat confusing. We propose to restructure the sections 5 and 6 into three sections,  each section having a well-defined outcome.

This makes it easier for an implementer to understand what to do and what is expected.

Also in section 8, we identified some overlapping with draft-ietf-sidrops-bgpsec-rollover-02. We propose some changes and references to mitigate the overlaps.

Once our concerns are addressed, we believe that the document should advance to IESG.

We are willing to help out in any capacity,

Thanks,

Oliver

From: sidr [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: Monday, October 02, 2017 11:14 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017

WG Folk,

Please consider this the WGLC for:
  https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-13<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-sidr-rtr-keying-13&data=02%7C01%7Coliver.borchert%40nist.gov%7C928c470f76354b13f98d08d50a0ce109%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636425972798413518&sdata=%2B4l88vCjZsKlctqmu2QGf24s%2FmhWtY2GgTSiSQm9%2FOI%3D&reserved=0>

Abstract:

Thanks!
-chris
co-chair

---

From: Sean Turner <[email-masked]>
Date: Sun, 15 Oct 2017 22:08:40 -0400

Just going to run through them in order but grouping some together.

0) 

  In the operator-driven method, the operator generates the private/
  public key-pair and sends it to the router, perhaps in a PKCS#8

[ob] "perhaps" As implementer, this is somewhat confusing.

   package [RFC5958].

[spt] sure I changed “perhaps” to "e.g.” ;)

1) 

  In the router-driven method, the router generates its own public/
  private key-pair.

[ob] End the sentence here

[ob] -------- The paragraph below contains too much detail for the introduction

[spt] The introduction just kind of kept growing.  And, I think somebody asked for concrete references somewhere along the way.  The references are   elsewhere in the document so maybe we can drop the super technical bits from the intro If we’re going to change this sentence to make it that short I’ll likely that the e.g., bit out of the previous paragraph.

2) update references

[spt] Yep - and done

3) s3 Intro

[ob] Maybe more than one sentences make it clearer. Not easy to
[ob] understand.

[spt] it is kind of a mouthful, how about:

  A number of options exist for the operator management
  station to exchange PKI-related information with routers
  and with the RPKI including:

  - Use application/pkcs10 media type [RFC5967]  to
    extract certificate requests and application/pkcs7-mime
    [RFC5751] to return the issued certificate

  - Use FTP or HTTP per [RFC2585], or

  - Use the Enrollment over Secure Transport (EST) protocol
    per [RFC7030].

4) router burden in s4, s6 (now s7), and s7, etc

   To start, the operator uses the communication channel to
   install the appropriate RPKI Trust Anchor' Certificate (TA Cert)
   in the router. This will later enable the router to validate the
   router certificate returned in the PKCS#7.

[ob] Section 8.1 specifies that the operator is responsible to assure
[ob] that the router has valid keys. Therefore, it is not clear why this
[ob] above paragraph necessary.
[ob] Maybe the above paragraph could be a feature of the “Advanced
[ob] Deployment [ob] Scenarios” in section 7

…

[ob] This is again back to trust. The operator should verify the
[ob] certificate, not the router.The operator MUST verify the
[ob] certificate prior publishing it. This is outside of the scope of the
[ob] router.

[spt] I agree with your point that it’s up to the operator to ensure the router’s keys are valid.  But, operators are humans and they make mistakes.

[spt] While s8.1 does include text stating that the operator is responsible to ensure valid keys are used, it’s in s8.1 much later in the document.  We placed this here to avoid a back pointer.

[spt] WRT burdening the router with verifying the private key corresponds to the returned public key: You’re right it’s the operator’s job, but operator’s make mistakes.  If the router also checks that the private key corresponds to the returned public key, it’s goodness all around.

6) Comments on restructuring s5-7.

[spt] Some of this I think might make sense, but not all of it ;)

7) s5

[spt] In the choose your own adventure of s5, I’d prefer to the leave the AS inclusion text in sub-sections.  Sure it’s repeated twice, but then each section is self-contained.

[spt] The 2nd para in s5.1 is there to address some comment we got long ago.  I’d like to leave the text, but add “NOTE:” in the front of it so people get that something has to happen for the RPKI to authenitcate the router.

8) new s7

[spt] I’m not sure why we’d move the paragraph that talks about checking the sig on the PKCS#8 and Certificate to s5.2.1.  The certificate isn’t yet in the picture yet so to me it seems to fit best where it is.

9) s7 (now s8)

[spt] We can’t move it to an informative appendix because s7 was a grand compromise between Max and the authors.  He assertion is that the manual process is weak security and it really ought to be more automated.

[spt] WRT “More PKI-capable router” there’s no really a reference.  It’s really just that the router supports some of the things listed in the remainder of the paragraph.  But, the basic idea is that the operator won’t be messing with the CLI.

[ob] How is this with RouterID 0 for shared keys within an AS? Could this
[ob] cause conflicts? Same for multiple keys for same router with
[ob] RouterID?

[spt] I’m trying to figure out whether this comment just applies to the advanced scenarios or more generally?

[spt] Here’s how I see it: Operator has two routers each with IEEE 802.1 AR certificates.  They communicate the subject names (and maybe the public keys) from the AR certificates to the CA.  The CA then accepts requests from these two routers and no others.  If the operator tells the CA to give them the same AS number it does if not it doesn’t.  Makes sense?

10) s8 (now s9)

[spt] I’m okay with the re-write of the intro, but I kind of want to keep the part about it being the operator’s responsibility to maintain the key for their entire lifetime.

[spt] WRT another ops RFC reference are thinking about something like ghostbusters?  Other than that I’m not sure what else we’d refer to.

[spt] I’m happy to point to the keyroll over spec.

[spt] re mentioning BG4 fallback isn't that kind of implied with disabling BGPsec?  I mean guess not, but would love for you to propose some text ;)

spt

> On Oct 12, 2017, at 17:43, Borchert, Oliver (Fed) <[email-masked]> wrote:
> 
> Hi,
>  
> <Review-v3-Router-Keying-for-BGPsec.pdf>

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Tue, 17 Oct 2017 19:49:39 +0000

Sean,

Thanks for addressing our concerns. With the new changes in place I believe it is ready to advance,
“ship it”

Oliver

On 10/15/17, 10:08 PM, "Sean Turner" <[email-masked]> wrote:

    0) 

    
       package [RFC5958].

    1) 

    

    2) update references
    
    [spt] Yep - and done
    
    3) s3 Intro

    

    

    
    
    …

    

    
    
    7) s5

    
    8) new s7

    9) s7 (now s8)

    

    
    10) s8 (now s9)

    

    spt
    
    >   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-sidr-rtr-keying-13&data=02%7C01%7Coliver.borchert%40nist.gov%7Ca922cab9e2474bbfa0ec08d5143ad472%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636437165271776966&sdata=tKol0WM%2BXO3sZBx1fhBU0SnUFaV%2BnBPNQQjbYMvoe1E%3D&reserved=0
    >  
    > Abstract:

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 17 Oct 2017 20:42:16 +0000

>Thanks for addressing our concerns. With the new changes in place I believe it is ready to advance, “ship it”

+1

Yes, thank you, Sean.
As Oliver mentioned, the comments you received from him were combined comments from the two us. 
I have looked over the new version you sent us. Looks good to me.

When you upload an updated version, please consider including this editorial suggestion:
s/[RFC8205] describes gritty details,/[RFC8205] describes the details of the BGPsec protocol,/

Thanks.
Sriram

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 18 Oct 2017 15:07:27 -0400

great, so .. if everyone agrees that commentsa re dealt with I'll send this
forward to iesg?

On Tue, Oct 17, 2017 at 4:42 PM, Sriram, Kotikalapudi (Fed) <
[email-masked]> wrote:

> >Thanks for addressing our concerns. With the new changes in place I
> believe it is ready to advance, “ship it”
>
> +1
>
> Yes, thank you, Sean.

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 18 Oct 2017 20:56:25 +0000

Yes, fine with me, ship it,
Oliver

From: Christopher Morrow [mailto:[email-masked]]
Sent: Wednesday, October 18, 2017 3:07 PM
To: Sriram, Kotikalapudi (Fed) <[email-masked]>
Cc: Sean Turner <[email-masked]>; Borchert, Oliver (Fed) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017

great, so .. if everyone agrees that commentsa re dealt with I'll send this forward to iesg?

+1

Yes, thank you, Sean.

Thanks.
Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 19 Oct 2017 11:46:06 +0000

Chris,

I think you should wait for Sean to upload version-14.
He sent it to me and Oliver but not uploaded yet.

Sriram
________________________________________
From: Christopher Morrow <[email-masked]>
Sent: Wednesday, October 18, 2017 3:07 PM
To: Sriram, Kotikalapudi (Fed)
Cc: Sean Turner; Borchert, Oliver (Fed); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017

+1

Yes, thank you, Sean.

Thanks.
Sriram

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 19 Oct 2017 12:05:34 -0400

ok terrific,

On Thu, Oct 19, 2017 at 7:46 AM, Sriram, Kotikalapudi (Fed) <
[email-masked]> wrote:

> Cc: Sean Turner; Borchert, Oliver (Fed); [email-masked];
> [email-masked]; [email-masked]; draft-ietf-sidr-rtr-keying@
> ietf.org
> [email-masked]<mailto:[email-masked]>> wrote: