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" <s...@sn3rd.com> wrote:
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)
<oliver.borch...@nist.gov> 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:sidr-boun...@ietf.org] On Behalf Of Christopher Morrow
> Sent: Monday, October 02, 2017 11:14 PM
> To: sidr@ietf.org; sidr-cha...@ietf.org; sidr-...@ietf.org
> 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://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:
> "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>
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
