Re: [tcpm] TCP reserved bits and793bis

[Joe Touch <[e-mail]>]

Hi, John,

On Jul 9, 2014, at 4:09 AM, John Leslie <[e-mail]> wrote:

> Joe Touch <[e-mail]> wrote:
>> 
>> There are two interpretations of "Must be zero":
>> a) current implementations should drop segments with those bits set
>> 
>> b) current implementations should ignore those bits
> 
>   Indeed, we must work around endpoints which do either of these.
> 
>> It says "Must be zero." That can easily be interpreted as requiring that 
>> when the bits are set the segment is invalid.
> 
>   But only so interpreted by an endpoint. No middlebox is entitled to
> do that.

Right - my claim has always been that there are no such things as middleboxes; there are hosts and there are routers. Routers ought to look no further than L3; everything else is acting like a host, and breaks what we expect when we think of an Internet. That's especially true for boxes that modify L3 or L4 beyond what RFC1812 permits (HBH options, hopcount, IP checksum).

>   (Of course, a middlebox _is_ entitled to drop an IP packet for any
> reason whatsoever.)

Anything that is visibly indistinguishable from a link is a link (or a part of a link). The same applies to routers and hosts, to me at least. Intent and mechanism aren't relevant; externally visible behavior is.

>   Our problem is that currently-deployed "middleboxes" do a bunch of
> things which really qualify as "damage". Accept that, but don't argue
> that it's a reasonable interpretation of 793.

Agreed.

>> Note that RFC793 doesn't define what to do when the Data Offset is 
>> smaller than 5 - so does that mean you should be liberal and process 
>> such segments, or drop them?
> 
>   That's a good question. Let me at least nibble around the edges.
> 
>   If the two endpoints have agreed on a meaning, of course the receiver
> should process it.

That's true for any property. It doesn't mean they're running TCP anymore, though.

>   If a receiver _hasn't_ agreed on a meaning, it should own up to
> having no clue whether there are any options and/or any data. If
> the checksum validates, it's probably time to give up and close the
> connection; otherwise it could discard the packet.

I don't think a single invalid segment should ever affect a connection or connection in progress. I would say "silent drop" to any packet that can't be understood.


>   If a middlebox sees Data Offset less than five, it similarly
> should probably admit it has no clue whether there are any options
> or any data. If all it wants to do is rewrite source IP and port,
> it should probably do that and pass everything else unchanged,
> adjusting the checksum.

I disagree; a middlebox that modifies the IP address and/or TCP ports is acting as a host to the downstream components, and should be expected to follow host requirements. In this case, if a host MUST silently drop nonsense packets then so should a box that looks like a host.

>   If a middlebox wants to do something with options or data, it
> probably needs to drop the packet -- because it can't do what it is
> designed to do.

I think it has to have already dropped it.

>   Now we get into the really messy area: if a middlebox sees that
> something like EDO has been negotiated (which _is_ possible when
> it intercepts in both directions), should it process according to
> that option?
> 
>   IMHO, there's no fully satisfactory answer to that. Myself, I'd
> prefer it didn't. A middlebox wanting to meddle that much should
> act as an endpoint. (But of course, we can't enforce that.)

See above; I've been saying as much for a long time. Actually NAT boxes are a little more complex:

	- to the upstream (the devices "behind") them, they MUST act like a router
	(including decreasing the hopcount, etc.)

	- to the downstream, they MUST act like a host

So they get twice the requirements.

>> I agree that "liberal" means that, in either case, you MUST NOT generate 
>> a response segment, ICMP message, or user error. But it's not as clear 
>> *from the current text*.
>> 
>> The point of all this is that 793bis needs to be updated to make this 
>> direct and explicit, though.
> 
>   Alas, that won't fix the problem. At best, it might change new
> middlebox designs. There's no way it could fix deployed middleboxes.
> (But it would _feel_ better to have an unambiguous statement that
> this is damage!)

Sometimes that's the best we can do; sometimes it's better to declare what's deployed "broken" than to try to find a way to accommodate it.

Joe