potential new IETF WG on anonymous IPSec

[Bill Stewart]

At 02:17 PM 9/16/2004, Joe Touch wrote:

>Ian Grigg wrote:
>>On the backbone, between BGP peers, one would have thought
>>that there are relatively few attackers, as the staff are
>>highly trusted and the wires are hard to access - hence no
>>active attacks going on and only some passive eavesdropping
>>attacks.  Also, anyone setting up BGP routing knows the other
>>party, so there is a prior relationship.
>
>My understanding of the attacks this past spring is that:
>         a) they were indeed on the backbone BGP peers
>         b) that those peers had avoided setting up
>            preshared keys or getting mutually-authenticatable
>            certificates because of the configuration overhead
>            (small on a per-pair basis, but may be large
>            in aggregate)

The interesting attacks were a sequence-number guessing attack
using forged TCP RST packets, which tell the TCP session to tear down,
therefore dropping the BGP connection (typically between two ISPs).
The attackers didn't need to be trusted backbone routers -
they could be randoms anywhere on the Internet.
BGP authentication doesn't actually help this problem,
because the attack simply kills the connection at a TCP layer
rather than lying to the BGP application.

A simple way to avoid most of this problem is to
filter packets at the edges so that customer connections
can't send IP (or ICMP, while you're at it) packets
to the core addresses on the routers that do the BGP signalling.
(It's not a complete solution, because both ends of the connection
need to so that, or need to do spoof-proofing so nobody can forge packets
from those addresses, or both.)  Customers can still send packets
to the ISP edge routers supporting their own connections,
but killing your own internet connection is much less entertaining
than killing somebody else's, and if the customer is managing their own router,
their users probably have an easier time killing that end of the connection
than convincing the ISP's end to drop the connection.

(One downside to this approach is that customers can't simply ping routers
to get information about paths, latencies, capacities, etc.,
but that's not necessarily a bad thing.  Also, you can set things up
so they can traceroute to the far end of a connection and still get
traceroute responses from the intermediate routers.)

>While inspired by this issue, there may be other solutions (e.g., IMO 
>IPsec) which are more appropriate for BGP peers.
>...
>I wouldn't think that the encryption need be opportunistic; in the BGP 
>backbone world, as you noted, peers are known a-priori, and should have 
>certs that could be signed by well-known, trusted CAs.

I agree with Joe.  You can fix most of the problems using ACLs,
but IPSEC does have some appeal to it.
You don't even need CAs - pre-shared secrets are perfectly adequate,
but if you want to use a CA-based IPSEC implementation for convenience,
you can agree on what CA to use when you're agreeing on other parameters.


----
Bill Stewart  bill.stewart at pobox.com