Re: [sidr] draft-dickson-sidr-route-leak-solns-01.txt

[DougM lists <[e-mail]>]

As noted a while back 
(http://www.ietf.org/mail-archive/web/sidr/current/msg03797.html 
<http://www.ietf.org/mail-archive/web/sidr/current/msg03797.html>)  we 
have been trying to add this to BGP for over 20 years (see RFC1105 - 
this was in BGP design at one point).   What always sends this straight 
into a rat hole are the exceptions cases.

In particular:

1. If the granularity of the labeling is the peering session, you will 
find that there are situations in which some routes need to be labeled 
differently than the rest.

* If you label individual updates, you at least have the flexibility to 
have exceptions per-peering session.

2. If you label updates - there will always be situations where someone 
does not want to reveal that relationship.

* The encoding must permit some updates to be unlabeled (or marked 
"undisclosed").

3. If you mandate the policy that MUST be enforced w/ these markings 
(e.g., valley free, no multi-hop plateaus, etc) there will always be 
exceptions.

* If you make the labeling of hops simply an input to local policy, 
receivers can decide what policies to implement with respect to the 
"shape" of the path.

If we avoid these rat holes, one could include such a feature w/ bounded 
risk,  time would tell how the mechanism is put to use in practice.

dougm

On 3/26/2012 8:09 AM, Randy Bush wrote:
> [ let me save mic time and just say what i said to the idr list ]
>
> i do not think this will fly in the long run, but let my try to at least
> get it in the best light.
>
>    o it could and should be said in a page or so in order that people can
>      get it and think it is simple and not imposing
>
>    o it assumes gao-rexford, which we know is an unsafe assumption, but
>      wtf, it's good in enough cases that we can let it go for the moment
>
>    o the relationship has to be per prefix not per link, as prefixes with
>      different business models are often sent over the same link
>
>    o the mark should be determined by the sender, and need not agree with
>      the receiver's perception of the relationship
>
>    o if the receiver does not like it they can call the sender on the
>      phone, drop the announcement, whatever
>
>    o this is a significant change to bgp, so idr should be asked to say
>      it's cool before sidr tries to protect it by signing over it
>
>    o if it is agreed by idr and it is well defined, we know how to sign
>      it in bgpsec, it's like a few more bits on each hop in the as path
>
>    o as with origin validation and path validation, the router should not
>      do anything on its own, but rather should provide the operator the
>      tools needed to apply policy based on the data
>
>    o therefore, to use it, the router will have to give the operator some
>      sort of expression over the catenation of the per-as policy markings
>
>    o but what should an operator do when they see a 'violation' six hops
>      away?
>
> randy
>
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr