Re: [tcpm] TCP reserved bits and793bis

[John Leslie <[e-mail]>]

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.

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

   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.

> 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.

   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.

   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.

   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.

   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.)

> 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!)

--
John Leslie <[e-mail]>