On Mar 21, 2012, at 4:57 PM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil <[email protected]> > wrote: > >> How about we turn this around with a simple question: >> Suppose two different feasible paths are being evaluated for a single >> prefix/origin pair and one was delivered via a signed bgpsec update, and the >> other was delivered via an unsigned update. What >> annotations/influencers/considerations/etc. does the bgpsec design suggest >> when the router is making its path selection between these two? >> > > ideall, I think, the process is something like: > 1) first path gets evaluated, is it 'good' (next-hop reachable, not > discarded by prefix-list/etc) > 2) second path gets evaluated, is it 'good' (same as above + > origin-validate + path-validation) > > If both 1 and 2 come out 'ok', assume each path was received from a > different peer on the same device: > 1) 1 - 2 - 701 - you > 2) 1 - 3 - 7018 - you > > If you decide that your network's policy is 'prefer signed and valid > over unsigned' paths, you'd pick #2. It could be that your method of > doing this is saying: > route-map inbound-bgp permit 10 > if route-signed and verified > set localpref 100 > > Which ideally would let localpref on the #1 route stay normal == 80 > and magically you'd just use the 'right' (from your perspective) path. > (signed and verified). > > of course, in the beginning of this you may choose a more conservative: > route-map inbound-bgp permit 10 > if route-signed and verified > set community you:verified > > so you could measure the deployment state of your customers + > rest-o-interwebs. > > In the end, I think 'bgpsec suggests' that the operator would make > some decision... ideally the same decision across the network. > > does that make sense? (the policy is deliberately short and simple, > obviously real policy is longer/stranger, but the end result is the > same)
Indeed, this makes sense, thanks for the detailed response. However, this also illustrates an evolution of semantics under non-attack circumstances. :) Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
