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