On Wed, Mar 21, 2012 at 5:17 PM, Eric Osterweil <[email protected]> wrote: > 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. :) >
I didn't take it as a barb:) you seemed to have in mind a problem, you showed it above as well, i was curious what the problem was. You highlight a problem that, of course, looks to me like a dnssec sort of thing? "Hey, this domain is supposed to have sigs, it didn't?" I think in this case you could change the simple example above as: 1) unsigned path, everything 'ok' 2) unsigned path, everything 'ok' except there is a prefix with ROA data and no sigs is that right? _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
