On Tue, Mar 20, 2012 at 9:59 PM, Russ White <[email protected]> wrote:
>
>
>> BGPSEC is not a new *routing* feature. It is protections for existing
>> routing features. BGPSEC eliminates certain *bad* routing behavior,
>> but it should not create *new* routing features.
>>
>> The ability to restrict where a receiver can propagate an update is
>> not presently BGP behavior. Brand new routing behavior. That's the
>> difference.
>
> So, just to ask... Suppose you have this:
>
> A---B---C---D
> | |
> +-E-+
(fixed, I think, the ascii-art, which didn't survive at least for me)
paths: a-b-c-d
a-b-e-c-d
both exist in the pict above.
> 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 think the arguement is that D never sees the path that includes E...
because B decided not to let that happen (by not sending E the path
which it could also decide not to send to C and thus on to D)
>
> Correct? So:
>
> 1. The existence of the link from B to E is a fact within the topology
> shown.
yes
> 2. Choosing not to use that link is an expression of policy, and a
> policy that cannot be expressed within BGP itself (on the wire protocol
> wise) today. Today, in other words, there is no way for B to communicate
> to D what it's policy is in regards to receiving transit traffic through
> E from D.
yes
> 3. So the ability to remove the B to E link from the possible paths
> available to reach A, enforcable by D, is actually a new feature in BGP.
i don't think so, it's a 'feature' of bgp in general, isn't it? not 'new'.
> The signatures suggested will actually provide D with information about
> B's policy towards E --something which is not currently carried in BGP.
> Hence BGPSEC is a new feature in BGP, and should be treated as such.
no, I don't think so. The signature data from B -> c -> d doesn't say
anything about E, you could infer (if you knew the topology) that B
has some policy in place to prevent routes traversing E to be made
available... Well, really you'd know that between B and E there
existed (on some side of the fence, though perhaps at E->C even!) some
policy which decided to not send routes of this ilk along.
Even more complicated, C could simply not choose to send the E path to
D... another policy enforcement point:(
or even more.... C could choose to not accept the route from E
because, there was some business logic in place (expressed in policy)
that said E was a 'customer' of E but was not elligible to transit
routes from B and A across this link between C and E!
-chris
(I think I drove the train off the rails...)
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
