Re: [tcpm] [Softwires] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite

HI Joe,

In RFC2385 - Section 2.0 Item 2, it says

       2. the TCP header, excluding options, and assuming a checksum of
          zero

Since TCP options are excluded, changing MSS won't affect the MD5 mechanism,
will it?

In draft-ietf-tpcm-tcp-auth-opt-04.txt - Section 5 Item 2, it says

   2. A TCP option flag. When 0, this flag allows default operation,
      i.e., TCP options are included in the MAC calculation, with TCP-
      AO's MAC field zeroed out.  When 1, all options (excluding TCP-AO)
      are excluded from all MAC calculations (skipped over, not simply
      zeroed). The option flag applies to TCP options in both directions
      (incoming and outgoing segments).

      >> The TCP option flag MUST NOT change during a TCP connection.

      The TCP option flag cannot change during a connection because TCP
      state is coordinated during connection establishment. TCP lacks a
      handshake for modifying that state after a connection has been
      established.

Changing MSS could be a problem when TCP option flag is set to 0. When the
flag is set to 1, changing MSS is fine, isn't it?

Thanks,
Yiu 

On 4/7/09 6:54 PM, "Joe Touch" <touch@ISI.EDU> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, all,
> 
> The solution has a bug: if TCP traffic uses TCP MD5 or TCP-AO, then it
> needs to be handled like non-TCP traffic, since MSS revision would
> destroy the packet's integrity.
> 
> IMO, this should be handled the simple way - remove the TCP case, and
> handle all traffic the non-TCP way.
> 
> Finally, if a NAT ever refuses to reassemble anything, it MUST issue an
> ICMP too-big IMO. The whole idea of creating a problem (encapsulating,
> decreasing the effective MSS on a path) then not cleaning it up
> yourself, or deciding when to clean it up based on *current* assumptions
> of network traffic is a bad idea and shouldn't be supported.
> 
> Joe
> 
> Magnus Westerlund wrote:
>> Hi,
>> 
>> There is a proposal to use TCP MSS clamping to deal with MTU issues that
>> comes from Dual-stack lite's tunnel encapsulation.
>> 
>> I think it would be good if TCPM could provide some feedback on this
>> proposal.
>> 
>> The relevant document and section:
>> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00
>> 
>> 7.4. MTU
>> 
>> 
>>    Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over
>>    IPv6 will reduce the effective MTU of the datagrams.  Unfortunately,
>>    path MTU discovery is not a reliable method to deal with this.  As
>>    such a combination of solutions is suggested:
>> 
>>    o  For TCP traffic, let the carrier-grade NAT rewrite the MSS in the
>>       first SYN packet to a lower value.
>> 
>>    o  For non-TCP traffic, perform fragmentation and reassembly over the
>>       tunnel between the home gateway and the carrier grade NAT.  In
>>       practice, this means put the IPv4 packet into a large IPv6 packet
>>       and fragment/reassemble the IPv6 packet at each endpoint of the
>>       tunnel.  There is a performance price to pay for this.
>>       Fragmentation is not very expensive, but reassembly can be,
>>       especially on the carrier-grade NAT that would have to keep track
>>       of a lot of flows.  However, such a carrier-grade NAT would only
>>       have to perform reassembly for large UDP packets sourced by
>>       customers, not for large UDP packets received by customers.  In
>>       other words, streaming video to a customer would not have a
>>       significant impact on the performance of the carrier-grade NAT,
>>       but will require more work on the home gateway side.
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> IETF Transport Area Director & TSVWG Chair
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAknb2a8ACgkQE5f5cImnZrs0ewCg7ScElkpLrz20zSpTMnXuRApa
> CPsAoIyhk9N9K2fPpEJTyShMKeZNLxD/
> =9ob2
> -----END PGP SIGNATURE-----
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> 