Re: [tcpm] tcp-security: Request for feedback on the outline of the document

[Alfred Hönes <[e-mail]>]

Folks,
I strongly disagree with Joe's proposal.
For detailed rationale see below.

Furthermore, the envisioned procedure for the treatment of the
document is perceiced as discriminating; it gives much more
influence to WG participants with an always open time budget, who
can continually follow the discussion and participate quickly,
and it makes contributing by folks like me (who have a 'bursty'
primary business and can only spend cycles for IETF purposes
irregularly) rather difficult and/or inefficient.
Starting this important work, with very short timelines, during
the major summer vacation period is even more unfortunate.
The apparent outcome I observe is that very few but very active
voices already have started majorizing the discussion, and that
I have not heard voices of implementers recently.


Regarding document structure:

The various past reviewers of the original document had
appreciated the focus on implementer's point of view, which
is closely related to the document structure, and among those
reviewers were quite a couple of implementers.

For instance, when implementing checks on a protocol field,
a comprehensive discussion of the properties of that field
is needed, with a summary of known attacks using that field,
and a presentation of restrictions and extensibility properties
of such field, in order to allow the reader to easily make an
educated decision on what checks to implement and what possible
other related hardening measures/knobs for his/her implementation
are needed.
Scattering that information throughout the document will make
the utility of the document highly questionable.
BTW: I could not even see where the fundamental basic discussion
of protocol field properties might be located in the stucture
Joe proposed.

IMO, far-reaching structural changes should only be applied with
strong support from the TCP implementers' community.


As a mathematician, I have a strong preference for a bottom-up
document structure, starting with the definitions and proceeding
to the properties and gradually more complex conclusions;
in the context of protocol design and implementation, that means
a good document (after a short overview) should start with the
basic data structures and protocol fields.
The worst documents I ever had to read and understand were those
that gave the basics last (e.g., many OSPF documents, defining
the PDU fields and formats in Appendices -- ugly!)

Fernando's outline roughly follows that natural bottom-up paradigm,
starting with the PDUs and the field properties, specific attacks
related to each single field, and general considerations regarding
particular groups of fields -- that's what will go into header
files (in 'C' implementations) and low-level code;
then the original outline proceeds to major procedures to be
implemented (connection setup and teardown, data buffer and data
segment management, congestion control, 'abstract' / socket API
-- modules that typically will have identifiable components in an
implementation and which hence are worth a high-level block of
discussion in a document useful for implementers;
the final chapters discuss more general topics spanning multiple
of the previous topics, and the final chapters regarding ICMP
and the interface to IP help to align with related protocol
components -- you know, strict layer separation isn't a
property of TCP/IP!


There are indeed details to be discussed, e.g., whether the
section on TCP Options better be a subsection of the preceding
section.
IMO, that's not a good idea; the basic TCP Header is mandatory
and (almost) static, it won't change -- even in the long term
future evolution of TCP --, whereas TCP Options are a truly
optional ensemble subject to yes/no implementation decisions;
option design is an ongoing effort making it worth to separate
TCP Options off the basic TCP Header for the exposition, allowing
to discuss general topics specific to these circumstances there.

However, I suggest to re-organize the subsections on the src/dst
port fields:
A general discussion of port numbers, including server ports vs.
(ephemeral) client ports, and the case (and pros/cons) of
(symmetric) peer-to-peer applications operation with fixed port
numbers on both sides should precede the discussion of the
src and dst prot number fields, because the logical properties
of the port numbers (as mentioned above) are not bound to their
per-packet role as src/dst.


In any case, the document structure should be such that
important details can be located in the Table of Contents.
The RFC Editor usually limits the ToC to a certain nesting level
(based on style and available tools); therefore, nesting sections
too deeply should be avoided in favor of more primary sections.


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+