On Fri, Oct 28, 2011 at 2:40 PM, Christopher Morrow <christopher.mor...@gmail.com> wrote: > Seems that the authors, at least, expect this doc to be prepared for > WGLC, could we do that concluding 11/11/11 please?
Sorry, didn't notice the date in the request. I do have some brief comments about a few bullet points. 3.17 says "no requiring revealing new inter-domain policy info". 3.21 says "don't infer anything regarding intent". 3.22 says "don't trust non-BGPsec markings across trust boundaries". e.g. communities. However (whether this has been acknowledged in the "threat" doc or not), one of the concerns is the ability of BGP speakers, and presumably this will include BGPsec speakers, to manipulate route attributes to attract traffic. Another concern is "route leaks" (which we may not all yet agree on either a definition of, or the scope of what is/isn't a "route leak"). It'd be a long proof to show this, but I believe it is the case that: - route path manipulation (outside of the "expected" paths) can only occur if "route-leak" capabilities exist, i.e. that "route-leaks" are not prevented via some BGPsec mechanisms. Suggestion: A BGPsec design MAY include elements designed to mitigate "route leaks". - (refuting 3.21) This may require marking intent. Suggested text: A BGPsec design MAY require explicit signaling of intent between neighbor ASes, and to "mark" in some limited form, that intent inside a (presumably mandatory) element of a BGPsec design (e.g. via a BGPsec path element). - (leads to negation of 3.17) It MAY be necessary to reveal some aspect of inter-domain policy which can already be accurately inferred via third-party data and tools -- specifically, and limited only, to customer/transit/peer. Additionally: - BGPsec design(s) SHOULD mark attributes used in path selection which are transitive, and MAY mark attributes used in path selection which are non-transitive. (This is necessary for 3.22 to apply and still avoid path manipulation occurring.) Brian _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
