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