On Fri, Nov 4, 2011 at 12:49 AM, Christopher Morrow <[email protected]> wrote: > (coming in late to the party, weee!) > > On Wed, Nov 2, 2011 at 1:08 PM, Brian Dickson > <[email protected]> wrote: >>>> (5) If any BGP path attribute used in Path Selection is not signed, >>>> then BGPSEC has failed to meet its charter requirements. >>> >>> Then MED and Local Pref must also be signed, along with a number of >>> communities, and even the next hop. >> >> Yes. > > err, so... you receive a route update from AS1 at AS2, it looks roughly like: > 1.2.3.0/24 nh = 192.168.1.1 > this is signed (all of the above data) > > When you pass this route off to AS3 you do so as: > 1.2.3.0/24 nh = 10.1.1.1 > the nh changed, the sig originally is for 192.168.1.1 > > Did you really mean to sign the next-hop? it seems infeasible... > > Also, LocalPref is a locally used/determined/created (non-transitive) > item, adding that set of bits into the signature seems blatantly > wrong, since the data won't exist when you pass the route outside your > ASN the verification is going to fail, for every route you send (which > had a localpref != default), That CERTAINLY seems like something you > would want to avoid, right?
Er, on non-transitive items like LocalPref, there is a use case for signing them iff the iBGP elements are decided as being in-scope. (I agree with Danny on this being worth considering.) What we are discussing is the threat model, and how threats could be countered. This in turn is used to inform the design of the protocol, not vice versa. So, when I say "signed", what I was thinking of was something along the lines of a sequence of blocks that might look something like: LocalBGPPerHopData signature(LocalBGPPerHopData|previousSignature) and after all those blocks, originatorSignature(FirstHopData|RPKI-validatable-data) The stack gives a history of transitive and non-transitive values, some of which won't be used for local policy decisions per se, and some of which can quite reasonably have been changes at each hop. The signatures protect that data. How the protected data itself is used is local policy, for selecting best path. This is more information than vanilla BGP has, of course, but arguably allows for better path selection by virtue of more data being available locally. Note that nothing is present than is generally known through various data sources, including local BGP tables, looking glasses, routeviews/Renesys, traceroutes, whois, RADB/IRR, RIRs, reverse DNS etc. Adding this "stack" allows for other aspects of local policy to be marked into the path, including markers suitable for preventing route leaks. It also means that non-transitive values can magically become pseudo-transitive, presuming the cruft that permits constructing local policy can be made to understand the association between AS-path hops and the captured policy at those hops. (This is a feature, not a bug.) The signatures make it possible to reject changes to this stack of path-historical data. The data makes it possible to choose to use the originated values, the latest values, or anything in between, however one chooses. The requirements to continue adding to this stack ensures the next AS to which the prefix is sent, has the same opportunity to apply local policy. Add a dollop of 'transit/non-transit' at each hop (mandatory but arbitrary), and simple leak-blocking (nearly fool-proof, in fact) is possible to support. Brian _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
