Re: [Gen-art] Gen-art LC/Telechat review of draft-ietf-sidr-usecases-05.txt

[Elwyn Davies <[e-mail]>]

Hi, Terry.

That's all fine by me.

Have a great Christmas!

Elwyn 

On Thu, 2012-12-20 at 17:02 -0800, Terry Manderson wrote:
> On 20/12/12 11:23 AM, "Elwyn Davies" <[e-mail]> 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