Sandra Murphy wrote:
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.
Yes, specifically origin manipulation (which would be covered
by path manipulation)
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.
Not easier to manipulate the origin, just better results
from such techniques. If maxlength is used, but not
all the most specifics are actually announced, an attacker could
announce a more specific from the block that will
pass validation with a manipulated origin. Without a
maxlength, they can still manipulate the origin to validate, but
they are limited to announcing a prefix of the same length
as an existing announcement. Such attacks will likely be
considerably more limited in scope of impact than a more
specific of an existing announcement.
-Larry
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
