Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03 -- TCP flags

From: Alfred Hönes <[email-masked]>
Date: Wed, 27 Jan 2010 17:38:49 +0100 (MEZ)

Regarding Pasi's comment on TCP header flags:

> - Appendix A.2, "Verify TCP": the bits that are currently reserved
>   might get allocated in the future (and half of the bits that were
>   reserved in RFC 793 have been since allocated -- so it's not very
>   clear exactly what "TCP.reserved_bits" means).

Please note that the second diagram at
   <http://www.iana.org/assignments/tcp-header-flags>
does not represent the current state of assignments.
It is drawn from RFC 3168 and does not depict the assignment
performed for RFC 3540.
The effective current state is shown in the diagram below.

(However, note that there are already proposals floating around
 to make use of the remaining available flags, e.g. for PCN
 signalling, IIRC.)

Generally, 'mbz' fields should never be checked by destination
systems or intermediate systems that don't support functionality
related to such bits specified in more recent documents --
otherwise transparency and protocol extensibility would be
impacted substantially.

RFC 2780 simply says:

|9.2 Reserved Bits in TCP Header
|
|  The reserved bits in the TCP header are assigned following a
|  Standards Action process.

... and RFC 4717 says:

|7.2.  Reserved Bits in TCP Header
|
|  There are not enough reserved bits to allocate any for
|  experimentation.

The TCP section of RFC 1812 refers to the IP sections of that document
for generally applicable rules, and there it states:

                                    [...]  A router MUST NOT set either
   of these bits to one in datagrams originated by the router.  A router
   MUST NOT drop (refuse to receive or forward) a packet merely because
   one or more of these reserved bits has a non-zero value; i.e., the
   router MUST NOT check the values of thes bits.

and later:

                                       [...]   Routers MUST NOT drop
     packets merely because one or more of these reserved bits has a
     non-zero value.

The aforementioned IANA registry should say (a request for correction
has been stalled long ago; at some point in time, I ran out of energy
to insist on action and follow up) -- change bars mark modified lines:

--------snip--------

The Transmission Control Protocol (TCP) included a 6-bit Reserved
field defined in RFC 793, reserved for future use, in bytes 13 and 14
of the TCP header, as illustrated below.
The other six Control bits are defined separately by RFC 793.

     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |               |                       | U | A | P | R | S | F |
   | Header Length |        Reserved       | R | C | S | S | Y | I |
   |               |                       | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

|RFC 3168 defines two of the six bits from the RFC 793 Reserved field
|to be used for ECN, and RFC 3540 added another bit, as follows:

     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|  |               |           | N | C | E | U | A | P | R | S | F |
|  | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
|  |               |           |   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

--------snip--------

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Jan 2010 14:55:51 +0200

>      packets merely because one or more of these reserved bits has a

This and Pasi's comments were strong enough, so I removed offending
check of reserved bits in the pseudocode (and updated also section
8.3.1).
-- 
[email-masked]