Subject: [tcpm] exegesis of 'Updates' -- was: ... review of draft-ietf-tcpm-tcpsecure[-10]

From: Alfred Hönes <[email-masked]>
Date: Tue, 30 Sep 2008 22:02:43 +0200 (MESZ)

Folks,
I observe that this discussion (which my initial posting has
triggered involuntarily) is getting ridiculous.

Let's return from fine-grained nano-arguments to the roots.

We are discussing the simple "relations" in the metadata of RFCs.

These serve the purpose to visibly link these documents together
in a coarse, qualified manner, and thus enable any reader not
aware of lengthy WG discussion list threads to find a web of
pointers which should assist her/him in finding the related
documents, when starting with a 'well known' base document.

Admittedly, the 'vocabulary' available is very simple, but one
of the main issue I had when I once started reading RFCs was the
very scarce and poor usage of this simple vocabulary, "Updates",
"Obsoletes", and "Also".
My perception frequently was that there were far too many MUSTs
and SHOULDs and MAYs inside the documents, and far too few
"Udates" helping the reader navigate the RFCs, in the metadata.
(It's similar to web pages with no hyperlinks on 'home pages'
[or equivalent] pointing to them!)

Any implementor or analyst reading RFC 793 should be made aware
of the tcpsecure RFC, as soon as it is out (and I really hope to
see it soon in the RFC index!), because that document contains
qualified statements this working group has judged.
[... in an incommensurate long period of discussion holding off
this long-expected document -- personal note.]
He/she should be pointed to this document by the RFC metadata,
and should read it (the latter seems to be the consensus of
the WG, isn't it?) -- otherwise publishing the document would
be rather moot.

The "Updated by" metadata links do not imply requirements
language in any way, they point the reader to documents that
(hopefully) contain an applicability statement and their own,
and detailed requirements language.

If a new document adds, e.g., new options, to properly designed
extensibility hooks of a protocol, without affecting/changing
processing rules of the protocol, that memo does not "Update"
the base document for that protocol, and that document can be
easily picked up by tracing the IANA Registry for the namespace
forming the extensibility hook.  But if a document discusses
new requirements for a protocol that have come up in the real
world, and it contains 'considerations' about modifications
to the processing rules laid down in another document (which
in this particular case already have been adopted by most
significant players in the marketplace as inevitable and
indispensible changes for security reasons), this new document
SHOULD be tagged in the RFC metadata as "Updates <the old one>".

Don't forget:
This WG is chartered for the *MAINTENANCE* of TCP.
If you don't want to make that maintenace visible, you are in
danger to dismiss your mission (and the mission of the IETF and
its Standards Process).  Since RFCs are immutable, RFC Errata
and additions to the RFC metadata are the only ways to make
an act of maintenance for a document visible at first place.

I only see one other option (but I guess that's not a real option
in practice, due to workload): *regularly* update RFC 4614 .
Such documents (and there are far too few of this kind!)
provide enough space to discuss the nuances of conditional
MUSTs and SHOULDs in case of applicability etc. etc. at length,
if deemed necessary.

Therefore my recommendation:

+++   Be very careful with "Obsoletes", but be generous
+++   with "Updates", for the benefit of RFC readers !

Kind regards,
  Alfred.

P.S.:
The discussion has mentioned the tiny number of "Updated by"
for RFC 793, one of the oldest and most important standards
of the IETF.  Many technicians not aware of the discussions
in this WG would take this as a severe indication, or even
evidence for lack of maintenance for TCP!

-- 

+------------------------+--------------------------------------------+
| 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]                     |
+------------------------+--------------------------------------------+

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 30 Sep 2008 15:21:42 -0700

Alfred,
   Excellent points. I completley agree with your sentiments. Some notable excerpts from your below email (cut & pasted) which I fully support :

A)
 > Any implementor or analyst reading RFC 793 should be made 
> aware of the tcpsecure RFC, as soon as it is out (and I 
> really hope to see it soon in the RFC index!), because that 
> document contains qualified statements this working group has judged.
> [... in an incommensurate long period of discussion holding 
> off this long-expected document -- personal note.] He/she 
> should be pointed to this document by the RFC metadata, and 
> should read it (the latter seems to be the consensus of the 
> WG, isn't it?) -- otherwise publishing the document would be 
> rather moot.

B)
> danger to dismiss your mission (and the mission of the IETF 
> and its Standards Process).  Since RFCs are immutable, RFC 
> Errata and additions to the RFC metadata are the only ways to 
> make an act of maintenance for a document visible at first place.

C) 

> +++   with "Updates", for the benefit of RFC readers !

