Re: Cisco VPN3000 MTU overflow (fragmentation issue)

[<porte10 () free fr>]

> 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