Date: 11 Jul 2002 00:12:39 -0000
From: [email protected]
To: [email protected]Subject: Cisco VPN3000 gateway MTU overflow
Cisco VPN3000 gateway MTU overflow
Bug class: Conceptual/bad protocol implementation
Equipments affected: Cisco/VPN 3000 Concentrator with
software vpn3000-3.5.Rel-k9.bin
FACTS
The Cisco VPN3000 gateway lets remote client dictate
which maximum MTU to use when sending back ESP
frames, regardless of the transmitting capabilities
of the physical medium.
IMPACT
* Oversized frames get silently discarded by
equipements linked to the gateway's public
interface and retransmissions occur.
* Other disturbances or DoS against neighboring
equipements may occur, especially as many IP
stacks on routers and sniffers etc ... are
poorly implemented.
DETAILS
We have witnessed this phenomena after establishing
tunnels with the "VPN dialer" over a modem
connexion: when the target sends back ethernet
frames with size close to the max ethernet MTU
(1500), the gateway encrypts the frames adding
ESP headers and stupidly tries to send a
1580-bytes frame back to the client.
RESOLUTION
-> From the official documentation there is no way
to enforce a maximum MTU on the VPN gateway.
-> Hence: a gateway software patch by Cisco is
necessary: if MTU negociation occurs, the gateway
should set a max-MTU threshold (the physical medium's !).
PSEUDO WORKAROUNDS
* client side: For Windows-based OS (likely Unix and
Linux-based OS too), Cisco released a tool
called setMTU.exe that can prevent ill MTU
negociation from happening.
* target side: artificially lowering the max MTU
on the interfaces.
-> But such a policy is not acceptable:
The VPN client, as well as remote targets,
should not have to be aware of
the gateway's interface configuration !
The bug does not lie in client software, but
in the gateway's software.
Master Phi
---
Today's statement:
Networking software robustness isn't worth the tenth
of that of arcade game engines.
Let's call it junk software.
