Skip to main content

Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-06

Revision differences

Document history

Date Rev. By Action
2019-07-12
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-06-24
06 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-06-06
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-05-17
06 (System) RFC Editor state changed to EDIT
2019-05-17
06 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-05-17
06 (System) Announcement was received by RFC Editor
2019-05-16
06 (System) IANA Action state changed to No IANA Actions from In Progress
2019-05-16
06 (System) IANA Action state changed to In Progress
2019-05-16
06 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2019-05-16
06 Cindy Morgan IESG has approved the document
2019-05-16
06 Cindy Morgan Closed "Approve" ballot
2019-05-16
06 Cindy Morgan Ballot approval text was generated
2019-05-14
06 Sean Turner New version available: draft-ietf-sidrops-rtr-keying-06.txt
2019-05-14
06 (System) New version approved
2019-05-14
06 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush
2019-05-14
06 Sean Turner Uploaded new revision
2019-05-06
05 Roman Danyliw
[Ballot comment]
Thanks for making the updates in -04 and -05 to address ekr’s DISCUSSes.  A few additional items:

(1) Typos:
** Section 5.2.1.  s/operators's/operators'/ …
[Ballot comment]
Thanks for making the updates in -04 and -05 to address ekr’s DISCUSSes.  A few additional items:

(1) Typos:
** Section 5.2.1.  s/operators's/operators'/
** Appendix B.  s/pubic/public/

(2) Section 10
PKI-relying protocols, of which BGPsec is one, have
  many issues to consider - so many, in fact, entire books have been
  written to address them; so listing all PKI-related security
  considerations is neither useful nor helpful. 

It seems odd to say there is a large body of knowledge of relevant issues that won’t be discussed/cited/referenced here.

(2) Appendix B.  The n00b Guide to BGPsec Key Management

It seems derogatory to refer to a section as being for “n00bs”.  I would recommend alternative language.
2019-05-06
05 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-04-11
05 Sean Turner New version available: draft-ietf-sidrops-rtr-keying-05.txt
2019-04-11
05 (System) New version approved
2019-04-11
05 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush
2019-04-11
05 Sean Turner Uploaded new revision
2019-03-05
04 Alissa Cooper [Ballot comment]
Thank you for addressing my DISCUSS and COMMENT.
2019-03-05
04 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2019-02-27
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-02-27
04 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-02-27
04 Sean Turner New version available: draft-ietf-sidrops-rtr-keying-04.txt
2019-02-27
04 (System) New version approved
2019-02-27
04 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush
2019-02-27
04 Sean Turner Uploaded new revision
2019-01-24
03 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2019-01-24
03 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-01-24
03 Martin Vigoureux
[Ballot comment]
Hello,

thank you for this Document.
I only have a couple of questions:

  In the operator-generated method, the operator SHOULD extract the …
[Ballot comment]
Hello,

thank you for this Document.
I only have a couple of questions:

  In the operator-generated method, the operator SHOULD extract the
  certificate from the PKCS#7 certs-only message, and verify that the
  private key it holds corresponds to the returned public key.

  The router SHOULD extract the certificate from the PKCS#7 certs-only
  message and verify that the public key corresponds to the stored
  private key.

I believe SHOULD applies to extract and to verify, correct?
But I wonder why isn't that a MUST, or asked differently, what could happen wrong if that verification was not done?

Thank you
2019-01-24
03 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-01-24
03 Ignas Bagdonas [Ballot comment]
A nit: s/NetConf/NETCONF
2019-01-24
03 Ignas Bagdonas [Ballot Position Update] New position, Yes, has been recorded for Ignas Bagdonas
2019-01-24
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-01-23
03 Terry Manderson
[Ballot comment]
[Authors/Shepherd need not respond these comments, these are just thoughts to take on as food for thought]

Thank you for a concise document, …
[Ballot comment]
[Authors/Shepherd need not respond these comments, these are just thoughts to take on as food for thought]

