Message619

Author pcalhoun
Recipients
Date 2008-10-10.14:47:35
Content
The agreement was to keep the Fragment ID field untouched to ensure we 
maintain backward compatibility, but include text to point out the possible 
issues. The resulting text is:

<proposed text>
3.4.  Fragmentation/Reassembly
[...]
   It is important to note that the fragmentation mechanism employed by
   CAPWAP has known limitations and deficiencies, which are similar to
   those described in [RFC4963].  The limited size of the Fragment ID
   field (see Section 4.3 can cause wrapping of the field, and hence
   cause fragments from different datagrams to be incorrectly spliced
   together (known as "mis-associated").  For example, a 100Mpbs link
   with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause
   the Fragment ID field wrap in 8 seconds.  Consequently, CAPWAP
   implementors are warned to properly size their buffers for reassembly
   purposes based on the expected wireless technology throughput.

   CAPWAP implementations SHOULD perform MTU Discovery (see
   Section 3.5), which can avoid the need for fragmentation.  At the
   time of writing of this specification, most enterprise switching and
   routing infrastructure were capable of supporting "mini-jumbo" frames
   (1800 bytes), which eliminates the need for fragmentation (assuming
   the station's MTU is 1500 bytes).  The need for fragmentation
   typically continues to exist when the WTP communicates with the AC
   over a Wide Area Network (WAN).  Therefore, future versions of the
   CAPWAP protocol SHOULD either consider increasing the size of the
   Fragment ID field, or provide alternatives extensions.

12.1.6.  CAPWAP Fragmentation

   RFC 4963 [RFC4963] describes a possible security vulnerability where
   a malicious entity can "corrupt" a flow by injecting fragments.  By
   sending "high" fragments (those with offset greater than zero) with a
   forged source address, the attacker can deliberately cause
   corruption.  The use of DTLS on the CAPWAP Data channel can be used
   to avoid this possible vulnerability.
</proposed text>
History
Date User Action Args
2008-10-10 14:47:35pcalhounlinkissue224 messages
2008-10-10 14:47:35pcalhouncreate