[c-nsp] RE: Pix to Pix tunnel performance w/Windows File Sharing

[Joel M Snyder]

Tony Mucker wrote:

> If you change MTU on the PIX, then a TCP host will send a packet with 
> say MSS of 1500 and DF set.  This will in theory cause the PIX to 
> report back an ICMP message that fragmentation was needed but DF was 
> set.  The TCP host then lowers MSS and tries again, until it succeeds.  

It's a bit more complex than that.  The IPsec specs allow you to either 
copy the DF bit or not when you tunnel a packet.  Most implementations 
don't, for whatever reason.  Since you ESP first, and then decide 
whether or not to fragment, a packet that does not have the DF bit 
copied will not get an ICMP generated by the IPsec device.

The complications get worse when you remember that the ICMP does not 
return the whole packet (generally) but only the first chunk.  Thus, 
let's say you DO copy the DF bit.  In most cases, when an ICMP 
frag-needed-but-df-set packet gets sent to an IPsec device, it does not 
have sufficient information to know WHICH TCP sender to forward the ICMP 
onto (assuming that the fragmentation happens on an encrypted packet).

Remember also that ESP cannot operate on a fragment.  This means that if 
an ESPed packet is fragmented on the way, the receiving IPsec device 
must recieve ALL fragments before it can decrypt the packet.  Ergo even 
further delays.

The result is that while diddling MTU or MSU are distasteful because of 
the little time bomb you're leaving behind, they are more reliable ways 
of solving performance problems with IPsec.

What I tell people in VPN design projects is that you should not run 
around gratuitously fiddling MTU parameters on hosts, but that if you do 
find a particular performance problem, you can specifically tcpdump to 
figure out whether fragmentation is the problem, and only then would you 
want to look at changing host-based or gateway-based parameters to solve 
it.  (and, yeah, fixing app-layer 'segment size' is always better than 
doing it in IP, because of the way that most apps work)

jms

-- 
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Phone: +1 520 324 0494 (voice)  +1 520 324 0495 (FAX)
jms at Opus1.COM    http://www.opus1.com/jms    Opus One