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" <[email protected]> wrote: > 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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
