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

Joe Touch <touch@ISI.EDU> Tue, 14 April 2009 14:25 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A407B28C143; Tue, 14 Apr 2009 07:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Level:
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gENXVAnQgmN8; Tue, 14 Apr 2009 07:25:17 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7ABF028C102; Tue, 14 Apr 2009 07:25:12 -0700 (PDT)
Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3EEPqfj026073; Tue, 14 Apr 2009 07:25:54 -0700 (PDT)
Message-ID: <49E49CF0.6070203@isi.edu>
Date: Tue, 14 Apr 2009 07:25:52 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Yiu L. Lee" <yiu_lee@cable.comcast.com>
References: <C60A018F.83F0%yiu_lee@cable.comcast.com>
In-Reply-To: <C60A018F.83F0%yiu_lee@cable.comcast.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: softwires@ietf.org, tcpm@ietf.org
Subject: Re: [tcpm] [Softwires] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2009 14:25:28 -0000

-----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" <touch@ISI.EDU> 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  +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
_______________________________________________
Softwires mailing list
Softwires@ietf.org
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-----