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

[Sean Turner <[e-mail]>]

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) <[e-mail]> wrote:
> 
> 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:[e-mail]] On Behalf Of Christopher Morrow
> Sent: Monday, October 02, 2017 11:14 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017
>  
> 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
> <Review-v3-Router-Keying-for-BGPsec.pdf>