The Secretariat has responded to my ticket about the attachment problem noted below.
> On Dec 7, 2017, at 5:17 PM, xxxxx via RT <ietf-act...@ietf.org> wrote: > > Hi Sandy, > > It turns out the archive did not have support for the "text/rtf" mimetype. > This > has now been added and the attachment appears in the messages you referenced > below. So .rtf attachments, if anyone were so wise as to try one, should now show up in the archive. —Sandy > On Nov 14, 2017, at 9:07 PM, Sandra Murphy <sa...@tislabs.com> wrote: > > Wellllll. > > The mail archive does not seem to show attachments. For me. I see do see > attachments on other messages. > > It would be nice to know if anyone has seen attachments on my messages in the > last few weeks. > > At any rate, for the mail archive, the comments are copied below the > signature. > > —Sandy > > > Points that might get lost in the long detailed list that follows: > > 1. RFC4271 (and RFC6286) and RFC8209 use the term “BGP Identifier”. The > main text says RouterID and the Appendix B says “serial number”. I believe > both are talking about what RFC8209 calls the “BGP Identifier”. Most of the > tech sites say router ID or router-id or routerid or RID or some such. But I > think consistency with the referenced text would be good. > > 2. I was initially confused by the text in various places that talks about > the operator adding the AS and RouterID (sic) and sends to the CA. I thought > that meant the operator adds those to the CSR, which would be hard since the > CSR is signed. This occurs a couple of places. I suggest a sentence early > on that says the router certificate includes the AS and router identifier but > the CSR does not include such fields, so the operator must include the AS and > routerID when it sends the CSR to the CA. > > 3. “corresponds” - there are several places that say the certificate must be > validated to prove that the public key corresponds with the private key. The > main body does not say how that correspondence is validated. The appendix > suggests that the operator could validate the signature on the CSR with the > returned router cert in order to validate the key. (a) When the operator > generated the public/private key pair, why not just do a comparison to the > generated public key, presuming it was retained? (b) When the operator > passed the CSR generated by the router to the CA, why not validate the public > key before sending it to the CA? The public key in the returned router > certificate could subsequently be validated by a comparison, presuming the > public key was retained. (c) When the router is supposed to validate the > public key of the router cert it receives, and the operator generated the > public/private key pair, it does not have a copy of the CSR to validate the > correspondence. Took me a bit to realize the router could sign just any old > bit of bytes and then validate the signature with the received router cert. > Right? > > 4. “corresponds” again - there’s no mention of a router verifying that the > router cert it receives has an AS that is configured on the router. There > are lots of other checks and double checks - why not this one? And if the > router has multiple ASs and multiple CSRs have been generated (either by the > router or by the operator), then the router uses the received router > certificate to associate the AS with the public/private key pair, so it knows > which private key to use over which session. Right? > > 5. Section 8 on “Advanced Deployment Scenarios” talks about routers that > already have pre-installed keys (with mentions of types of crypto that are > not known to me, and I did not dig up the refs, so I might be missing > something here). The first paragraph talks about “pre-installed key > material”. I could understand why these pre-installed keys might be useful > in authenticating the router directly to the CA. The “burdens” 1 and 2 also > talk abut “key material”. It did not look to me like the “key material” in 1 > and 2 are talking about these “pre-installed” keys. But I admit to being > very confused by the way the term is used. > > 6. Section 5.2.1 is titled ”Using PKCS#8 to Transfer Public Key”. The text > talks about using PKCS #8 in RFC5958, which allows for including both the > public and private key. But the text of that section is talking about using > PKCS #8 to transmit the private key to the router. I presume the title > should be Using PKCS#8 to Transfer Private Key > > 7. There is an early assumption that all the communication between the > operator and the router is over a protected channel. Section 5.2.1 suggests > using a CMS SignedData to transmit the PKCS#8. RFC5958 suggests several > different “CMS protecting content types” for the PKCS#8 - EncryptedData, > EnvelopedData, etc. I presume that the encrypted versions are not used here > because the protected channel ensures confidentiality. So (a) Appendix A > talks about the key strength to be used for the different crypto algorithms > (encryption, key exchange, …). That’s a big hint that the channel should > provide the related security protections. I think it would be good to > explicitly state the protections the protected channel must provide: “The > protected channel must provide confidentiality, authentication, integrity and > replay protection”. (b) if the protected channel provides authentication and > integrity, why is the protection of the CMS SignedData needed? One possible > reason follows -> (c) The AS EE certificate has an AS extension, not an IP > extension, I presume. So the AS EE certificate would be a second way for the > router to associate a private key with an AS and an appropriate BGP session > (see my comment 3c above). But this applies only when the operator generated > the public/private key pair. > > 8. PKCS#7 needs a reference. I looked at RFC2315. RFC2315 defines several > types of content, e.g., signed-data, enveloped-data, > signed-and-enveloped-data, etc. Is there any reason to specify which type? > Is it operator choice? > > 9. The term “operator” is used to talk about carbon-based units (who are > forgetful), ISP organizations (who peer with other operators), ASs (who have > an AS EE certificates) and management system stations (that receive CSRs from > the router). It was a bit unsettling, but after multiple reads through I’m > getting used to it. I’m not sure I could suggest a term that would fit all > those uses. Perhaps network operators (the ones with DNA) identify > personally with all those uses and think of their person in all cases. “I am > the AS”, “I am the peering entity”, “I am the management of the network”, etc. > > 10. I do not understand the last two paragraphs of section 7 at the bottom > of page 6. It sounds to me like they are out of place, like they belong > elsewhere in the text. > > 11. There are some occurrences of “must” and only a few of “MUST” - the > draft is standards track, so how much of the described behaviors are > mandatory? > > 12. Some consistency nits - PKCS sometimes followed by a space, sometimes > not. protected channel, secure channel, communications channel, protected > session, SSH session, . . . > > ======================================== > > OK, so on to the detailed comments, sequentially through the document > > p3, section 1: > > two methods to provision new and existing routers. The methods > described involve the operator configuring the two end points and > acting as the intermediary. > > What are the two endpoints? The router and the management station? The > router and the CA? I can imagine the operator configuring the management > station, but not the CA. I can imagine the operator acting as the > intermediary between the router and the CA, but not between the router and > the management station. > > p3, section 1: (nit) > > [RFC8208] > specifies the algorithms used to generate the signature. > > If I read correctly, “the” signature in this text would be the signature on > the PKCS#10. > > suggest: > > [RFC8208] > specifies the algorithms used to generate the PKCS#10 signature. > > > p4, section 2 > > See Appendix A for security considerations > for this channel. > > I think it is important to say what security protection are required for this > protected channel. > Appendix A talks about the strength of the key used in the various crypto > algorithms. I think a > sentence something like the following would be useful here or in Appendix A. > > “The protected channel must provide confidentiality, authentication, > integrity” and replay protection.” > > p4, section 4 (nit) > > appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router. > > suggest: > > appropriate RPKI Trust Anchor Certificate (TA Cert) in the router. > or > appropriate RPKI Trust Anchor’s Certificate (TA Cert) in the router. > > p4, section 4 > > The operator also configures the Autonomous System (AS) number to be > used in the generated router certificate. This may be the sole AS > configured on the router, or an operator choice if the router is > configured with multiple ASs. > > There’s a hint here that the operator configures the router to generate just > one router certificate. > RFC8209 allows the router certificate to have one or more ASs, but recommends > that there be multiple router certificates with one AS each. Does this > paragraph intend to limit a router to one router certificate or just to limit > the router to one AS per router certificate? I have questions later about > what happens if the router wants a router certificate for each of multiple > ASs. > > Perhaps “A router with multiple ASs can be configured with multiple router > certificates”, maybe also “by following the process of this document for > reach desired certificate”. > > The operator configures or extracts from the router the BGP RouterID > > RFC4271 and RFC8209 say “BGP Identifier”. OSPF uses RouterID, and lots of > C/J commands use RouterID, or router-id, or router id, or RID, or . . . But > consistency with the referenced specs would a good thing. > > p4, section 5 > > I think it would be great to add a sentence here explaining that the PKCS#10 > (CSR) format does not include the AS and RouterID (sic). Therefore, the > operator must transmit the AS and RouterID (sic) as well when it sends the > CSR to the CA. > > That sentence applies to both the router generated keys and the operator > generated keys, so maybe it could go here. > > The PKCS#10 format does not include the AS and RouterID for the router > certificate. Therefore, the operator must include the AS it has chosen for > the router and the RouterID when it sends the CSR to the RPKI CA. > > That should be a MUST, shouldn’t it? > > p5, section 5.1 > > The operator adds the chosen AS number and the RouterID to send to > the RPKI CA for the CA to certify. > > My first reading was that the text meant the AS and RouterID were added to > the CSR. First, that’s not possible because of the signature, unless there’s > some key sharing going on. Second, that’s not possible because the CSR > format does not include the AS and RouterID. Hence my comment above. > > suggest: > > The operator includes the chosen AS number and the RouterID when it sends > the CSR to > > p4, section 5.1 (nit) > > NOTE: If a router was to communicate directly with a CA to have the > > suggest: > > NOTE: If a router were to communicate directly with a CA to have the > > p5, section 5.2 > > and adds the chosen AS number and RouterID to be sent to the RPKI CA > for the CA to certify. > > suggest: > > and includes the chosen AS number and the RouterID when it sends the CSR to > the RPKI CA > for the CA to certify. > > p5, section 5.2.1 > > section title “Using PKCS#8 to Transfer Public Key” > > PKCS#8 in RFC5958 can transfer public keys. But the following text is > talking about transferring the private key to the router. > > I think this title should be “Using PKCS#8 to Transfer Private Key” > > > A private key encapsulated in a PKCS #8 [RFC5958] should be further > encapsulated in Cryptographic Message Syntax (CMS) SignedData > [RFC5652] and signed with the AS's End Entity (EE) private key. > > Would “A private key encapsulated in a PKCS #8” be followed by "OTOH, a > private key that is not encapsulated in a PKCS#8”? :-) > > Suggest: > > A private key can be encapsulated in a PKCS #8 [RFC5958] and should be > further > (or “is” encapsulated or “should be” encapsulated) > > Section 3 suggests various ways to “exchange PKI-related information with > routers”. Is this PKCS#8 just one more way, or is it the recommended way? > The intro to section 5 suggests that copy and paste could also be used, but > doesn’t say if that would be copy and paste of the PKCS#8. If Section 5 is > also talking about straight copy and paste of the hex or the PEM block, then > that’s another alternative. > > RFC5958 discusses several “CMS protecting content types” to protect the > AsymmetricKeyPackage. I presume that the encryption/enveloping content types > are not needed because confidentiality is being provided by the protected > channel. But then why use the CMS SignedData - would not the protected > channel provide the authentication and integrity needed? (But see potential > reason below) > > > [RFC5652] and signed with the AS's End Entity (EE) private key. > > Does it matter which AS’s EE cert the operator uses to sign the PKCS#8? I > presume that the AS must match an AS with which the router is configured. > Should the router check that? Does a router that is configured with multiple > ASs use this communication to tie the private key to the appropriate AS & > BGPsec session? > > If the answer is yes to both questions, should those actions be mentioned > here? > > (I admit to being a bit dizzy here, but maybe the mapping of private key to > AS happens in the receipt of the router certificate.) > > include in the SignedData the RPKI CA certificate and relevant AS's > EE certificate(s). > > Maybe this is the reason for using the SignedData - to be able to include the > AS’s EE cert and give the router the means to tie the private key to the > right AS. > > The router SHOULD verify the signature of the encapsulated PKCS#8 to > ensure the returned private key did in fact come from the operator, > > Then shouldn’t it be signed with the operator’s personal cert? :-) > > include in the SignedData the RPKI CA certificate and relevant AS's > EE certificate(s). > > Elsewhere (sections 6 & 7) it mentions including the entire cert chain. > Should that be mentioned here as well? > > p5, section 6 (nit) > > The operator uses RPKI management tools to communicate with the > global RPKI system to have the appropriate CA validate the PKCS#10 > request, sign the key in the PKCS#10 (i.e., certify it) and generated > PKCS#7 response, as well as publishing the certificate in the Global > RPKI. > > for symmetry, suggest: > > The operator uses RPKI management tools to communicate with the > global RPKI system to have the appropriate CA validate the PKCS#10 > request, sign the key in the PKCS#10 (i.e., certify it) and generate a > PKCS#7 response, as well as publish the certificate in the Global > RPKI. > > p5, section 6 > > External network connectivity may be needed if the certificate > is to be published in the Global RPKI. > > The previous sentence and the following paragraph do not hint that there is > any “if” about the publication of the certificate. Is there a case where the > certificate is NOT “to be published in the Global RPKI”? > > p6, section 6 (nit) > > 2. Returns the certificate to the operator's management station, > packaged in a PKCS#7 > > Needs a reference. RFC2315? > > In the operator-generated method, the operator SHOULD extract the > certificate from the PKCS#7, and verify that the private key it holds > corresponds to the returned public key. > > “it” means the operator, right? > > You get to Appendix B before the verification of the correspondence is > explained. I think it should be explained here. > > The Appendix B says the operator should verify the signature on the PKCS#10 > CSR to verify the correspondence. But the operator generated the key - can’t > the correspondence be verified by checking the certificate’s public key > against the operator generated public key (presuming the key was retained)? > That seems too easy - I fear I am missing some important part here. > > p6, section 7 > > The router SHOULD extract the certificate from the PKCS#7 and verify > that the public key corresponds to the stored private key. > > I think more needs to be said about how the correspondence would be verified. > > Appendix B says the operator should verify the signature on the PKCS#10 with > the certificate to verify the correspondence to the private key. That would > work for the router as well if the router generated the PKCS#10, but not if > the operator generated the key pair and the PKCS#10. But the router could > sign any random bunch of bits and verify the signature with the certificate > to verify the correspondence. Should those things be said? > > Also, in the router-driven method, the router can verify the correspondence > simply by matching the certificate’s public key with one of the router’s > stored public keys. (Right? What am I missing here?) > > Should the router also verify that the AS mentioned in the returned router > certificate is an AS with which it is configured? > > For a router that is configured with multiple ASs, is this where the router > ties the private key to the AS & BGPsec session with which the private key > should be used? > > The last two paragraphs of section 7 confuse me. > > 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]. > > What is “this signature”? And there’s been no mention in this section of > extracting the private key from the router. > > This sounds to me like it belongs in section 5.1, maybe after: > “to sign > the PKCS#10 with the private key. Once generated, the PKCS#10 is > returned to the operator over the protected channel. > > And then: > > 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. > > Maybe this belongs in section 5.2.1 where it is talking about the PKCS#8? > > Even so, I’m not sure what Certificate this text references. The AS EE cert? > > Both the router-driven method and the operator-driven method are not the > direct CA. Nowhere in this draft does it mention the CA generating the keys. > So the entire draft is one of these “advanced configurations”. What am I > missing here? > > p7, section 8 (nit) > > Transport" [RFC7030] or the original CMC transport protocol's > > Is the possessive really needed here? I didn’t peruse the RFC5273 > thoroughly, but I can see that it defines a number of transport methods, so > maybe there is a “CMC transport protocol’s X” missing here. > > p7, section 8 > > > This section uses “key material” several places. But I’m not certain each > use is talking about the same key material. > > When the operator first establishes a secure > communication channel between the management system and the router, > this pre-installed key material is used to authenticate the router. > > So the router gets keys as part of the manufacturing, where the > “pre-installed key material” can be used in communication with the operator. > > I can see that this might make it easier for the router to communicate > directly with the CA and authenticate itself using these keys. But section > 5.1 notes that the CA has no way to authenticate the router. I don’t know > that the pre-installed key material could provide that way to authenticate > the router, without the participation of the operator at some point. > > The operator burden shifts here to include: > > I’m not sure how to read this. Maybe “The operator burdens that shift here > can/will include”. > > I’m also not sure if both 1 and 2 are presumed to be shifted/lifted, or if it > is either. > > > 1. Securely communicating the router's authentication material to > 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 RouterID as well as > the router's key material, but can also include additional > information. Authentication material can be communicated to the > CA (i.e., CSRs signed by this key material are issued > certificates with this AS and RouterID) or to the router (i.e., > the operator uses the vendor-supplied management interface to > include the AS number and routerID in the router-generated CSR). > > Who is doing the communicating in “securely communicating to the CA” and “can > be communicated to the CA”? In the following paragraph, the text says “the > router is communicating directly with the CA” - is the communication in this > part 1 text going from the router to the CA? > > What is the “router’s key material”? I could read it both ways: > > The paragraph above says that the pre-installed key material is used to > authenticate the router, so maybe the “router’s key material” is the > pre-installed key material. The text says that the CA “uses” the > authentication material, which includes the router’s key material, to > determine whether to issue the certificate. I don’t know how the > pre-installed key material could assure the CA that the router could be > issued a cert, without some coordination with the operator about that > particular key material. > > Then the text says “CSRs signed by this key material” which implies that the > “router’s key material” is the public/private key pair. > > So I’m not certain what is going on here, or how the pre-installed key > material is helping. > > > Once configured, the operator can begin the process of enrolling the > router. > > What does “once configured” mean? configuring the router-operator protected > channel? Doing the communication of authentication material in 1 and 2 > above? Configuring the router with AS and RouterID? > > Because the router is communicating directly with the CA, > there is no need for the operator to retrieve the PKCS#10 from the > router or return the PKCS#7 to the router as in Section 6. Note that > the checks performed by the router, > > Section 5 says the router returns the PKCS#10 to the operator. > Section 7 says the operator sends the PKCS#7 to the router and the router > performs checks. > > suggest: > > Because the router is communicating directly with the CA, > there is no need for the operator to retrieve the PKCS#10 from the > router as in Section 5 or return the PKCS#7 to the router as in Section 7. > Note that > the checks performed by the router in Section 7, > > When a router is so configured the communication with the CA SHOULD > be automatically re-established > > what does “so configured” mean here? configured with pre-installed key > material? configured by the operator with AS and RouterID? > > p8, section 9.1 (nit) > > just for symmetry: > > 4. Use some other kind of automated process to search for and track > > suggest: > > 4. The operator uses some other kind of automated process to search for > and track > > p8, section 9.1 > > Regardless of the technique used to track router certificate expiry > times, it is advisable to notify additional operators in the same > organization > > “notify additional operators” — In addition to what? or after what? > > I think you mean “multiple” operators, or I misunderstand. > > p9, section 9.3 (nits) > > certificate to the router), and distributing the status takes time > > Not sure what you mean by “status” that needs to be distributed. Are you > talking about distributing the revocation “status” in the CRL? > > Keeping the router operational and BGPsec-speaking is the ideal goal, > but if operational practices do not allow this then reconfiguring the > router to disabling BGPsec is likely preferred to bringing the router > offline. > > suggest: > > router to disable BGPsec is likely preferred to bringing the router > > p10, section 9.4 > > 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 inserted via a > protected session, 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 topic here is routers that won’t allow off-loading of their keys. > > “routers SHOULD allow the private BGPsec key to inserted” > > is the router that is doing the allowing the old, soon to be replaced > routers, or the newly installed routers? > > “to <be> inserted” - where? - in the newly installed router or in the > management station? > > “This lets the operator escrow the old private key” - sounds like the old > router is allowing the private key to be “inserted in” (exported to?) the > management station. Right? > > Is there a suggestion of how to get the routers to allow export of the key, > which is currently not allowed? > > I don’t see that section 5.2 says anything about a mechanism for escrowing > keys. It talks about installing a private key into a router over the > protected channel. If the citation to 5.2 is about the “such that it can be > re-inserted” part of the sentence, then I get it. But the citation should > move to the end of the sentence. > > p10, section 10 (nit) > > After > familiarizing one's self with the capabilities of the router, > operators are encouraged > > suggest: > > After > familiarizing themselves with the capabilities of the router, > operators are encouraged > > > or > > After > familiarizing one's self with the capabilities of the router, > an operator is encouraged > > p11, section 10 (nit) > > employees that no longer need access to > routers SHOULD be removed the router > > suggest > > employees that no longer need access to > a router SHOULD be removed from the router > > or > > employees that no longer need access to > a router SHOULD be removed from the router access [list] > > p11, section 10 (nit) > > The > operator MUST ensure that installed CA certificate is valid. > > suggest: > > The > operator MUST ensure that the installed CA certificate is valid. > > p14, section Appendix A > > x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for > authentication. > > is that an example, or a recommendation? > > p15, section Appendix B (nit) > > that will generate the key pair for the algorithms noted in the main > body of this document; > > the algorithms are not noted in the main body, but the end of section 1 does > cite RFC8208. > > the private key just generated to sign the certification request with > the algorithms specified in the main body of this document; > > the algorithms are not specified in the main body, but the end of section 1 > does cite RFC8208. > > p16, Appendix B > > Uses of “serial number”: > > the subject name and serial number for the router. The CA needs this > and > CSR you sent; the certificate will include the subject name, serial > number, public key, and other fields > and > Create CSR and sign CSR with private key, and; o Step 3: Send CSR > file with the subject name and serial number to CA. > > The first of these seem to mean the BGP Identifier aka RouterID. As said > before, RFC4271 and RFC8209 use the term BGP Identifier. > > The second and third use of “serial number” probably also mean BGP Identifier > aka RouterID (not the issued cert’s serial number). > > p17, section Appendix B (typo nit) > > way through GPsec-enabling the router. > > suggest: > > way through BGPsec-enabling the router. > > p17, section Appendix B > > To avoid having routers with expired certificates > follow the recommendations in the Certification Policy (CP) [RFC6484] > > you could also mention section 9.1. > > > > > >> On Nov 14, 2017, at 10:36 AM, Sandra Murphy <sa...@tislabs.com> wrote: >> >> >> >> Sorry, the reply did not pick up the original attachment. >> >> Attached here. >> >> Let me know if there are problems reading the comments. >> >> —Sandy >> >> <draft-ietf-sidr-rtr-keying-14.mycomments.rtf> >> >>> On Nov 14, 2017, at 10:33 AM, Sandra Murphy <sa...@tislabs.com> wrote: >>> >>> Speaking as wg co-chair >>> >>> Please, wg, do take a look at the comments attached. This draft was >>> requested by the operators and is important. >>> >>> Some of the comments are about substance. Those at the very least must be >>> considered by the wg. >>> >>> Please take advantage of focused attention and close proximity at the IETF >>> meeting to discuss. >>> >>> I unfortunately can not be there to button hole people and shove printouts >>> into their hands. >>> >>> —Sandy, speaking as wg co-chair >>> >>>> On Nov 5, 2017, at 9:25 PM, Sandra Murphy <sa...@tislabs.com> wrote: >>>> >>>> I’m attaching some comments and questions I found in the -14 version. >>>> >>>> —Sandy >>>> >>>> <draft-ietf-sidr-rtr-keying-14.mycomments.rtf> >>>> >>>>> On Oct 20, 2017, at 1:04 PM, Sean Turner <s...@sn3rd.com> wrote: >>>>> >>>>> Chris, >>>>> >>>>> This version includes changes to address Oliver’s and Sriram’s comments. >>>>> >>>>> spt >>>>> >>>>>> On Oct 20, 2017, at 13:02, internet-dra...@ietf.org wrote: >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Secure Inter-Domain Routing WG of the >>>>>> IETF. >>>>>> >>>>>> Title : Router Keying for BGPsec >>>>>> Authors : Randy Bush >>>>>> Sean Turner >>>>>> Keyur Patel >>>>>> Filename : draft-ietf-sidr-rtr-keying-14.txt >>>>>> Pages : 17 >>>>>> Date : 2017-10-20 >>>>>> >>>>>> 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 IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >>>>>> >>>>>> There are also htmlized versions available at: >>>>>> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-14 >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-14 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-14 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> i-d-annou...@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> _______________________________________________ >>>>> sidr mailing list >>>>> sidr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sidr >>>> >> _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
