Re: [sidr] Route Leak fix: V free routing

["Montgomery, Douglas" <[e-mail]>]

On 11/22/11 8:45 AM, "Randy Bush" <[e-mail]> wrote:

>> These ideas have floated around for 20+ years.  They have even appeared
>>in
>> early BGP specs ... See "LINK TYPE" in
>>http://www.ietf.org/rfc/rfc1105.txt.
>> 
>> I actually think this is a useful idea, but the discussion always rat
>> holes in the supposition of absolute filtering rules and proof by
>>counter
>> examples.
>> 
>> I think it would be simple for transmitters to indicate and sign their
>> view of the peering relationship they are sending an update over.
>> Customer, provider, peer, or unspecified.
>> 
>> (where/how you encode this is a detail, I would suggest in the PATH SIG
>> unless we decide to take on the more general approach below).
>> 
>> What receivers do with that information ... Just like validation state,
>> would be a matter of local policy.
>> 
>> Worse case is everyone chooses unspecified and we waste two bits under
>>the
>> signature.
>> 
>> Best case for those who don't care about declaring who their
>> customers/providers are to their customers/providers .... Then receivers
>> can choose to filter "V" routes if they wish.
>
>[ thanks for the only actual constructive hint i have seen on this list
>  for a while.  being still on travel and very time constrained, i have
>  started just hitting delete to the repeat blather from the failed
>  rpsec wg. ]
>
>do you expect it to be covered by the signature?  if so, then the
>business relationship is published globally.  do you see a way to assure
>veracity and non-repudiation while not exposing globally?
>
>Randy

I think the exposure thing is a red herring.

Yes I expect it to be covered by a signature.

It will travel by BGP as far as the update travels, to exactly the same
set of players.   So that set of folks already know you have a peering
relationship, I suspect they can figure out what the effective
relationship is, if they care, with a little analysis already.

Of course collectors might capture the update ... Just as they do now
revealing the peering existence.

Concerned about that?   I would like to understand how the exposure is any
greater than just sending the update today?

Still if you are concerned, set the relationship to "unspecified".

It is just a low cost tool.    I think one of our great mistakes is trying
to engineering what the end use cases will be for some of these
mechanisms.   I contend we have little idea exactly how all of this will
play out.   Providing a low cost mechanism that would allow interested
communities to address these forms of "leaks" .... especially if we don't
mandate that everyone has to either (a) reveal the relationship (I.e.,
unspecified) or (B) enforce any policy relative to it (e.g., drop "V") ...
Seems pretty harmless.

If 20 years for now 99% of the peering hops in AS_PATHS are "unspecified"
... We hashed and extra byte for nothing ... A risk I would be willing to
take.

I will note that all previous attempts at this (there was another interim
BGP spec years later that proposed a partial ordering among confederations
that imposed similar no-"V" properties, I could not find a stable
reference to that idea) suggested that it was an fixed property of the
peering relationship.

I will note that, so far, BGPSEC is 1 NLRI per update.  While I am not
suggesting sane reasons to do so, one might envision that some prefixes I
might transmit with "unspecified" while others I might not.


As far as veracity and non-repudiation .... I am setting a flag in an
update, not attesting to a contract.   The main (only?) use of which is to
suggest that you don't want your customers to transit the Internet through
you ... Nothing about that needs to be proved other than I set it.

Maybe I see an emotional issue here ... What if the bits were call "no
export to providers", "no export to peers", "unspecified", "free
distribution"... i.e., this is not a declaration of a contractual status,
it is a request by a transmitter to limit the distribution of an update
potentially multi-hops down stream.   I set this if I care, or think it
would be a public service, to constrain the flow of this update.  Mind you
this naming conveys that it is the transmitter who is trying to effect
policy, not the receiver.

The difference in having this under the PATH SIG is my preferences remain
with the update, unless someone strips the whole sig.

Once again, if receivers care about any of this, they would write policies
to implement their concerns ... Just as they will have to to react to the
validation state itself.

dougm



>