Sriram, Kotikalapudi wrote:
If some people preferred to see a pdf version of my long first (initial)
posting on this topic, here is a link for that:
http://www.antd.nist.gov/~ksriram/Prefix_Origin_UseCases.pdf
Now to Larry's question:
Thanks, Larry, for your comments.
I will think about you suggestion about use cases for differentiating
small scale peering vs. large-scale peering,
and also discuss it with my co-authors.
We will report if we can come up with something.
I would also like to speak to you about this at the IETF if you plan to attend.
Yes, I will be there.
Regarding the maxlength issue,
I consider the use of
maxlength to be potentially dangerous (where the full set
of most specifics are not announced)
I have question for you.
When YouTube prefix was hijacked,
it had to announce /24s and then /25s out of its
aggregate /22 in order to recover the traffic.
If YouTube registers a ROA with only the /22 and no maxlength,
then even its own updates with the more-specifics for recovering
the traffic (under hijack) would be dropped.
If maxlength is not specified, how do you envision
a solution for this?
Yes, I've considered this as a possible argument to using
maxlength. And I do see some validity to it in limited or
partial deployment scenarios of ROA's. However, you failed to point
out that Pakistan Telecom was announcing a /24 more specific out of
the /22 aggregate. And this is the main reason why it was
so successful. The reason for the /25's being announced by
Youtube was to combat Pakistan Telecom's /24.
I think the case study helps prove my point if you think about
the reverse situation. Namely, that if Pakistan Telecom had been
limited to announcing a /22 by a ROA with maxlength 22, they
would have likely had more limited success since they would
have been competing against the existing /22 from Youtube.
Just as Youtube had problems overcoming Pakistan Telecom's
/24 with it's own /24 announcement (and ended up using /25's), you can
imagine that Pakistan Telecom would have had limited
effect if it had been limited to announcing a /22 against
Youtube's existing /22 announcement.
-Larry
Sriram
-----Original Message-----
From: Larry Blunk [mailto:[email protected]]
Sent: Thursday, March 18, 2010 11:33 AM
To: Sriram, Kotikalapudi
Cc: [email protected]
Subject: Re: [sidr] Prefix-Origin Validation Use Cases
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
