('binary' encoding is not supported, stored as-is) > 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
This archive was generated by hypermail 2b30 : Fri Jul 12 2002 - 15:41:56 PDT