On 3/31/11 4:51 AM, Robert Raszuk wrote:
Hi,
If I am not mistaken there was a Randy's comment today at the mic
indicating that an AS may consider a path origin validation as INVALID
as compared to the peering AS just because the "RPKI may not be
synchronized"
Is this at all possible ? Doesn't RPKI already have been enhanced
sufficiently to avoid mis-detections even in the AS migration cases ?
Otherwise if this is a valid comment and if due to issues with RPKI
sync ASes will even transiently be subject to wrong classifications of
legitimate incoming paths I think there is a much bigger issue to
worry about.
Many thx,
R.
If you think about the concatenated timing cycles of RPKI repository
publication, polling intervals of validating caches, and notification
intervals between caches and routers it is clear there will be
(hopefully transient) incidents of RPKI state skew across the global
net ... and in particular in the context of this draft, two neighboring
eBGP speakers. Of course, beyond the timing effects of normal
operations, reboots etc of routers/cache's/repositories could also cause
these transients.
When A sends and announcement to B, that B thinks has an invalid origin,
it is not clear if it is A or B who has a stale view of the global RPKI
(maybe A has not rsync'ed a recent CRL) or maybe they have a consistent
view, it is just the case that A implements a policy that does not
preclude selection of routes with invalid origins (e.g., it implements a
preference for valid origins vs a policy that ignores invalid routes).
While I am very supportive of the need for new diagnostics for BGP
routing w/ ROA/RPKI processing there are some details of the draft that
need some clarification.
1. As was pointed out at the mic, there is no way in the protocol to
know if your peer has even tried to implement RPKI/ROA validation.
While one could question if they would implement this new capability
before they implemented ROA processing, you should address (a) if you
will blindly send these messages to such a router, or (b) have some way
of using the query feature to decide if you should bother your neighbor
with these.
2. In the early days one might expect a few valid origins and ~300,000
unknows. While you note rate limiting these, one might recommend the
ability to choose which validation codes you send diagnostics for.
3. The ROA validation drafts recognize 3 potential results - valid,
invalid, unknown. Seems like your Method 1 validity codes should
follow this.
4. It is not clear that routers that follow the rpki/rtr model (i.e.,
don't have a full RPKI cache, but instead just a white list) will have
enough information to emit the reason codes specified for method 1
validity code 2 (i.e., invalid).
dougm
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
