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

That's like making the British drive on the right: you can not incrementally deploy.

--
Jakob Heitz.

On Nov 22, 2011, at 8:51 AM, "Brian Dickson" <brian.peter.dickson@gmail.com> wrote:

> On Tue, Nov 22, 2011 at 8:45 AM, Randy Bush <randy@psg.com> wrote:
> 
>> 
>> 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?
> 
> I see a way...
> 
> [I'm assuming here, that the the places where business relation ships
> need to be possible to hide, are only where there is the potential for
> that hiding to have some effect:
> 
> - Transit providers know the relationship they have with their
> customers, and their customers' customers...
> - Peers expect to only hear their peers' customers (and customers' customers)
> - (Leaving aside "special" arrangements)
> - The only place where any announcement of non-customer routes occurs
> is from transit to customer
> 
> end assumption]
> 
> What is needed, is a separate signature chain, "provenance".
> 
> The provenance chain is required ONLY when sending a customer prefix
> to a non-customer.
> 
> The provenance chain consists of signatures over (the current "apex"
> bit + previous signature)
> The apex bit is either zero (on customer->transit AS path hops), or
> one (peer->peer).
> 
> Once received from a peer or transit provider, and validated (if
> present), the provenance chain MAY be stripped from the prefix.
> 
> If a prefix has no provenance chain, it is to be treated as if it has
> at least one apex bit set.
> 
> Transit providers SHOULD reject any prefix from a customer, if any
> "apex" bit is set (or if there is no provenance chain).
> 
> Peers SHOULD reject a prefix from a peer, which has no provenance
> chain, or has a provenance chain with the "apex" bit set anywhere
> except on the peers' entry on the chain.
> 
> Note that the vast majority of prefixes received by any AS, will be
> non-customers' and can have their provenance chains removed. This
> significantly reduces the impact of another set of signatures.
> 
> The absence of a provenance chain achieves the hiding of business relationships.
> 
> The absence of a provenance chain also permits the receiver of routes
> to detect and stop leaked prefixes.
> 
> This mechanism would be applied on a prefix basis, not blindly on an
> neighbor AS basis, although it would require knowledge of the
> relationship with the neighbor to function correctly.
> 
> I think this meets all Randy's requirements, as well as Danny's.
> 
> Brian
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr