>Number:         21596
>Category:       kern
>Synopsis:       ip_nat.c MSS clamping ineffective when only one TCPOPT present in packet
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 16 12:35:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Jason Lingohr
>Release:        NetBSD 1.6
>Organization:
	N/A
>Environment:
	
	
System: NetBSD bastion 1.6 NetBSD 1.6 (BASTION_IPSEC_ALTQ) #1: Fri Oct 25 08:43:34 EST 2002 root@bastion:/usr/src/sys/arch/i386/compile/BASTION_IPSEC_ALTQ i386
Architecture: i386
Machine: i386
>Description:
Firstly, my network (logical, not physical):

	Internet
	   |
	DSL into upstream
	   |
	IPIP tunnel to my 56k async modem dialup
	   |
	bastion (this box)
	   |
	LAN

When using NAT and the mssclamp option to get around evil remote hosts, I
find that when a remote host returns only one TCP option during negotiation,
clamping isn't performed on the outgoing packet.

I can only suspect this is the case as inbound connections to the same
IP and same port, but with several TCP options present, get clamped fine.

Here is a tcpdump of a working attempt (dumps done on gif0, as I run
a tunnel routing my Class C network to/from me):

17:07:57.172559 211.28.135.246.52487 > 203.56.123.10.smtp: S [tcp sum ok] 3548657691:3548657691(0) win 16384 <mss 1420,nop,wscale 0,nop,nop,timestamp 0 0> (DF) (ttl 56, id 44626, len 60)
17:07:57.173268 203.56.123.10.smtp > 211.28.135.246.52487: S [tcp sum ok] 2300069903:2300069903(0) ack 3548657692 win 32660 <mss 552,nop,nop,timestamp 383322033 0,nop,wscale 0> (DF) (ttl 63, id 34503, len 60)

And here is another that fails (and the mail delivery eventually times
out):

17:06:44.659360 203.2.192.85.39767 > 203.56.123.10.smtp: S [tcp sum ok] 2580423104:2580423104(0) win 8760 <mss 1420> (DF) (ttl 242, id 31465, len 44)
17:06:44.660374 203.56.123.10.smtp > 203.2.192.85.39767: S [tcp sum ok] 2231473183:2231473183(0) ack 2580423105 win 32660 <mss 1420> (DF) (ttl 63, id 34229, len 44)

MTU values on each end of the PPP link is 1500, and 1492 on the gif
tunnel (this has been done because my upstream uses DSL.)

Clamping config (/etc/ipnat.conf):

map gif0 203.56.123.0/24 -> 0/0 mssclamp 552

Now, I've seen the hints on setting net.inet.tcp.rfc1323=0, and haven't
tried it as I'm fairly sure that may fix -- but I'm not happy
about disabling RFC1323 TCP extensions across the board just for the
occasional host.

I'm not intimate with the code, but it would seem that if the stack sees
a "non RFC1323-enabled packet", it skips clamping altogether.  As per the
RFC, TCP option mss is not part of the 1323 extensions.

>How-To-Repeat:
Any host connecting inbound, and only sending the one TCP option (mss) appears
to reproduce the problem.

>Fix:
Unknown.

>Release-Note:
>Audit-Trail:
>Unformatted: