On Thu, 18 Mar 2010, Larry Blunk wrote:
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.
That's an interesting statement. If you can substantiate security
concerns arising from having a maxlength in the ROA, please do document it
as quickly as possible. Please. ASAP.
Do you really mean "hijacking via path manipulation" not "hijacking via
origin manipulation"? The sidr wg is not working on path validation at
this time, we are working on origin authorization only. So such a comment
might not require a fix to the current documents.
But if you can see that a ROA with a maxlength might make it easier for
someone to manipulate the remainder of the path somehow, I for one would
be interested to hear, anyway.
--Sandy
-Larry Blunk
Merit Network
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
