On 20/12/12 11:23 AM, "Elwyn Davies" <[email protected]> wrote:
> Hi, Terry. > > Thanks for the swift reply. > > Looks like all is well with most of he comments. > > I guess the main consclusion would be that you maybe need to put in a > bit more explanation of the context to which make-before-break applies > as per your explanation to me below. I hear you, I will come back to you after Xmas with some expanded draft text for s2.1. > >>> It is possible that I don't understand the problem, but this appears to >>> be trying to prove a negative by the existence of something. What RPKI >>> object would have to exist to make the route suspicious? >> >> Essentially a valid RPKI ROA object would need to exist that proves a route >> is suspicious. Because the RPKI+ROA is a "bolt on after the fact" security >> effort, you can do no more. Simply routing exists now, the RPKI would be >> deployed in the future. So any route that is seen must be considered >> intended unless proven otherwise. > I see now.. perhaps you could add something like: > ... valid RPKI object that explicitly invalidates the route (see Section > 7 for examples). That works for me. >> >>> >>> s6.2: Can the make-before-break principle be applied to the resource >>> certificate for Org B? Presumably this would mean overlapping existence >>> of resource certs for Org A and Org B so that the ROA add can occur >>> before the revoke. Is this a problem? >>> >> >> The preference, I believe (and my co-authors can correct me) is that two >> different resource certificates (unless one in subordinate to the other) >> should never exist. >> >> This problem is an open issue in SIDR related to the grandfathering topic. >> So for now the usecase should be that overlap cannot occur. > Do you think this needs explicit mention? No. I feel it is better to remain silent in the usecases. A requirements document (should one ever be set as a charter deliverable) would define that behaviour, which would then be reinforced by the RPKI architecture. I personally feel it is better to bis this document should change be needed. >> work for you? > > Maybe 'through two or more' but basically 'yes, thanks'. Works for me. >> >>> describe the add before the revoke in each case? >> >> ahh.. I think we have a disconnect. make before break is considered in the >> routing sense that a route is considered o.k. (UNKNOWN) unless proven >> otherwise, this means you can remove ALL RPKI object for a route, and it >> will still exist happily until a new and conflicting RPKI ROA is created.. >> And we are working to that. Not necessarily making a new valid object before >> breaking the old valid object. That would then imply ownership of a prefix >> can then be in two places at the same time. And like the transfer of title >> for a house, overlap tends to be considered a bad thing. (co-authors, chime >> in here!) >> > See initial comment.. this is a useful explanation and some words to > this effect would avoid others with equally bad understanding of the > RPKI scenario making the same mistake. > Ack. Will run draft text past co-authors and bring back post xmas. Terry
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
