I think that is more or less right. --John
On Feb 25, 2011, at 4:29 PM, Joel M. Halpern wrote: > Let me try phrasing the issue differently. I may still be missing the point, > from all sides. > > I believe that what is actually wanted is primarily: > o To prevent any advertiser from sending an advertisement that would cause > other properly behaving parties to send traffic iin a way that they are not > "entitled" to cause > > As secondary matter > o We want such attempted subversion to be visible at more than one hop > because experience tells us that not everyone deploys the tools properly, and > thus we can not count on every honest player doing their job well. > > (Colluding subverting players is addressed only to the degree that it is > covered by what we are after, not explicitly. We are staying away from > Byzantine Generals.) > > The above probably needs more wordsmithing, but is a problem statement that > does not assume that packets follow their advertisements, nor that any party > can control what any other party actually does. It also avoids getting into > the question of the accuracy of the reflection of the path of the > advertisement, the AS path in the advertisement, and the actual packet flow. > Instead, it focuses on an attack we are trying to prevent. > I believe that the primary solutions on the table are all solutions that can > be reasonably considered to address the problem as stated. (I.e. I am not > trying to change the solutions pace, only to clarify the problem space.) > > Apologies if I am still completely confused. > Yours, > Joel > > On 2/25/2011 9:14 AM, John Scudder wrote: >> On Feb 25, 2011, at 4:10 PM, Russ White wrote: >>>>> Can you explain the difference in some other way that doesn't mix the >>>>> two ideas? >>>> >>>> Since after reading your message carefully three times I don't understand >>>> your question, I'm unable to answer it. Sorry. >>> >>> You're apparently trying to separate the idea of proving an update >>> traveled a specific path from the idea of using this information to >>> actually filter or determine any other policy. I don't see how you can >>> separate the two --can you explain how you can? >> >> If you can establish the former (that the route did travel across the path >> it said it did), that outcome can be used as input to policy. This is >> exactly analogous to draft-ietf-sidr-pfx-validate-01, BTW. >> >> Divide, conquer. A commonly used trick in computing. :-) >> >> --John >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
