('binary' encoding is not supported, stored as-is) 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.