> I do not understand how increasing the MTU would
> be a security vulnerability.
Well, it isn't a raw security vulnerability
-- however there may be side-effects), but an
"availability issue". "Availability issues",
whose worst form is DoS, deserve being published
in BugTraq, provided they are critical and
easily reproduced.
> The VPN Client software allows you to reduce the
> MTU so that when encryption overhead increases
> the size of the packet it does not cause
> unnecessary fragmentation.
Again, I DON'T SEE WHY THE CLIENT SHOULD BOTHER
ABOUT THE GATEWAY'S NETWORK INTERFACE CONFIGURATION.
We clearly have a design issue here, as the gateway
does not fragment accordingly. Just sniff and
watch.
You can check that the gateway does not accordingly
fragment return packets using the following steps:
E.g.
target ->- 1500 byte-frames/ethernet ->- GATEWAY
|
1580 byte-frames/ethernet ----<-----|
1. sniff at the gateway's public interface
2. from you source search for the critical
data size (by dichotomy) -- the lowest
length for which you get no traffic back:
[CMD]
> ping -t -l 1499 gateway
> ping -t -l 1400 gateway
> ping -t -l 1450 gateway
...
>From my probes, i converged to:
1420 = mtu_ethernet (1500) - ESP headers (80)
>>>>>>>>>>
To patch the bug, the gateway should fragment IP
packets considering the maximum value
max { client_proposed_mtu, gateway_medium_mtu }
instead of just client_proposed_mtu.
Master Phi
