On 18/11/2010, at 8:23 PM, Sandra Murphy wrote:
> (OK, so there *is* another one, making lucky 13.)
>
> Randy Bush has requested a WG LC for draft "BGP Prefix Origin
> Validation"
>
> The document and the draft version history are available at
> http://tools.ietf.org/wg/sidr/draft-ietf-sidr-pfx-validate.
>
> The Last Call will end Thu, 2 Dec 2010 (AOE).
>
> As usual, please address all comments to the WG mailing list, and
> please be clear in your comments to this last call if you are
> supporting the document's submission to the IESG or if you are
> opposed. If you are opposed, please indicate why.
>
I don't think this document is ready to head to the IESG.
By and large I agree with the observations and recommendations in this
document, but I don;t believe that this is ready for the IESG. More
wordsmithing for clarity and consistency is requires in my view (see below)
Also, one statement struck me as needing further commentary:
Section 5. Routing Policy
Announcements with invalid origins MAY be used, but SHOULD be less
preferred than those with valid or unknown.
Here I agree with the sentiment in terms of the relativity to valid or unknown,
but I am worried about the MAY statement here, and I would like the document to
explain this further.
For example, a simple reading of the document leads one to believe that all
announcements MAY still be accepted according to the routing policy selection
allowed in section 5, yet if that were the case then the ability of origin
validation to "deal with inadvertent mis-advertisement" is questionable.
I would prefer the document to look at the implication of _why_ a party MAY
accept a route that the origination validation framework is leading to a local
judgement that the route is invalid. i.e. is it because of missing information
in the relying party's local cache, which may bne resolved over time? Is is due
to potential circularity of dependence, where parts of the RPKI distributed
repository lie behind routes that can only be judged as valid using certs and
ROAs found in that repository?
I would also like to see the security considerations section include a
statement to the effect that if a party were to use routes that have an invalid
validity state then the ability to detect and filter certain forms of
mis-advertisement would in effect be negated.
Back to the wordsmithing and consistency comment, the terminology of
unvalidatable origins and unknown origin is used in different sentences - it
would be better to use consistent terminology.
It would also be good if the terminology of validity state is consistent - are
we talking about "announcements" or "routes"? Are we talking about "valid
origin" or "routes that are validated by the RPKI ROA framework"?
So close, but not quite ready for shipping yet in my opinion.
(My apologies - I should've commented earlier on this, but its only a WGLC that
leads to these reviews happening for me.)
thanks,
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
