> yup... no-export/advertise were taken as 'advisory' communities that > networks MAY heed, but certainly weren't bound to do so.
>From what's been said on the list in the last several days, however, isn't it true that even the signatures are "advisory?" There is an insistence that local policy overrules the signatures --so all the entire SIDR effort is doing is providing more information on which to act. Why wouldn't signing communities be providing more information on which to act, as well? How can we say that providing more information on which to at is legitimate in the one case (that the receiver isn't bound by the information provided, but it is good information to have), and yet in the second case argue that because no-one is bound to act on the information, we shouldn't provide it? > I suppose documenting: "One leak scenario is <see id name>" is a fine > thing, does it help to actually fix the problem though? I think what I > heard in the meeting and on the thread(s) here was: "Sure leaks are > important, there's not a way devised so far that distinguishes a > 'leak' route from a 'normal' route, more than 1 as-hop from the > 'source' of the leak. > > In the id/draft: > > isp1 isp2 - me > \ / > AS1 > > I can't tell at 'me' that the route I see is a 'leak', just that I see > an as-path that is isp1-as1-isp2. There is a way to tell --you simply have to have ISP1 and ISP2 advertise through some mechanism that AS1 is not a transit peer. You can either add this information into BGP itself, through a community or some other attribute --but note that BGP wasn't designed to do this, and you're trusting AS1 to pass along the information that's it's not a transit peer when trying to act as a transit peer (a bit pathological, IMHO), or you must do so out of band. There are out of band solutions available, but the insistence that no-one ever advertise their intent has blocked all such out of band options. Not everyone might object to advertising their intent --and building a system that doesn't allow the advertisement of policy to appease the few that do object appears to be backwards from the way business should be done. Operators should be given the ability to trade off between additional security and "privacy." :-) Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