Thanks,
-Anantha
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alfred HÎnes
> Sent: Tuesday, September 30, 2008 1:03 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [tcpm] exegesis of 'Updates' -- was: ... review 
> ofdraft-ietf-tcpm-tcpsecure[-10]
> 
> Folks,
> These serve the purpose to visibly link these documents 
> together in a coarse, qualified manner, and thus enable any 
> reader not aware of lengthy WG discussion list threads to 
> find a web of pointers which should assist her/him in finding 
> the related documents, when starting with a 'well known' base 
> document.
> 
> Admittedly, the 'vocabulary' available is very simple, but 
> one of the main issue I had when I once started reading RFCs 
> was the very scarce and poor usage of this simple vocabulary, 
> "Updates", "Obsoletes", and "Also".
> My perception frequently was that there were far too many 
> MUSTs and SHOULDs and MAYs inside the documents, and far too 
> few "Udates" helping the reader navigate the RFCs, in the metadata.
> Any implementor or analyst reading RFC 793 should be made 
> aware of the tcpsecure RFC, as soon as it is out (and I 
> really hope to see it soon in the RFC index!), because that 
> document contains qualified statements this working group has judged.
> [... in an incommensurate long period of discussion holding 
> off this long-expected document -- personal note.] He/she 
> should be pointed to this document by the RFC metadata, and 
> should read it (the latter seems to be the consensus of the 
> WG, isn't it?) -- otherwise publishing the document would be 
> rather moot.
> 
> If a new document adds, e.g., new options, to properly 
> designed extensibility hooks of a protocol, without 
> affecting/changing processing rules of the protocol, that 
> memo does not "Update"
> easily picked up by tracing the IANA Registry for the 
> namespace forming the extensibility hook.  But if a document 
> discusses new requirements for a protocol that have come up 
> in the real world, and it contains 'considerations' about 
> modifications to the processing rules laid down in another 
> document (which in this particular case already have been 
> adopted by most significant players in the marketplace as 
> inevitable and indispensible changes for security reasons), 
> this new document SHOULD be tagged in the RFC metadata as 
> "Updates <the old one>".
> 
> Don't forget:
> danger to dismiss your mission (and the mission of the IETF 
> and its Standards Process).  Since RFCs are immutable, RFC 
> Errata and additions to the RFC metadata are the only ways to 
> make an act of maintenance for a document visible at first place.
> 
> I only see one other option (but I guess that's not a real 
> option in practice, due to workload): *regularly* update RFC 4614 .
> MUSTs and SHOULDs in case of applicability etc. etc. at 
> length, if deemed necessary.
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Sep 2008 15:30:06 -0700

Alfred � wrote:
...
> +++   with "Updates", for the benefit of RFC readers !

Well, we used to have a general rule:

	Be conservative in what you send,
	be liberal in what you receive.

The second rule is bent by tcpsecure, which interprets unexpected
segments as attacks needing defense.

As a result, we're here considering reasons not to put Updates in the
header, to avoid too strongly implying that all TCPs everywhere need to
be augmented with an IPR-encumbered poor substitute for true security.

My conclusion is that, although I agree with Alfred in spirit, I can't
see why we should be more liberal with Updates than we are with segments
we receive.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 30 Sep 2008 16:19:36 -0700

Joe, 

> Behalf Of Joe Touch
> Sent: Tuesday, September 30, 2008 3:30 PM
> To: Alfred  
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tcpm] exegesis of 'Updates' -- was: ... 
> reviewof draft-ietf-tcpm-tcpsecure[-10]
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Alfred   wrote:
> ...
> The second rule is bent by tcpsecure, which interprets 
> unexpected segments as attacks needing defense.

You have blown this trumphet from day one, so nothing new, really. Like it has been clarified by many folks umpteen number of times, tcp-secure improves robustness of TCP w.r.t processing in-window RSTs, SYNs and Data injection. If you think by doing so we have punched a hole in "liberality", that is your personal take. Not sure why we are even debating this now, during last call! We have moved on from this line a long time back!

> 
> As a result, we're here considering reasons not to put 
> Updates in the header, to avoid too strongly implying that 
> all TCPs everywhere need to be augmented with an 
> IPR-encumbered poor substitute for true security.

IPR issue was raised when the document was initially presented 3+ years ago!. Scott Bradner made a presentation to clarify the IPR intent and after that this, the IPR issue was never considered as a hindrance for the draft to move forward. Agreed that the IPR issue might have had some influence w.r.t the verbiage on the strength of mitigations. Lars Eggert suggested an applicability statement to be added, we added the same. Not sure why you are bringing this up now, the IPR issue was beaten to death long time back.

Again, my current understanding (which is inline with Alfred) is about "if a draft changes the TCP RFC 793 rules in some way, then it is considered as an update and we should mark it accordingly upfront for easy reference purposes" Also, update doesn't mean that "all TCP's everywhere need to be augumented with the changes". An implementer would read the mitigations, AS and the strength of recommended mitigations and would make his/her own choice!

