On 3/21/12 5:56 PM, "Christopher Morrow" <[email protected]> wrote:
>On Wed, Mar 21, 2012 at 5:19 PM, Robert Raszuk <[email protected]> wrote: >> Hi Chris, >> >> >>> In the end, I think 'bgpsec suggests' that the operator would make >>> some decision... ideally the same decision across the network. >> >> >> Such decision is inherently per prefix. So even assuming ideal case and >>such > >yes > >> policy like in your example would be the same across given AS how would >>you >> see such policy to be the same across the entire path given update >>traverses >> ? > >is the policy supposed to be the same across the whole of the path? >does, today, 2914 have the same policy for prefix 128.2.35.0/24 as >as701 as as7018 as as4134 ? > >The policy wrt any bgp learned (AND ANNOUNCED!) route is per-operator, >'per asn' at best. In reality there are even cases where where the >policy is 'per link in an ASN'. > >I'm not sure why expecting this to be different in SIDR is a good thing >to do. > >> Aren't you afraid about swiss cheese effect for end-to-end connectivity >>if >> some ASes prefer signed and some other non signed paths ? > >In general, today there is no coherent policy across ASN's. EXCEPT >'make sure packets get as close to the destination as is possible for >my asn to do.' I suspect that over the course of ~7-10 years BGPSEC >(or similar) would rollout across enough ASN's to ensure 'good enough' >security for a large portion of destinations/prefixes on the network. >I hope that would be the case. > >I believe that, as I said before (perhaps not on sidr?) that the >process looks something like (for an individual operator): > 0) hear about bgpsec > 1) figure out which end is up > 2) upgrade code/etc to support this function after deciding it's >worth your while. > 3) start collecting stats on internal usage + customer usage + >customer-certification-of-resources > 4) action fixes to customer setup and internal setup > 5) start signing your prefixes as you can > 6) use metrics to judge success > >there's likely a few middle steps skipped there... I'm sure someone >else could find other bits to add. > >(really jayb@att has done a lot of work on this planning...) > >> >> What happens in your example if singed comes with PATH_SIG listing 4 >>ASes >> (pCount=1 of each) and real AS_PATH is length of 3 ? > >so, pcount I'm not a fan of.... but, you're suggesting a path that's >invalid? or impossible? In the current BGPSEC spec, there is only a PATH_SIG element (with AS hops encoded within), so this specific scenario could not occur. But even if the protocol carried both fields, I think the basic design of the protocol would label the AS_PATH "Invalid" under the simple primise that the SIG data does not validate the AS_PATH data (no matter where/how it is encoded). What your local policy does with that "Invalid" label, is up to you. Dougm _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
