Re: Modefg considered harmful

[Stephen Kent <kent@bbn.com>]

At 7:54 PM -0800 2/1/03, Bernard Aboba wrote:
>  > But there is a second function of the gateway that is
>>  intimately bound to address allocation. The IPsec gateway has to respond to
>>  ARPs to the assigned IP address and forward packets addressed to that IP
>>  address to the endnode.
>
>So you're saying that the IPsec gateway *must* implement proxy ARP? Why
>wouldn't participation in the routing mesh be enough? For example, if the
>IPsec gateway is injecting routes for the addresses of the nodes it is
>handling (either an aggregated prefix or the host routes) wouldn't that
>work? The result will be that packets destined for those addresses will be
>forwarded to the IPsec gateway.
>

Bernard,

When one starts moving into this realm of routing functionality, 
there are serious security concerns that IPsec has not yet fully 
addressed.

In 2401bis, we plan on de-coupling route selection from SA selection, 
by having an explicit lookup for routing performed prior to SA 
selection, and then passing along a virtual interface ID as part of 
the SA selection process.  This is something that was discussed among 
a set of folks interested in PPVPN and overlay nets over the last 
several months. If adopted, this would make it easier to accommodate 
the sort of full-fledged routing participation that you allude to.

However, another problem arises here, i.e., how do we know what 
portions of address space a given IPsec gateway is authorized to 
advertise. If the gateway represents a leaf for routing purposes, 
then this may be successfully managed manually, and with the current 
binding of SA selection and routing, I assume this is what has been 
done. But there are folks who have a good reason to want to separate 
these two functions, and if we start having IPsec gateways executing 
BGP, I worry that we do not have adequate means to verify the 
authorization aspect of routes.  The infrastructure developed for 
S-BGP (a pet project of mine) would supply the necessary info, but it 
has not been deployed so far. At a minimum we should address the 
question in our documents, even if we don't have an agreed-upon 
solution.

Steve