Re: [tcpm] poll for adopting draft-gont-tcp-security

[Fernando Gont <[e-mail]>]

Hello, Matt,

> Consider sect 4.4.1, SACK-permitted option length must be 2:  This 
> forbids ever extending SACK by adding a subtype, for example to 
> negotiate non-renege-able SACK, by putting a 1 in an optional sub-type 
> carried in additional bytes in the SACK-permitted option.  As far as I 
> know every implementation today correctly parses the option length (e.g. 
> skips forward by the relevant amount), but ignores the option data, so 
> such a change would be backwards compatible with all existing 
> implementations.

I had promised to come back to you on this one. FreeBSD ignores those 
options whose length is not equal to the expected value. Excerpt of the 
tcp_dooptions() function from netinet/tcp_input.c:

		case TCPOPT_SACK_PERMITTED:
			if (optlen != TCPOLEN_SACK_PERMITTED)
				continue;
			if (!(flags & TO_SYN))
				continue;
			if (!V_tcp_do_sack)
				continue;
			to->to_flags |= TOF_SACKPERM;
			break;

The same thing is done for all other TCP options.


Linux does exactly the same thing. Excerpt of the tcp_parse_options() 
function from net(ipv4/tcp_input.c (available online at: 
http://lxr.linux.no/linux+v2.6.30/net/ipv4/tcp_input.c#L3763):


3763                        case TCPOPT_SACK_PERM:
3764                                if (opsize == TCPOLEN_SACK_PERM && 
th->syn &&
3765                                    !estab && sysctl_tcp_sack) {
3766                                        opt_rx->sack_ok = 1;
3767                                        tcp_sack_reset(opt_rx);
3768                                }
3769                                break;


This suggests that extending SACK while still using the same option type 
is not a good idea, or at least not a backwards-compatible one. (It's 
worth noting that about 220 of the 256 available TCP option numbers are 
currently unassigned... so it doesn't look like there's a TCP 
option-number shortage problem, either)

That said, the point you raised is worth noting (i.e., that TCP 
implementations ignore options that do not match the expected option 
length), so it doesn't come as a surprise to anybody trying to extend an 
existing TCP option.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1