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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Yiu L. Lee wrote:
> 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 TCP MD5, TCP options can be modified and the MD5 hash will not detect 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?

Yes, these are correct. I would assume that the flag is 0, however -
there are numerous reasons to want/need to protect other TCP options,
e.g., timestamps, to protect the connection from attack.

Joe


> On 4/7/09 6:54 PM, "Joe Touch" <[e-mail]> wrote:
> 
> 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  [phone]
>>>> Färögatan 6                | Mobile [phone]
>>>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>>>> ----------------------------------------------------------------------
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknknO8ACgkQE5f5cImnZrv7owCghgf+Mq4n0Oth93iaA3mPLkO6
2jcAoKcufMum39GbkG3rMhG/WD5BlE1c
=kvbr
-----END PGP SIGNATURE-----