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