Re: ProxyARP and IPSec

[stephen@dino.dnsalias.com (Stephen J. Bevan)]

Alexey Kuznetsov writes:
 > Probably, you are not aware that "standard IPsec tunnel device",
 > if it is created:
 > 
 > 1. Probably, will not accept fragmented frames, because IPsec cannot
 >    handle them

IPsec can handle them, though not particularly smoothly if the IPsec
tunnel is only supposed to carry a particular port&protocol
combination.


 > 2. Probably, will have undefined MTU (65536), because of 1

An MTU that is more likely to make most things work (at least over
Ethernet) is ETH_DATA_LEN - MAX_SA_LEN where MAX_SA_LEN is however
much is required for IPsec (something like IP + UDP if NAT-T + ESP
header + IV + padding + ESP trailer).  The simplest thing is to just
statically configure it.  However, some implementations dynamically
calculate the IPsec device MTU based on the maximum size required by
any of the IPsec SAs that will go over the interface, using either a
pessimistic (255) or optimistic (2) padding estimate.  This can cause
problems for OPSF adjacency if each side arrives at a different MTU
but that can be handled by either manually configuring the device MTU
or explicitly configuring the MTU that OSPF will advertise (I think
Quagga supports that).


 > Actually, this is the reason why it is not implemented.
 > It is dirty business. :-) And the person, who implements this,
 > has to be really... unscrupulous. :-)

Exactly the same issue occurs if one implements IPsec (or any other
encryption method) in user-level using a tun/tap device.  Consequently
while I agree that fragmentation causes an additional level of
problems if one wants to have port/protocol based selectors in IPsec,
I believe that most (but not all) VPN users are quite satisfied with
policies containing all traffic, all ports and so will not encounter
any IPsec specific problems.