Thank you for a concise document, and especially thank you for the very informal appendix ("B") to explain BGPsec/PKI key management to people who are more concerned with making sure packets go from "here" to "there" and not be crypto key management experts.

I have no strong concerns about document status, but BCP feels about right to me given the art of dealing with key material on routing kit is likely to evolve as experience dictates - that said, I won't be out of shape if the sponsoring AD and the rest of the IESG feels otherwise - however I see that BCP looks like the consensus at this stage.

I'm torn about the absence of a clear recommendation to choose between a router-method operator-method. On one hand it seems a deficiency to leave it as "free to choose" without providing a set of considerations that may help direct the operators naive choice, and yet on the other hand the experience gained thus far appears limited and this BCP is yet to find its way, and may well be updated in future.
2019-01-23
03 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2019-01-23
03 Eric Rescorla
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D13996



DETAIL
S 2.

>      Operators are free to use either the router-driven or …
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D13996



DETAIL
S 2.

>      Operators are free to use either the router-driven or operator-driven
>      method as supported by the platform.  Regardless of the method
>      chosen, operators first establish a protected channel between the
>      management system and the router.  How this protected channel is
>      established is router-specific and is beyond scope of this document.

This seems rather under-specified. Given that we know that people are
not careful about this, I think you need to specify some sort of
minimum requirements for this channel. That need not be a particular
protocol, but it needs to specify the security properties it provides.
I see you have some SHOULD-level language later, but I think you need
MUST level, and as noted below, I think the guidance is wrong.


S 5.2.
>      the BGP Identifier when it sends the CSR to the CA.

>      Even if the operator cannot extract the private key from the router,
>      this signature still provides a linkage between a private key and a
>      router.  That is, the operator can verify the proof of possession
>      (POP), as required by [RFC6484].

It's not clear to me what is being claimed in terms of PoP here. As I
understand it, the certificate is a binding between the AS number/BGP
identifier pair and the public key, but if neither of those is in the
PKCS#10 request, then they're not signed over by the private key, and
so PoP isn't really operative. The relevant question is whether if I
obtain the PKCS#10 request I can obtain a certificate for an identity
other than the intended one.


S 5.2.1.
>      ensure the returned private key did in fact come from the operator,
>      but this requires that the operator also provision via the CLI or
>      include in the SignedData the RPKI CA certificate and relevant
>      operator's EE certificate(s).  The router should inform the operator
>      whether or not the signature validates to a trust anchor; this
>      notification mechanism is out of scope.

I don't understand what security this is intended to provide. As I
understand it, the way this works is that the operator signs the
PKCS#8 package and then sends it to the router, which verifies the
signature. This verification is performed based on a key configured by
the operator, right? But in that case, if someone obtains operator
access to the router, they can just configure their own key, thus
bypassing the signature check.
Secondarily, I don't understand how this works if the RPKI CA
certificate is included in the SignedData, because then how do I
validate it against a trust anchor. Finally, how does the router know
which of the large number of EEs signed by the RPKI CA it should
accept signed PKCS#8 messages from.




S 6.
>      private key it holds corresponds to the returned public key.  If the
>      operator saved the PKCS#10 it can check this correspondence by
>      comparing the public key in the CSR to the public key in the returned
>      certificate.  If the operator has not saved the PKCS#10, it can check
>      this correspondence by generating a signature on any data and then
>      verifying the signature using the returned certificate.

It is not clear to me that this is correct. You seem to be assuming
that it given a key pair (K_priv, K_pub), it is not possible to
generate a new key K_pub' that will validate signatures made with
K_priv. This isn't ordinarily an assumption we make of digital
signature systems.


S 8.
>          the CA prior to operator initiating the router's CSR.  CAs use
>          authentication material to determine whether the router is
>          eligible to receive a certificate. Authentication material at a
>          minimum includes the router's AS number and BGP Identifier as
>          well as the router's key material, but can also include
>          additional information. Authentication material can be

Surely it also includes some information that allows the router to
prove it is entitled to a key with that AS and BGP identifier, but I'm
not seeing this here.


