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

From: Joe Touch <[email-masked]>
Date: Tue, 07 Apr 2009 15:54:39 -0700

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: [email-masked]
> ----------------------------------------------------------------------
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Apr 2009 07:25:52 -0700

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" <[email-masked]> wrote:
> 
> Hi, all,
> 
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: "Yiu L. Lee" <[email-masked]>
Date: Tue, 14 Apr 2009 09:02:07 -0400

HI Joe,

Thanks,
Yiu 

On 4/7/09 6:54 PM, "Joe Touch" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, all,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAknb2a8ACgkQE5f5cImnZrs0ewCg7ScElkpLrz20zSpTMnXuRApa
> CPsAoIyhk9N9K2fPpEJTyShMKeZNLxD/
> =9ob2
> -----END PGP SIGNATURE-----