Bugtraq mailing list archives
Re: Cisco VPN3000 MTU overflow (fragmentation issue)
From: <porte10 () free fr>
Date: 12 Jul 2002 16:27:53 -0000
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
Current thread:
- Re: Cisco VPN3000 MTU overflow (fragmentation issue) porte10 (Jul 12)