Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Brian Dickson <[e-mail]>]

On Fri, Oct 28, 2011 at 2:40 PM, Christopher Morrow
<[e-mail]> 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