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. 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? 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