> 
> My conclusion is that, although I agree with Alfred in 
> spirit, I can't see why we should be more liberal with 
> Updates than we are with segments we receive.

IMO, these two are completely 2 different things!

-Anantha
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkjiqG4ACgkQE5f5cImnZruw4wCcDIHsrjF8mTwwMRM1N8YB7vc0
> SRYAnj6ZXFfzhFgzCzUgIMofGUu2SVgj
> =ZAPQ
> -----END PGP SIGNATURE-----

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Sep 2008 16:42:10 -0700

Anantha Ramaiah (ananth) wrote:
...
>--- 
> IPR issue was raised when the document was initially presented 3+
> years ago!. Scott Bradner made a presentation to clarify the IPR intent
> and after that this, the IPR issue was never considered as a hindrance
> for the draft to move forward. 

That is proven incorrect by your next sentence.

> Agreed that the IPR issue might have had
> some influence w.r.t the verbiage on the strength of mitigations. Lars
> Eggert suggested an applicability statement to be added, we added the
> same. Not sure why you are bringing this up now, the IPR issue was
> beaten to death long time back.

It is relevant to the issue of Updates, just as it was during the
MUST/SHOULD/MAY discussions.

> Again, my current understanding (which is inline with Alfred) is
> about "if a draft changes the TCP RFC 793 rules in some way, then it
> is considered as an update and we should mark it accordingly upfront
> for easy reference purposes" Also, update doesn't mean that "all
> TCP's everywhere need to be augumented with the changes". An
> implementer would read the mitigations, AS and the strength of
> recommended mitigations and would make his/her own choice!

Others have shown cases where modifications with more ubiquitous utility
do not carry the Updates tag. There is no evidence this mod is more
deserving of that tag.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 30 Sep 2008 17:35:24 -0700

<snip>
 
> 
> > Agreed that the IPR issue might have had some influence w.r.t the 
> > verbiage on the strength of mitigations. Lars Eggert suggested an 
> > applicability statement to be added, we added the same. Not 
> sure why 
> > you are bringing this up now, the IPR issue was beaten to 
> death long 
> > time back.
> 
> It is relevant to the issue of Updates, just as it was during 
> the MUST/SHOULD/MAY discussions.

Atleast this is the first time I am hearing that IPR issue is relevant to the "updates" issue.

> 
> > Again, my current understanding (which is inline with 
> Alfred) is about 
> > "if a draft changes the TCP RFC 793 rules in some way, then it is 
> > considered as an update and we should mark it accordingly 
> upfront for 
> > easy reference purposes" Also, update doesn't mean that "all TCP's 
> > everywhere need to be augumented with the changes". An implementer 
> > would read the mitigations, AS and the strength of recommended 
> > mitigations and would make his/her own choice!
> 
> Others have shown cases where modifications with more 
> ubiquitous utility do not carry the Updates tag. There is no 
> evidence this mod is more deserving of that tag.

The word deserving comes across quite funny to me! Even though modifications with more ubiquitous utility in the past might have missed the "updates" clause (may be due to hindsight), that is a not a reason why we shouldn't use the "updates" tag for a document which actually updates something in 793, IMO. To quote Alfred : [ sorry, it is easier rather than me framing a new sentence altogether]

"
This WG is chartered for the *MAINTENANCE* of TCP.
If you don't want to make that maintenace visible, you are in danger to dismiss your mission (and the mission of the IETF and its Standards Process).  Since RFCs are immutable, RFC Errata and additions to the RFC metadata are the only ways to make an act of maintenance for a document visible at first place."

Well, 1323 and 2581 was mentioned as mods (if that is what you are referring to above). My reply was :

" FWIW, 1323 talks "TCP extensions for High performance" about window scaling ( a new TCP option), timestamps ( a new TCP option) and PAWS (which "is possible only when you use timestamps), these don't update RFC 793 and just supplements it, IMO.

RFC 1122 standardized the TCP congestion control algorithms and not RFC 793. So if it all 2581 has to update something it had to be 1122 not 793."

Anyways, this is my line of thinking and I haven't heard any convincing arguments so far. 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Sep 2008 17:52:44 -0700

...
> RFC 1122 standardized the TCP congestion control algorithms and not RFC 793.
> So if it all 2581 has to update something it had to be 1122 not 793."
> 

So why do you believe that 2581 updates 1122 and not 793? Or that 1122
wouldn't thus also update 793? Changes to the congestion control
algorithm are equivalent to the changes you propose - they change
behavior (reaction to certain events), but not the fundamental state
machine.

Joe