S 12.1.
>      CSR you sent; the certificate will include the subject name, serial
>      number, public key, and other fields as well as being signed by the
>      CA.  After the CA issues the certificate, the CA returns the
>      certificate, and posts the certificate to the RPKI repository.  Check
>      that the certificate corresponds to the private key by verifying the
>      signature on the CSR sent to the CA; this is just a check to make

This is not the right check. The CSR contains the public key. If you
want to check, make sure it is identical to the one in the cert.
2019-01-23
03 Eric Rescorla
[Ballot comment]
S 1.
>      These two methods differ in where the keys are generated: on the
>      router in the …
[Ballot comment]
S 1.
>      These two methods differ in where the keys are generated: on the
>      router in the router-driven method, and elsewhere in the
>      operator-driven method.  Routers are required to support at least one
>      of the methods in order to work in various deployment environments.
>      Some routers may not allow the private key to be off-loaded while
>      others may.  While off-loading private keys would ease swapping of

Nit: "off-load" has multiple meanings. I would suggest "exported"




S 1.
>      operator-driven method.  Routers are required to support at least one
>      of the methods in order to work in various deployment environments.
>      Some routers may not allow the private key to be off-loaded while
>      others may.  While off-loading private keys would ease swapping of
>      routing engines, exposure of private keys is a well known security
>      risk.

This is a somewhat shallow treatment of this. Specifically:

1. There are multiple ways in which a device might allow a key not to
be exported. For instance, there might not be a command, but it might
be in unencrypted NVRAM. Or, it might be in an HSM. These have very
different security properties.

2. There are designs which allow a key to be moved from device to
device without exposure, e.g.,, a hardware token.


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

>      The router-driven method mirrors the model used by traditional PKI
>      subscribers; the private key never leaves trusted storage (e.g.,
>      Hardware Security Module).  This is by design and supports classic

This seems overly concrete. The router may or may not have an HSM, but
there are benefits even if it does not.


S 1.
>      ensure that no one can impersonate the subscriber.  For non-humans,
>      this method does not always work.  For example, when an operator
>      wants to support hot-swappable routers, the same private key needs to
>      be installed in the soon-to-be online router that was used by the the
>      soon-to-be offline router.  This motivated the operator-driven
>      method.

I'm not following this explanation, as it's routine for Internet
servers to have keys in software and be able to transfer them from
device to device. This is, after all, what PEM files do


S 1.
>      acting as the intermediary.  Section 8 describes another method that
>      requires more capable routers.

>      Useful References: [RFC8205] describes gritty details, [RFC8209]
>      specifies the format for the PKCS#10 certification request, and
>      [RFC8208] specifies the algorithms used to generate the PKCS#10's

Nit "The PKCS#10's signature" is not grammatical


S 2.
>      method as supported by the platform.  Regardless of the method
>      chosen, operators first establish a protected channel between the
>      management system and the router.  How this protected channel is
>      established is router-specific and is beyond scope of this document.
>      Though other configuration mechanisms might be used, e.g.  NetConf
>      (see [RFC6470]), the protected the protected channel between the

"the protected the protected"


S 3.
>      bis] to return the issued certificate,

>      - Using FTP or HTTP per [RFC2585], and

>      - Using Enrollment over Secure Transport (EST) protocol per
>      [RFC7030].

I'm surprised you don't list ACME.


S 5.
>      is sometimes referred to as a Certificate Signing Request (CSR), may
>      be generated by the router or by the operator.

>      The PKCS#10 request SHOULD be saved to enable verifying that the
>      returned public key in the certificate corresponds to the private
>      used to generate the signature on the CSR.

This is generally not necessary. In most systems, the private key
syntax either includes the public key or the public key can be
generated from the private key.




S 5.1.

>      NOTE: If a router were to communicate directly with a CA to have the
>      CA certify the PKCS#10 certification request, there would be no way
>      for the CA to authenticate the router.  As the operator knows the
>      authenticity of the router, the operator mediates the communication
>      with the CA.

