Hey Chris, On Mar 21, 2012, at 5:06 PM, Christopher Morrow wrote:
> On Wed, Mar 21, 2012 at 5:04 PM, Eric Osterweil <[email protected]> > wrote: >> >> 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. :) > > expand please. Sure, there is now a new element in the BGP update (the sig(s)) whose presence, nature, or absence causes the interpretation of the update to differ. While I still disagree with the earlier caveat that all bets are off during an attack, that statement clearly does cover this case where one update simply isn't signed. That's what I meant, though I didn't mean to be cavalier when I said it before... Sorry if it came off as a barb. :) Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
