On Tue, Nov 22, 2011 at 8:45 AM, Randy Bush <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/sidr