This doesn't seem like it's necessarily true. For instance, with ACME
the operator could provide the router with a credential sufficient to
authenticate the request.


S 5.2.1.

>  5.2.1.  Using PKCS#8 to Transfer Private Key

>      A private key can be encapsulated in a PKCS#8 Asymmetric Key Package

>      [RFC5958] and should be further encapsulated in Cryptographic Message

SHOULD?


S 10.
>      Private key protection in transit: Mistakes here are, for all,
>        practical purposes catastrophic because disclosure of the private
>        key allows another entity to masquerade as (i.e., impersonate) the
>        signer; transport security is therefore strongly RECOMMENDED.  The
>        level of security provided by the transport layer's security
>        mechanism SHOULD be commensurate with the strength of the BGPsec

I'm not sure "commensurate" is what's needed here. For instance, the
transport channel might be much more secure than the router key (e.g.,
P-521 and AES-256 with a RSA-2048 router key).

More generally, it's not clear to me that these are really connected
at all, as the threat environments are totally different. As noted
above, I believe you should just specify a minimal level.


S 12.1.
>      and integrity and replay protection.

>  Appendix B.  The n00b Guide to BGPsec Key Management

>      This appendix is informative.  It attempts to explain all of the PKI
>      technobabble in plainer language.

All fields have jargon, but generally deriding another field's
language as "technobabble" doesn't seem that helpful.


S 12.1.
>      BGPsec speakers send signed BGPsec updates that are verified by other
>      BGPsec speakers.  In PKI parlance, the senders are referred to as
>      signers and the receivers are referred to as relying parties.  The
>      signers with which we are concerned here are routers signing BGPsec
>      updates.  Signers use private keys to sign and relying parties use
>      the corresponding public keys, in the form of X.509 public key

They're not in the form of public key certificates, they are carried
in certificates.


S 12.1.
>      that will generate the key pair for the algorithms referenced in the
>      main body of this document; consult your router's documentation for
>      the specific commands.  The key generation process will yield
>      multiple files: the private key and the public key; the file format
>      varies depending on the arcane command you issued, but generally the
>      files are DER or PEM-encoded.

Actually, it may or may not generate multiple files. That's
implementation specific.
2019-01-23
03 Eric Rescorla [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla
2019-01-23
03 Deborah Brungard
[Ballot comment]
I agree with the status as BCP. It is describing current practices.

On some other comments:

I like having both approaches in the …
[Ballot comment]
I agree with the status as BCP. It is describing current practices.

On some other comments:

I like having both approaches in the same document vs. two different BCPs. I don't see the
need to say "which is better" (Alvaro's comment). The document is quite clear on the different uses.
It is dependent on much more than what is described here. And as section 8 says, it is becoming blurred.

I think Appendix A is fine as separate from the main document. As section 2 says it is outside the
scope.

I liked Appendix B - Thanks! It's not so scary - especially with good automation tools.
2019-01-23
03 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2019-01-23
03 Alissa Cooper [Ballot discuss]
As this is a BCP, I don't understand why transport encryption of the private key is not normatively required. Could you explain?
2019-01-23
03 Alissa Cooper
[Ballot comment]
Given that this document is ostensibly specifying a "best" current practice, I would have expected a clearer expression of preference for the router-driven …
[Ballot comment]
Given that this document is ostensibly specifying a "best" current practice, I would have expected a clearer expression of preference for the router-driven method over the operator-driven method, e.g., something like BGPsec-speaking routers MUST implement the router-driven method and MAY implement the operator-driven method. Or if there is some exception case that makes that MUST problematic, it would at least be good to emphasize which one of these is actually "best" from a security perspective, even though the other one is being specified and we know will be used.

Nit in Section 1:

s/gritty details/details of the BGPsec protocol/
2019-01-23
03 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2019-01-23
03 Alvaro Retana
[Ballot comment]
(1) I don't really have a strong objection for this document being a BCP.  However, while documenting two different methods, there is no …
[Ballot comment]
(1) I don't really have a strong objection for this document being a BCP.  However, while documenting two different methods, there is no clear indication of "what is believed to be the best" [rfc2026], or even better, which method should be used in what situations.  I understand that operators have different preferences/needs and that prescribing one method as the default in not the right thing to do. 

I would really like to see some text (maybe a "Deployment Considerations" section) that talks about when one or the other might be preferred/considered.


(2) §4: s/BGP Identifier [RFC4271]/BGP Identifier [RFC6286]


(3) §4: "In the case where the operator has chosen not to use unique per-router certificates, a BGP Identifier of 0 MAY be used." rfc6286 defines the BGP Identifier as always being non-zero.  rfc8209 says that "if the same certificate is issued to more than one router (and hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the Issuer."  It seems to me that it doesn't matter which ID is used...it just can't be 0.  The simple fix is to just remove the sentence.


(4) §8: "Enabling the router-to-CA connectivity MAY require connections to external networks (i.e., through firewalls, NATs, etc.)."  That "MAY" is out of place because this sentence is just stating a fact.


(5) §8: "Note that the checks performed by the router in Section 7...SHOULD be performed."  Besides confirming the checks from §7, I'm not sure what this sentence really contributes...but I do think that the "SHOULD" is out of place because the Normative language is already in §7. 


(6) Nits
s/used by the the/used by the
s/corresponds to the private used/corresponds to the private key used
2019-01-23
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-01-22
03 Adam Roach
[Ballot comment]
Thanks to the authors for a well-written and clear document. I have one
substantive comment, and a minor editorial nit.

---------------------------------------------------------------------------

§3:

>  …
[Ballot comment]
Thanks to the authors for a well-written and clear document. I have one
substantive comment, and a minor editorial nit.

---------------------------------------------------------------------------

§3:

>  - Using FTP or HTTP per [RFC2585], and

It's not clear from a casual examination whether use of unencrypted and
non-integrity-protected channels for these operations are safe. I would expect
to see a discussion of this in this section and/or section 10. The closest I
could find is the SHOULD-strength (!) recommendation for transport-level
security for private key transport.

Without a more thorough analysis, I suspect we should more strongly deprecate
the use of unencrypted/non-integrity-protected transports. This document is,
after all, supposed to be calling out best practice; and, in 2019, that really
does entail transport security except under the most exceptional circumstances.

---------------------------------------------------------------------------

§2:

>  Though other configuration mechanisms might be used, e.g.  NetConf
>  (see [RFC6470]), the protected the protected channel between the

Nit: duplicate "...the protected..."
2019-01-22
03 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-01-22
03 Ben Campbell
[Ballot comment]
- General: The document says it's intended as BCP, but the data tracker says "Proposed Standard". Was this last called with the correct …
[Ballot comment]
- General: The document says it's intended as BCP, but the data tracker says "Proposed Standard". Was this last called with the correct status?  (I agree with BCP, by the way.)

- I share Benjamin's concern about the idea of moving private keys between routers as a "need" vs "something people do".

§5.2.1: "The router should inform the operator
whether or not the signature validates to a trust anchor; this
notification mechanism is out of scope."

Should that be normative?

§9.3: The second paragraph is a single convoluted sentence. Can it be broken into simpler sentences?

§10:

- "This document defines no protocols. So, in some sense, it introduces
no new security considerations."

I think practices can absolutely come with security considerations. For example, the practice of moving private keys between routers.

- "Private key protection in transit": Is there no expectations that transmitted private keys would have object-level encryption?

§A: I'm curious why this is not part of the main-body security considerations?
2019-01-22
03 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2019-01-22
03 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2019-01-22
03 Alexey Melnikov [Ballot comment]
No strong opinion on document status.
2019-01-22
03 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2019-01-21
03 Warren Kumari Already on Telechat,  just updating Datatracker
2019-01-21
03 Warren Kumari IESG state changed to IESG Evaluation from Waiting for Writeup
2019-01-21
03 Benjamin Kaduk
[Ballot comment]
I know the intended status has been beaten to near death already, but I
could see this as Informational as well as BCP. …
[Ballot comment]
I know the intended status has been beaten to near death already, but I
could see this as Informational as well as BCP.

Section 1

                                      For example, when an operator
  wants to support hot-swappable routers, the same private key needs to
  be installed in the soon-to-be online router that was used by the the
  soon-to-be offline router.  This motivated the operator-driven
  method

As the secdir review notes, there is no need to copy private keys to hot-swap routers
(unless there is something special about the "hot-swap" case that nullifies
the arguments he made?).

It rather seems that we should avoid framing this behavior as justified by
a need for hot-swapping, but rather as something that people do to work
around processes that do not admit the more secure workflow, as an
operational reality.

Section 2

  (see [RFC6470]), the protected the protected channel between the

nit: duplicate "the protected"

Section 5

  The PKCS#10 request SHOULD be saved to enable verifying that the
  returned public key in the certificate corresponds to the private
  used to generate the signature on the CSR.

I mostly assume this is done by the party that generates the CSR, though
perhaps one could read it as being done on the router always.  (I guess
later on we do recommend both the operator and router to do this
verification.) This could be reworded, though, either to remove the 2119
language ("Retaining the CSR allows for verifying that [...]" or to apply
to the actual verification as opposed to just the saving.

Section 5.1

  NOTE: If a router were to communicate directly with a CA to have the
  CA certify the PKCS#10 certification request, there would be no way
  for the CA to authenticate the router.  As the operator knows the
  authenticity of the router, the operator mediates the communication
  with the CA.

nit: I think that the thing we care about here is the CA's ability to show
that the request is authorized.  The operator is assumed to have an
account/relationship with the CA and a channel via which to authorize
cert-signing requests.  In particular, "no way" is a rather strong
statement, and would seem to deny the possibility of a three-party workflow
where the router sends the CSR to the CA but the operator logs in to the CA
independently and is presented with a list of pending requests to approve.
(It would also preclude the operator from delegating their authorization at
the CA to the router, as described in Section 8.)

Section 5.2 ("Operator-Generated Keys")

  Even if the operator cannot extract the private key from the router,
  this signature still provides a linkage between a private key and a
  router.  That is, the operator can verify the proof of possession
  (POP), as required by [RFC6484].

This paragraph seems a bit of a non-sequitur -- if the operator just
generated the key, it sure isn't going to need to extract the private key
from the router to sign something using it!

Section 6

  In the operator-generated method, the operator SHOULD extract the
  certificate from the PKCS#7 certs-only message, and verify that the
  private key it holds corresponds to the returned public key.  If the

nit: "private key it holds" is the one the operator holds, not the PKCS#7
certs-only message.  It's probably worth disambiguating, here.

Section 7

  NOTE: The signature on the PKCS#8 and Certificate need not be made by
  the same entity.  Signing the PKCS#8 permits more advanced
  configurations where the entity that generates the keys is not the
  direct CA.

Why are we talking about PKCS#8 (asymmetric key transport) signatures here
at all?  This is the section about installing certificates!  I guess I am
not terribly familiar with the RPKI, but in the Web PKI at least it's quite
uncommon for the CA to be generating the private keys, so mentioning these
together is a non sequitur to me.

Section 8

  More PKI-capable routers can take advantage of this increased
  functionality and lighten the operator's burden.  Typically, these

nit: most readers will not bind "this" to the right thing and will instead
be left confused.

Why do we not mention the need to get the manufacturer-installed key
material (or information thereof) to the operator?

  When a router is so configured, the communication with the CA SHOULD
  be automatically re-established by the router at future times to
  renew or rekey the certificate automatically when necessary (See
  Section 9). This further reduces the tasks required of the operator.

Mentioning renewing certificates is natural, as they have a stated end time
to prepare for.  Re-keying certificates is something of a different matter,
and it would be nice to provide (a link to) some guidance on what
timescales at which to rekey, if we're mentioning rekeying here.
(draft-ietf-sidrops-bgpwec-rollover provides some related guidance, but I
did not see much concrete on this point.)

Section 9.4

  Currently routers often generate private keys for uses such as SSH,
  and the private keys may not be seen or off-loaded from the router.
  While this is good security, it creates difficulties when a routing
  engine or whole router must be replaced in the field and all software
  which accesses the router must be updated with the new keys.  Also,

This seems to be talking about key management for keys other than
BGPsec-signing keys.  Isn't that out of scope for this document?

  any network based initial contact with a new routing engine requires
  trust in the public key presented on first contact.

  To allow operators to quickly replace routers without requiring
  update and distribution of the corresponding public keys in the RPKI,
  routers SHOULD allow the private BGPsec key to be inserted via a

Making this a SHOULD is perhaps an overstatement, since AFAICT this
functionality is not useful for the stated purpose unless the operator has
access to private keys directly (whether by virtue of the operator having
generated the keys or an extraction interface on the current routers).
This is an inherent tradeoff, as stated, between the delay in
update/distribution of public keys in the RPKI vs. reducing the risk of
unauthorized key access.  I'm not making this a Discuss point because it's
not exactly my tradeoff to make, but I do want to be sure that this is
actually the tradeoff that SIDROPS wants to present to the community.

  protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP.  This
  lets the operator escrow the old private key via the mechanism used
  for operator-generated keys, see Section 5.2, such that it can be re-
  inserted into a replacement router. The router MAY allow the private
  key to be to be off-loaded via the protected channel, but this SHOULD
  be paired with functionality that sets the key into a permanent non-
  exportable state to ensure that it is not off-loaded at a future time
  by unauthorized operations.

This last sentence is a somewhat different topic and could probably stand
alone as its own paragraph.  This would also provde the opportunity to
clarify that this offload interface is intended for use in conjunction with
key generation, and the permanent non-exportable state to be applied
thereafter.

Appendix A

I agree with Mirja about the duplication of content and thus non-need for
normative language.
2019-01-21
03 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2019-01-21
03 Mirja Kühlewind
[Ballot comment]
I would recommend to remove the normative language from Appendix A ("SHOULD" in the first sentence) as this is, I think, covered in …
[Ballot comment]
I would recommend to remove the normative language from Appendix A ("SHOULD" in the first sentence) as this is, I think, covered in the security considerations section. If not, it might be worth moving Appendix A to the main body of the document.
2019-01-21
03 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-01-18
03 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2019-01-17
03 Amy Vezza Placed on agenda for telechat - 2019-01-24
2019-01-17
03 Warren Kumari Ballot has been issued
2019-01-17
03 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2019-01-17
03 Warren Kumari Created "Approve" ballot
2019-01-17
03 Warren Kumari Ballot writeup was changed
2019-01-16
03 Sean Turner New version available: draft-ietf-sidrops-rtr-keying-03.txt
2019-01-16
03 (System) New version approved
2019-01-16
03 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush
2019-01-16
03 Sean Turner Uploaded new revision
2019-01-03
02 Warren Kumari Ballot writeup was changed
2018-12-26
02 Scott Bradner Request for Last Call review by OPSDIR Completed: Serious Issues. Reviewer: Scott Bradner. Sent review to list.
2018-12-18
02 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-12-18
02 Sean Turner New version available: draft-ietf-sidrops-rtr-keying-02.txt
2018-12-18
02 (System) New version approved
2018-12-18
02 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush
2018-12-18
02 Sean Turner Uploaded new revision
2018-12-18
01 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-12-16
01 Dhruv Dhody Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Dhruv Dhody.
2018-12-14
01 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-12-14
01 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-sidrops-rtr-keying-01, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-sidrops-rtr-keying-01, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-12-11
01 Daniel Franke Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Daniel Franke. Sent review to list.
2018-12-11
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2018-12-11
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2018-12-07
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Daniel Franke
2018-12-07
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Daniel Franke
2018-12-06
01 Jean Mahoney Request for Last Call review by GENART is assigned to David Schinazi
2018-12-06
01 Jean Mahoney Request for Last Call review by GENART is assigned to David Schinazi
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Dhruv Dhody
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Dhruv Dhody
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Mach Chen
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Mach Chen
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Daniele Ceccarelli
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Daniele Ceccarelli
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Stewart Bryant
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Stewart Bryant
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Patrice Brissette
2018-12-05
01 Min Ye Request for Last Call review by RTGDIR is assigned to Patrice Brissette
2018-12-05
01 Alvaro Retana Requested Last Call review by RTGDIR
2018-12-04
01 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-12-04
01 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-12-18):

From: The IESG
To: IETF-Announce
CC: morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-rtr-keying@ietf.org, sidrops-chairs@ietf.org, Chris …
The following Last Call announcement was sent out (ends 2018-12-18):

From: The IESG
To: IETF-Announce
CC: morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-rtr-keying@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Router Keying for BGPsec) to Proposed Standard


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'Router Keying for BGPsec'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-12-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-12-04
01 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-12-04
01 Warren Kumari Last call was requested
2018-12-04
01 Warren Kumari Last call announcement was generated
2018-12-04
01 Warren Kumari Ballot approval text was generated
2018-12-04
01 Warren Kumari Ballot writeup was generated
2018-12-04
01 Warren Kumari IESG state changed to Last Call Requested from Publication Requested
2018-12-04
01 Sean Turner New version available: draft-ietf-sidrops-rtr-keying-01.txt
2018-12-04
01 (System) New version approved
2018-12-04
01 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush
2018-12-04
01 Sean Turner Uploaded new revision
2018-11-05
00 Chris Morrow Intended Status changed to Proposed Standard from Internet Standard
2018-11-05
00 Chris Morrow
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  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.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This document started life in SIDR and moved to SIDROPS after the SIDR->SIDROPS move happened. In SIDR this document went through ~16 revision, with comments and discussion along the way. The consensus in SIDR was good, in SIDROPS there've been no objections.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are no NITS reported.
There are 3 editorial changes inbound at next revision, none alter the intent of the document.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?


Shepherd: morrowc@ops-netman.net (me)
AD: warren@kumari.net - Warren Kumari

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


The document shepherd read several versions to include the final version.
it seems sane enough to the shepherd.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

no concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

no required reviews.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.


nothing raised.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, there are no IPR conerns.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

none required.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Good consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no threats of appeal

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


no nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.


no formal reviews required

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

no.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

no

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

no

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

no considerations to IANA required.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

no registries required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no automated checks/reviews required.
2018-11-05
00 Chris Morrow Responsible AD changed to Warren Kumari
2018-11-05
00 Chris Morrow IETF WG state changed to Submitted to IESG for Publication from WG Document
2018-11-05
00 Chris Morrow IESG state changed to Publication Requested
2018-11-05
00 Chris Morrow IESG process started in state Publication Requested
2018-11-05
00 Chris Morrow Changed document writeup
2018-11-05
00 Chris Morrow Notification list changed to Chris Morrow <morrowc@ops-netman.net>
2018-11-05
00 Chris Morrow Document shepherd changed to Chris Morrow
2018-11-05
00 Chris Morrow Changed consensus to Yes from Unknown
2018-11-05
00 Chris Morrow Intended Status changed to Internet Standard from None
2018-09-24
00 Chris Morrow This document now replaces draft-ietf-sidr-rtr-keying instead of None
2018-09-24
00 Sean Turner New version available: draft-ietf-sidrops-rtr-keying-00.txt
2018-09-24
00 (System) WG -00 approved
2018-09-21
00 Sean Turner Set submitter to "Sean Turner ", replaces to draft-ietf-sidr-rtr-keying and sent approval email to group chairs: sidrops-chairs@ietf.org
2018-09-21
00 Sean Turner Uploaded new revision