Hello, It is from 2007 but may still be relevant to this work :-) http://thomas.mangin.com/data/pdf/LINX%2057%20-%20Mangin%20-%20BGP%20Leak.pdf
IMHO, any solution should allow to implement the solutions presented but more easily. Thomas On 26 Jul 2014, at 18:14, Doug Montgomery <[email protected]> wrote: > What seems necessary to address the set of problems we examined is the > ability to: > > 1. Tag additional semantics for an individual announcement who's meaning is > globally known. > > 2. To have these tags be transitive, remaining on the route end to end (not > just one hop). > > 3. In speaking to operators who were concerned about intentional leaks of > routes to critical infrastructure, it seems that the tags should be secured > so that a party anyone where on the net could verify which AS added the tag > on transmission to specific peer, and verify if a tag had be modified or > stripped in transit. > > It did not appear to us that this was achievable with current community > mechanisms. One could easily implement such semantics through some new > variant of community+protections, but it did not seem the current mechanism > addressed what we perceived as the requirements. > > dougm > > > > > On Fri, Jul 25, 2014 at 3:12 PM, Tony Tauber <[email protected]> wrote: > How is this different than tagging with communities today? > In either case, the provider's correct action on the semantics is needed (and > can go awry through misconfiguration). > > Tony > > On Fri, Jul 25, 2014 at 1:40 PM, Doug Montgomery <[email protected]> wrote: > The last point that Sriram made is important to the higher level discussion > of the problem. > > Semantically what we are proposing is that a BGP speaker can ad a semantic > tag to a route that describes restrictions on the intent of the authorization > that is implicit in sending a peer a BGP route. > > Note that the one tag we suggested was not "DOWN" or "CUSTOMER" it was the > intent that the sender expects that you will not redistribute this update to > transit providers. > > "I am sending you this route, but I do not wish it propagated to your > providers" > > So discussing the semantics of the tag: what that tag applies to (e.g., > specific route, vs peering session), what the tags attempt to signal, what > the security properties of such a tag should be, and what policies might one > build using such tags ... is the important part. > > The specific encoding proposed was the result of one attempt to think through > these issues ... but not all the thoughts made it into the draft. > > > > dougm > -- > DougM at Work > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > > > > > > -- > DougM at Work > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
