Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09

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

A few notes triggered by the recent discussion:


(1)  "internet"  vs.  "Internet"

>From FYI 12, the "Internet Users' Glossary" (RFC 1983):

   internet
      While an internet is a network, the term "internet" is usually
      used to refer to a collection of networks interconnected with
      routers.  See also: network.

   Internet
      (note the capital "I") The Internet is the largest internet in the
      world.  [...]

      [[ the subsequent text is mostly OBE ]]

So it's been clear since decades that "internet" is the general term
to be used in statements of general scope.  For the sake of precision,
"Internet" should not be used as "pars pro toto" term -- only when the
statement to be made is specific to "The Internet" and does not hold
more generally in connected networks (that might not be globally
routable).

Please note that the OPS Area has carefully banned "Internet" from
documents related to the SMI and SNMP framework in order to emphasize
that these technologies developed in the IETF are _not restricted_
to the (global) "Internet".


(2)  "the WG"

What has been referred to as "the [TCPM] WG" in this thread is by
most readers of the TCPM list seen as a tiny group of o^Hverl^Hy
active contributors who overwhelm the discussion with iterated
notorious statements which many folks that are not in a position
to be able to constantly respond at a high rate got tired of over
the years.

TCPM, in an absolutely annoying manner, is short of ultimately
failing its mission to "maintain" the TCP specifications.
Maintenance in a rapidly changing world does not mean aseptical
conservation of sacred documents in a holy grail; it means
evolution, adoptation to requirements, and progress.

Implementation experience and changing environments are getting
ignored and neglected to a degree I rarely ever have seen in
another WG.
RFC 5681 is the only Standards-Track document ever published by
this WG that resonably falls in the "TCP maintenance" category.
Two "minor extensions" have been published on the Standards Track as
well, but all other output of the WG so far is either Experimental
or Informational.  Note that one of these two "extensions" actually
is limited to "detecting", and doesn't initiate protocol actions.
That's why many folks do not contribute any more to the list, why
vendors and implementors do not regularly comment any more on the
list, and why the majority of *relevant* TCP related discussions
aiming at progress is conducted off-(TCPM-)list now, according to
my personal experience.

Folks interested in learning what maintenance and constructive
WG work and discussion means should look for examples; there are!
Observing WGs successfully acting on protocol maintenance isn't
difficult.  Strong success factors are the tradional confidence
in the normative power of robust, interoperable implementations
combined with active WG process management and orientation on
milestones (once agreed upon).  For instance, we can now expect
that the revised IKEv2 specification will be completed by mid-2010,
within roughly 2 years (unless the IESG runs havoc against it),
although the thourough review process has uncovered much more
issues in the original specification than envisioned by IETF 72.
In this case, implementers have been attracted by seeing their
voices are being heard.  On the contrary, TCPM has convinced
many folks that it doesn't pay to participate.  Changing their mind
after they have been silenced and/or discouraged over several years
will need a major effort and a clear commitment to progress.

Seeing a WG constantly exercising the habit of "we're not changing
the spec" (even when we admit it's poor, ambiguous, or OBE) and even
"and we aren't even making any recommendations" is one of the main
reasons why so few people voluntarily undertake the pain of being
thrashed for their real-world arguments by a few loud and frequent
voices on TCPM.  People expect leadership and guidance from the IETF,
not documents where "the WG" (see above) says:
 "Ouch, the authors brought experience and advice to us, but we did
  not feel comfortable with what we are chartered for and actually
  do not want to endorse any kind of real-world improvement."

Do we really need some kind of "TCP-related Kaminsky++" attack
demonstrated at 27C3 (or maybe 28C3 -- ask the web for 26C3 if
you don't know) and failure of the IETF to actually maintain TCP
reported in the press worldwide before this group is waking up
and starting efficient work to bring the TCP specs in alignment
with current requirements and generally agreed implementation
practices, or do you want to continually further the predominant
impression of a WG trying to conserve a clinically "clean", but
mummified TCP specification -- up to the point that vendors and
open-source TCP implementers regard IETF work there (or in general)
as irrelevant for the evolution of the protocol(s)?

This list should stop ignoring the "silent majority".

>From time to time, ultimately someone's blood boils and he raises
his voice on the list, but messages like msg05064 in December ...

> ... on all fronts it has shown exactly how the IETF should not do
> things.  The fact that one vocal and nagging individual can usurp
> and upset the effort and the ideas that originated with others was
> definitely odd to me..

... aren't going to be understood as an alarming sign by "the WG".
They should!

It cannot be denied that the TCPM processes are broken.
That's a basic, general matter of fact.
Everybody can find evidence in the archives.

I've arbitrarily picked a TCPM charter snapshot (from May 2008) :
  <http://www.IETF.ORG/dyn/wg/charter/history/tcpm-charter.2008-05-22.0.html>

| TCP Maintenance and Minor Extensions (tcpm)
|
| Last Modified: 2008-04-23
|
| ...
|
| Goals and Milestones:
|
| ...
|
| Oct 2006     Submit revision of RFC 2581 to the IESG for publication
|              as a Draft Standard.

(Sic. In May 2008.  Time journey?  Hibernation?  Honest, at least.)

As recorded today, with only one additional comment:

[script]  # ftp ftp.RFC-Editor.ORG
[script]  ...
[script]  ftp> dir in-notes/rfc5681.txt
[script]  200 PORT command successful.
[script]  150 Here comes the directory listing.
[script]  -rw-rw-r--    1 6000     1000    44339 Sep 04 22:08 rfc5681.txt
                                           # i.e. 2009-09-04
[script]  226 Directory send OK.
[script]  ftp> ...

|
| ...
|
| Jan 2007     Submit ICMP attack document to the IESG for publication
|              as an Informational RFC.

... <2010-01-28 today>  ???  ...

At the same time (since early in 2008), there was a *wg* draft not
even listed in the charter, about which the _current_ WG page,
<http://tools.IETF.ORG/wg/tcpm/>, reports:

| ...
|
| draft-ietf-tcpm-1323bis        -01     2009-03-04  Expired
|
| ...



Kind regards,
  Alfred Hönes.

-- 

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