Sriram, Kotikalapudi wrote:
The uses cases listed below pertain to {Prefix, Orgin} validation,
and are not yet included in draft-manderson-sidr-usecases-01
http://tools.ietf.org/html/draft-manderson-sidr-usecases-01
We plan to include them in the next updated revision (as a SIDR WG draft) which we
(Terry, myself, Russ) expect to submit soon.
Your comments are requested.
These use cases try to systematically enumerate the situations a relying party may encounter while receiving a BGP update and making use of ROA information to interpret the validity of the prefix-origin information in the update. We systematically enumerate the situations or scenarios but do not make a final recommendation on any RPKI interpretation at this point. We have included some comments on plausible RPKI recommendations. However, it is fully acknowledged that these recommended RPKI interpretations can be overridden by ISP’s local policy. It would generally be up to an ISP to make choices regarding the interpretation or decision, based on various considerations, including their view of “Partial Deployment”, “Full Deployment” of RPKI, etc.
I'd like to see some mention of scenarios involving customer
sessions/small scale peering vs. large-scale peering.
Providers may likely wish to have more stringent
enforcement on customer sessions where the lack of covering ROA
for a prefix is treated as an invalid announcment. Much as
those providers who use IRR based filtering do today. I believe
this will also help improve deployment.
I've also mentioned in the past that I consider the use of
maxlength to be potentially dangerous (where the full set
of most specifics are not announced) in that I believe it
makes hijacking via path manipulation easier. Don't know
if that bears mention in this document or perhaps a new one.
I'd be willing to write something up if it would be helpful.
-Larry Blunk
Merit Network
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
