On 2011-04-10 03:13, Geoff Huston wrote: > On 09/04/2011, at 10:34 PM, Brian E Carpenter wrote: > >> Please see attached review. >> >> <draft-ietf-sidr-roa-validation-10-carpenter.txt> > > > > Thanks Brian, > > I'm not sure as to the appropriate form of response, but let me respond to > the two minor issues you identified in this review (many thanks for the > review, by the way)
This is just fine... the gen-art archive is public, so replying here is on the record. >> 3. Applying Validation Outcomes to Route Selection > ... >> "valid" is to be preferred over >> "unknown", which is to be preferred over >> "invalid". > ... >> It is a matter of local routing policy as to the actions to be >> undertaken by a routing entity in processing those routes with >> "unknown" validity states. > > you commented that: > > That seems to leave open the possibility that an aggregated route (which > is by definition "unknown") would be rejected. Assuming that the various > separate routes that were aggregated together never reached this particular > router, the result would be a black hole. At the least, it seems that this > should be mentioned, even if it is an intentional possibility. > > But the next sentence in the document states: > > Due to considerations of partial use of > ROAs in heterogeneous environments, such as in the public Internet, > it is advised that local policy settings should not result in > "unknown" validity state outcomes being considered as sufficient > grounds to reject a route outright from further consideration as a > local "best" route. Yes, indeed, and all I was thinking of was adding a sentence here saying that the "unknown" category might include aggregates. It's a direct implication of the earlier text but I tend to assume that not all readers will notice all implications. > Also, given the current proposal in the IDR WG to deprecate the use > of AS Sets (and by implication deprecate the (rarely used if ever) > practice of proxy aggregation, I am unsure of the need to call out > proxy aggregation in this context. I won't get into that debate ;-) >> 5. Route Validation Lifetime >> >> The "lifetime" of a validation outcome refers to the time period >> during which the original validation outcome can be still applied. >> The implicit assumption here is that when the validation lifetime >> expires the routing object should be re-tested for validity. > > you commented that: > > OK, but shouldn't a previously "valid" route be downgraded to > "unknown" after the lifetime expires and until the validity has > been re-tested? > > Not necessarily. When a route is validated, the validation lifetime refers > to the validation time of the EE cert used to sign that ROA. When the > ROA is no longer valid the route should be re-tested for validity. It it > possible that there is another ROA that still validates the route, or in the > absence of the ROA that previously validated the route, the route may > be considered invalid (i.e. there is an AS 0 ROA still extant that encompasses > this prefix). For this reason the text specifically indicates that the > appropriate action is to retest the route for validity in the context of the > current local cache of valid ROAs. Yes, but I have no sense of the timing - would the time taken to revalidate the route leave a long enough gap for some kind of security exposure while an expired route was still marked as valid? Maybe I am worrying about nothing. > > > At this stage I am unsure if changes to the draft are warranted, as > I believe that the issues you highlight here are addressed in the > document as it stands. Sure, these were minor comments, unless your shepherd feels differently. Brian _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
