Re: [RPSEC] Re: draft-convery-bgpattack-00

[[e-mail]]

>- include all neighbors in one signature: more costly in terms of
>  memory, less in processing

You have probably read Charlie Lynn's mail by now where he says that
SBGP can do this.  And we had discussed earlier grouping neighbors.

Which brings up the point that I should and will stop trying to answer
questions about the SBGP stuff, since I'm definitely not the expert here.

>Because there is simply a lot of peering.

Well, it's widely know that the average AS_PATH is not long.  But it
isn't *2*.  Which means that there are lots of cases where two AS's
aren't neighbors.  Which opens opportunities for influencing routing
to the bad, if you don't have protections.

>- don't include the AS for peering neighbors but only transit neighbors
>  in the signature. Then peers don't get to announce the route any
>  further, which is good, mostly. Customers of the peer would have to
>  accept the route without a signature, though.

I don't get this at all.  But, more importantly, I don't think that we
should be trying to work out the details of a solution for BGP.
Certainly not in this working group.

The original comment that sparked this thread was that the SBGP
protections eliminated certain optimizations that are used and desirable.
That was incorrect, as Charlie's message shows.  But the lesson for
this working group is (1) most security solutions can have an effect
on optimizations and (2) should the security requirements prohibit
impact on optimizations?  permit the impact?  limit the impact?  Etc.

--Sandy
_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec