On Wed, Mar 21, 2012 at 8:10 AM, Russ White <[email protected]> wrote: > >> A---B---C---D >> | | >> +---E---+ >> >> "A sends an advertisement to B, B sends it to C, but B does not send it >> to E. Your argument is that BGPSEC prevents D from using the path >> through E by including in the update a series of signatures." > >> I don't see this putting policy in BGP, I don't think anyone has >> stated that you should send along alternate path info with: "Hey, but >> don't use this" bits set. > > What is the signature's existence in the advertisement from C, but it's > non-existence in the advertisement from E, supposed to mean to D? Not to > use the path through E.
but in your example, B never sends the route to E. There is no route, there is no signature... unless you mistyped and meant that it didn't sign toward E but still sent a route toward E? > By adding the signature to the path through C, you've told D not to use > other paths, even if they really exist. Without the signature, D would hrm, well... I think you really (backing up and assuming you MEANT 'did not SIGN to E, but sent to E' originally) tell E "Hi, you don't do security-foo, so you get a plain route", the follow on receipt at C from E is also not signed (once unsigned, can not resign) C can say: "Hrm, I prefer Signed over unsigned, except for Customer over Peer" or some version of that... In any case C has to select the E path as 'better' in some way for it to send the route along to D. At D, again: "Signed over Unsigned" or whatever their policy is rules the day. > have to pick the phone up and ask. With the signature, they don't need > the phone call. If you don't need the phone call to know what B's policy > is, you've added the policy to the protocol. again, your example was B never sends anything to E, " B does not send it to E" (your words, where 'it' refered to the 'advertisement'). So... you can infer all the policy you want at several points in the picture (as I outlined in my initial response) but... the other bits about signature are not applicable. > The point is you've gone beyond the existence of the path here to the > rightful use of the path --and that is policy. don't think so. -chris > > Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
