Sriram, Let me re-comment on some of the points.
(skip) >> >> Particularly, I was surprised that in your assessment for the PKR method you >> did not considered the points highlighted in section 4.2 of our draft >> (Advantages/Disadvantages). >> > > In your Section 4.2, you have proposed what looks like a hybrid of PKR and > EKR methods > (without using that specific taxonomy). We consider PKR and EKR as separate > design choices, > and hence discussed their pros/cons separately. But I think we have captured > many of > the same advantages/disadvantages you have outlined and some additional ones. > We are open to taking in comments and revising the document as needed; > so we will be happy to relook at that. (Roque) As expressed in our document, there are many reasons to do key rollover for BGPSEC certificates, just like in any PKI. Using your taxonomy, can we consider EKR as emergency rollovers due to a key been compromised, changes on the certificate information or local policies? In my mind, the only thing that we we need to care about is if we follow the periodic scheduled periodic rollover process or an emergency rollover. In general the difference between the two is that in the emergency case there may not be the time to wait for the RPKI process to propagate the information. > I have a question for you on your Section 4.2 regarding why you propose > to implement a hybrid of PKR and EKR. Let me take that up in a separate > thread. > (Roque) ok, I will take a look at that other email. >> >> 2) Your summary statement: "The Expire Time (ET) method is best" does not >> represent the WG consensus when our draft was accepted as WG item and when >> the timestamp field was removed from the Protocol Specification. >> > > We are fully mindful of the WG consensus and we are in no way promoting > the ET method in the document. You took a piece of the whole statement > and made it appear like that was the summary of our document. > The actual statement (in Section 7) in the document is as follows: > > "1. The Expire Time (ET) method is best (on par with the PKR method) > in terms of preventing huge update workloads during peering and > policy change events at transit routers with several peers. It > has no added RPKI churn. But the ET method has the disadvantage > of requiring on-the-wire protocol change if some parameters > (e.g., the units of beacon interval) change." > > The intent here was just to equate the ET and PKR methods in terms of update > workload. > We would change the first sentence (when revised) to read: > "The ET and PKR method are on par in terms of preventing huge update > workloads ......" (Roque) Again, the problem that the WG was concerned about when studying the ET value (and that was not covered in your document) was not the changes "on the wire" (although some discussion happened on who had control over the expiration time) but rather the changes on the BGP logic that has been around for decades. This point is not covered in your document. > >> >> IMHO, the problem with your comparison between ET and PKR is that you did >> not mentioned that implementing ET introduces important changes to current >> BGP implementations. The design decision is to either maintain states in >> every BGP speaker (having to allocate an expiration time to every update and >> needing to check if that time is old) vs increase the churn at the RPKI >> repository system and more admin processes in the RPKI. The group took the >> second path. >> > > It depends on how you see it. How would you keep track of the NotValidAfter > time > of update signatures (as determined by the NotValidAfter time of the > respective certs) > in the PKR method? If keeping track of this is done in the router, > then there is a need to maintain state even in the PKR method. OTOH, > if the RPKI cache server is sending a withdraw of the public key > when the cert's NotValidAfter time is reached, even then the BGP process > needs > to scan the update tables and prune out the ones that are affected. > I think that also implies changes to the current BGP implementations anyway. > However, we did observe that with the ET method we have the disadvantage > that the expire-time field is built into on-the-wire BGPSEC protocol > and that is not a desirable feature. (Roque) The need for the router (if the certificate signing requests are originated by the router) to keep track of the NotValidAfter time is ONLY for its own certificates. We covered this in our draft, particularly when we express as an advantage that the AS that wants to protect itself against a replay attacks pays most of the "Administrative cost" (Steve later corrected us that Relying Parties also pay a tax which will be included in our next release). Now, to keep track of the "NotValidAfter" time for the rest of the BGPSEC certificates you follow the traditional RPKI process: the caches fetch the repositories, if a certificate is not longer valid, they send a withdrawn to the routers for that SKI. The routers do not need to keep track of it because the cache will do it. Moreover, we mention in the draft that the automatic process to make this to work (certificate provisioning, changes to the RTR protocol and how a router should react to a SKI withdrawn message) are not yet documented but we worked under the assumption that it would be shortly. We understand that other members of the SIDR WG are working on this piece and that is why we did not cover it. >> >> 3) Your study of EKR is very bias because the effect of event-driven key >> rollovers will depends on the event that is driving that key rollover. >> Particularly, and putting it on the same words that our draft uses, in this >> particular case you are comparing a rollover of the "transit" certificate >> key vs a rollover of the "origin" certificate key. >> > > I think you are referring to slides 6-8 in > http://www.nist.gov/itl/antd/upload/replay-discussion.pdf > No, we are not comparing apples and oranges here. In these comparisons (see > slide 8), > we do not focus at all on the rollover of the "origin" certificate key. (Roque) Ok, so you are focussing on the "transit" certificate rollover. This means that this is a different discussion and has nothing to do with the re-play attack as the technique we are pushing forward to control the windows of exposure are periodic rollovers of "origin" certificates keys. Is the goal then to compare the router's behavior when dealing with periodic vs emergency rollovers? > That actually has a very minor impact on updates (as illustrated in slide 5) > and > we don't focus on that in the plot in slide 8. Instead, what we consider in > slides 6-8 is that > when the event occurs, in the PKR method no cert is rolled (by design). (Roque) I do not understand your comment " in the PKR method no cert is rolled (by design)". The transit certificate, as any PKI certificate, will need to be rollover due to two possible reasons: periodically (it has a long validity period but one day it will expire) and emergency (particularly key compromised). Now, in each of these cases, you need to perform a rollover process and you want to "do before break" (sometimes in emergency process you do not have this option and you break). > But even then a certain amount of BGPSEC updates would be propagated similar > to > what happens in conventional BGP-4. That is because the router will recompute > new best paths > for the prefixes affected by the event, and those updates need to be > propagated > even though no key has been rolled due to the event. > In some scenarios such as Scenario 1 in slide #6, no updates are generated in > PKR > under those circumstances. But in another scenario such as Scenario 2 in > slide #7, > a moderate burst of updates is generated in PKR (same number as in BGP-4). > However, in both scenarios, a huge burst of updates is generated in the EKR > method > due to the transit key rollover which causes all prefix routes to be > propagated > or re-propagated at that router. I hope this explanation helps. (Roque) Sorry but I am still confused. In my view an emergency or a periodic key rollover will have the same effect on the BGPSEC layer with the difference that in the emergency case you may not have the chance to wait for the RPKI information to be propagated and thus you risk that the new BGP UPDATES do not validate. > >> >> As you wrote in the document, when you rollover the transit certificate, you >> gain the possibility to refresh transit policies which is not the case with >> either ET or only rolling over the origin certificate key using PKR. But >> rolling over the transit certificate key should be very rare because of the >> reasons that you and us mention. >> > > I agree. > > Thank you once again for reading and commenting on the document. > > Regards, > Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
