Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 28 Sep 2008 14:08:01 -0700

Alfred,
    I am compiling all the changes including the last call comments into the next revision. I will incorporate all your comments below. 

In particular, regarding your observation of mentioning what the document is doing, I agree that we should mention that it "updates 793". I am hoping that nobody has any objection to this point. 

-Anantha
-----Original Message-----
From: Alfred HÎnes [mailto:[email-masked]] 
Sent: Wednesday, August 13, 2008 11:50 PM
To: Anantha Ramaiah (ananth); [email-masked]; Mitesh Dalal (mdalal)
Cc: [email-masked]
Subject: another review of draft-ietf-tcpm-tcpsecure[-10]

Hello all,
I have once more tried to closely read the latest (-10) version of the 'tcpsecure' draft, and only found a very small number of nits -- see below.

Furthermore, I once more advocate making clear in the document metadata what the document does, by adding to the heading:

    Updates: 793 (if approved)

Doing so will definitely help guide implementers to quickly locate the document once published as an RFC.
By WG consensus, the document is intended for Standards Track, and Sections 3.2, 4.2, and 5.2 clearly state that they update RFC 793; thus, this should be made visible at the metadata level as well.

Nits (in recently added / modified text):

(1)
At the very end of section 1, please change:

              [...] please refer to draft [RFC4953]
                                   ^^^^^^          ^
   to:
              [...] please refer to RFC 4953 [RFC4953].
                                   ^^^^^^^^^          ^
   or:
              [...] please refer to [RFC4953].
                                   ^         ^

(2)
In the first paragraph of section 5.2, please correct two punctuation flaws (missing period, and extraneous apostrophe).
I also have included two minor stylistic improvement below:

                                                    [...].  It needs to
|  be noted that RFC 793 page 72 (fifth check) says : "If the ACK is a
                        ^                          ^^
   duplicate (SEG.ACK < SND.UNA), it can be ignored.  If the ACK
   acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
|  ACK, drop the segment, and return" This mitigation makes the ACK
                                    ^^
   check more stringent since any ACK < SND.UNA wouldn't be accepted,
|  instead only ACK's which are in the range ((SND.UNA - MAX.SND.WND) <=
                   ^^
   SEG.ACK <= SND.NXT) gets through.
---
                                                    [...].  It needs to
|  be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
                        ^^^^                          ^
   duplicate (SEG.ACK < SND.UNA), it can be ignored.  If the ACK
   acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
|  ACK, drop the segment, and return."  This mitigation makes the ACK
                                    ^^^^
   check more stringent since any ACK < SND.UNA wouldn't be accepted,
|  instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) <=
                   ^^
   SEG.ACK <= SND.NXT) gets through.

Note: The quotation comprises multiple sentences; hence the "rational
      quotation" rule of the RFC-Ed does not apply.

IMO, otherwise the draft is ready to go, and because of the importance of the topic, it should now be advanced quickly!

Kind regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| 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: Lars Eggert <[email-masked]>
Date: Mon, 29 Sep 2008 18:26:18 +0300

Hi,

(individual hat on)

On 2008-9-29, at 0:08, ext Anantha Ramaiah (ananth) wrote:
> In particular, regarding your observation of mentioning what the  
> document is doing, I agree that we should mention that it "updates  
> 793". I am hoping that nobody has any objection to this point.

since this document specifies an optional component to TCP, I'd argue  
that it should not update RFC793. If you look at the RFC Editor page,  
almost no other RFC updates RFC793, because even widely-deployed  
extensions (timestamps, SACK, etc.) are all optional. Even RFC2581  
doesn't update RFC793.

Lars

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 29 Sep 2008 09:14:47 -0700

Lars,

Confused here. The TCP timestamps, SACK etc., are NOT specified in RFC 793. Hence they don't update RFC 793 in any sense, these are independent.

Now, RFC 2001 is a separate RFC by itself which was obsoleted by RFC 2581. Yes, this is pretty close since this talks about congestion control which is central to TCP, so may be it updates some sections of RFC 793, I haven't taken a close look.

Tcpsecure on the other hand does update the processing rules of 793 ( pl see sections 3.2, 4.2, and 5.2), and hence Alfred's point makes sense to me. 
FWIW, I never thought about this until Alfred brought this point up, IMO, this is a good point.

-Anantha

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Monday, September 29, 2008 8:26 AM
To: Anantha Ramaiah (ananth)
Cc: Alfred HÎnes; [email-masked]; Mitesh Dalal (mdalal); [email-masked]
Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]

Hi,

(individual hat on)

> 793". I am hoping that nobody has any objection to this point.

since this document specifies an optional component to TCP, I'd argue that it should not update RFC793. If you look at the RFC Editor page, almost no other RFC updates RFC793, because even widely-deployed extensions (timestamps, SACK, etc.) are all optional. Even RFC2581 doesn't update RFC793.

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Sep 2008 10:27:34 -0700

This has been the big issue with this doc from the beginning, and I've
been raising it from the beginning. Other docs describe extensions to
the protocol, but don't change the base protocol. This one does, which
has always been my broadest concern.

It's a little odd to hear anyone think this is the first time this was
raised.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Sep 2008 10:31:10 -0700

Lars,

Is it possible that a SHOULD isn't considered a "updates"?

I.e., there are different issues:

	a) this doc does change the core 793 spec
	b) this doc is optional

(b) argues that we really ought not be using SHOULD, but rather MAY, for
the whole document. I've made that point before, but the label "updates"
may motivate revisiting that issue.

IMO, MAYs don't update, MUSTs definitely do. I don't know where SHOULDs
fall, though.

I.e., I would be comfortable with the current recommendation (SHOULD,
and not "updates"), but if SHOULD implies "updates", I'd suggest
considering going to a level of recommendation that does NOT update 793
(e.g., MAY, if that even suffices).

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 29 Sep 2008 10:37:40 -0700

I think we are losing context here. ( At this stage in the document we don't need a rat-hole here) Alfred's point was :

" 

"

The question is whether or not we should put that phrase in the front. 

-Anantha

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Monday, September 29, 2008 10:28 AM
> Cc: Lars Eggert; [email-masked]; Alfred HÎnes; Mitesh Dalal 
> (mdalal); [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> This has been the big issue with this doc from the beginning, 
> and I've been raising it from the beginning. Other docs 
> describe extensions to the protocol, but don't change the 
> base protocol. This one does, which has always been my 
> broadest concern.
> 
> It's a little odd to hear anyone think this is the first time 
> this was raised.
> 
> Joe
> 
> > Confused here. The TCP timestamps, SACK etc., are NOT 
> specified in RFC 793. Hence they don't update RFC 793 in any 
> sense, these are independent.
> > 
> > Now, RFC 2001 is a separate RFC by itself which was 
> obsoleted by RFC 2581. Yes, this is pretty close since this 
> talks about congestion control which is central to TCP, so 
> may be it updates some sections of RFC 793, I haven't taken a 
> close look.
> > 
> > Tcpsecure on the other hand does update the processing 
> rules of 793 ( pl see sections 3.2, 4.2, and 5.2), and hence 
> Alfred's point makes sense to me. 
> > since this document specifies an optional component to TCP, 
> I'd argue that it should not update RFC793. If you look at 
> the RFC Editor page, almost no other RFC updates RFC793, 
> because even widely-deployed extensions (timestamps, SACK, 
> etc.) are all optional. Even RFC2581 doesn't update RFC793.
> > 
> > Lars
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkjhEAYACgkQE5f5cImnZrvhkgCfQMc0AP8JMGZqXgKhjNZ/LreG
> k7kAoM9M9JgpiYagxzrNjibrCR29fwCy
> =ELvI
> -----END PGP SIGNATURE-----
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 30 Sep 2008 12:43:10 +0300

Hi,

(individual hat on)

> Is it possible that a SHOULD isn't considered a "updates"?

RFC2119 language has nothing to do with the "updates" relationship.  
It's the applicability that matters.

"Updates 793" on document X means "if you implement 793 you also need  
to implement X". That is, because "updates" is typically used when a  
new document fixes critical bugs in an existing specification or adds  
mandatory new functionality.

For this document the applicability statement is basically "SHOULD  
implement when vulnerable, MAY otherwise". That's a conditional  
"updates". Unfortunately, the "updates" header isn't expressive enough  
to convey this.

We're left with two less-than-optimal choices: Add "updates 793",  
which doesn't capture the conditional expressed by the applicability  
statement, or omit "updates 793", which is also inaccurate.

My reason for suggesting to omit the "updates" - and this is a  
personal preference, I'll respect the WG decision and would like to  
head other opinions - is that a plain "updates 793" looks like a "you  
must implement this when implementing 793", and we had a long  
discussion around the applicability statement that seemed to indicate  
that the WG didn't want to make this blanket recommendation.

Lars

PS: As an example, look at the recent RFC5348, which is TFRC. It  
obsoletes RFC3448 (which was the old version of TFRC) but it also  
updates RFC4342 (DCCP's CCID3), which implements TFRC inside DCCP. The  
"updates" relationship here means that CCID3 implementations must now  
(also) implement RFC5348, i.e., the new version of TFRC.

---

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

> (individual hat on)
...
> My reason for suggesting to omit the "updates" - and this is a personal
> preference, I'll respect the WG decision and would like to head other
> opinions - is that a plain "updates 793" looks like a "you must
> implement this when implementing 793", and we had a long discussion
> around the applicability statement that seemed to indicate that the WG
> didn't want to make this blanket recommendation.
> 
> Lars

Right - that's the critical issue, and I agree with your conclusion.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 30 Sep 2008 08:55:03 -0700

[ I don't need to put on a special "hat" I guess ;-), I am commenting as a individual and not as the author]

To me, "updates" is just a quick reference indicating that the current draft contents updates some of the material of the original draft. Now,, nobody would take this as a recommendation or an implementation advice, IMO. The word "updates" cannot be perceived as an override of the applicability statement or the mitigation strengths decsribed in the draft. Therefore, I don't think that the word "updates" has the effect of "if you implement 793 you should also implement this draft". It also doesn't imply a "blanket recommendation" in any sense.

May be it is a good idea to get the opinions of IESG in this matter ?

Thanks,
-Anantha

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Lars Eggert
> Sent: Tuesday, September 30, 2008 2:43 AM
> To: ext Joe Touch
> Cc: Alfred HÎnes; [email-masked]; Anantha Ramaiah (ananth); 
> [email-masked]; Mitesh Dalal (mdalal)
> "Updates 793" on document X means "if you implement 793 you 
> also need to implement X". That is, because "updates" is 
> typically used when a new document fixes critical bugs in an 
> existing specification or adds mandatory new functionality.
> 
> For this document the applicability statement is basically 
> "SHOULD implement when vulnerable, MAY otherwise". That's a 
> conditional "updates". Unfortunately, the "updates" header 
> isn't expressive enough to convey this.
> 
> We're left with two less-than-optimal choices: Add "updates 
> 793", which doesn't capture the conditional expressed by the 
> applicability statement, or omit "updates 793", which is also 
> inaccurate.
> 
> My reason for suggesting to omit the "updates" - and this is 
> a personal preference, I'll respect the WG decision and would 
> like to head other opinions - is that a plain "updates 793" 
> looks like a "you must implement this when implementing 793", 
> and we had a long discussion around the applicability 
> statement that seemed to indicate that the WG didn't want to 
> make this blanket recommendation.
> 
> Lars
> 
> PS: As an example, look at the recent RFC5348, which is TFRC. 
> It obsoletes RFC3448 (which was the old version of TFRC) but 
> it also updates RFC4342 (DCCP's CCID3), which implements TFRC 
> inside DCCP. The "updates" relationship here means that CCID3 
> implementations must now

---

From: David Borman <[email-masked]>
Date: Tue, 30 Sep 2008 10:54:52 -0500

(WG co-chair hats on)

Wes and I discussed this, and we agree with Lars.  "Updates" is  
generally for things that are now required if you implement the cited  
spec.  Tcpsecure doesn't fit that criteria, so the "Updates 793"  
doesn't belong on this document.  As Lars said, this is less than  
perfect, but it is what we currently have.

FWIW, I could only find one RFC that has "Updates 793", and that is  
RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to  
IP", which allocates two of the reserved flags in the TCP header.

			-David & Wes, TCPM WG co-chairs

On Sep 30, 2008, at 4:43 AM, Lars Eggert wrote:

> "Updates 793" on document X means "if you implement 793 you also  
> need to implement X". That is, because "updates" is typically used  
> when a new document fixes critical bugs in an existing specification  
> or adds mandatory new functionality.
>
> "updates". Unfortunately, the "updates" header isn't expressive  
> enough to convey this.
>
> head other opinions - is that a plain "updates 793" looks like a  
> "you must implement this when implementing 793", and we had a long  
> discussion around the applicability statement that seemed to  
> indicate that the WG didn't want to make this blanket recommendation.
>
> Lars
>
> updates RFC4342 (DCCP's CCID3), which implements TFRC inside DCCP.  
> The "updates" relationship here means that CCID3 implementations  
> must now (also) implement RFC5348, i.e., the new version of  
> TFRC._______________________________________________
> tcpm mailing list
> [email-masked]

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 30 Sep 2008 09:43:14 -0700

David/Wes,

I don't intend to prolong this discussion, but the current stance comes across very incurrate.

Based on the example which you gave narrated below :

RFC 3168 used up 2 reserved bits in the TCP header, and hence updated the RFC 793. Now RFC 3168 is optional. This doesn't prevent the fact that "updates" can be used as a qualifier. 

With TCP secure, it changes the processing rules of certain segments (algorithm), so strictly speaking it does update RFC 793. It is optional since none of the conditions is MUST and also there is an AS in place. Here you can't use "updates" since that becomes too strong a word! This beats me.

It appears that we are reading too much into the word "updates" rather than acknowledging its simplicity, i.e, it is just a quick reference point.

So, I guess I am confused as to how and where the lines are drawn. Hence, I think that it would be expedient to seek the advice of IESG as well in this matter. Isn't a good thing ? 

$0.02,
-Anantha
> From: David Borman [mailto:[email-masked]] 
> Sent: Tuesday, September 30, 2008 8:55 AM
> To: Lars Eggert; [email-masked]
> Cc: ext Joe Touch; Alfred HÎnes; Anantha Ramaiah (ananth); 
> Wes and I discussed this, and we agree with Lars.  "Updates" 
> is generally for things that are now required if you 
> implement the cited spec.  Tcpsecure doesn't fit that 
> criteria, so the "Updates 793"  
> doesn't belong on this document.  As Lars said, this is less 
> than perfect, but it is what we currently have.
> 
> FWIW, I could only find one RFC that has "Updates 793", and 
> that is RFC 3168, "The Addition of Explicit Congestion 
> Notification (ECN) to IP", which allocates two of the 
> reserved flags in the TCP header.
> 
> also need 
> > The "updates" relationship here means that CCID3 
> implementations must 
> > now (also) implement RFC5348, i.e., the new version of

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Tue, 30 Sep 2008 12:06:28 -0500

>Behalf Of Anantha Ramaiah (ananth)
>Sent: Tuesday, September 30, 2008 12:43 PM
>
>David/Wes,
>
>RFC 3168 used up 2 reserved bits in the TCP header, and hence 
>updated the RFC 793. Now RFC 3168 is optional. This doesn't 
>prevent the fact that "updates" can be used as a qualifier. 
>
>With TCP secure, it changes the processing rules of certain 
>segments (algorithm), so strictly speaking it does update RFC 
>793. It is optional since none of the conditions is MUST and 
>also there is an AS in place. Here you can't use "updates" 
>since that becomes too strong a word! This beats me.
>
>It appears that we are reading too much into the word 
>"updates" rather than acknowledging its simplicity, i.e, it is 
>just a quick reference point.
>
>So, I guess I am confused as to how and where the lines are 
>drawn. Hence, I think that it would be expedient to seek the 
>advice of IESG as well in this matter. Isn't a good thing ? 

My personal opinion on the number of angels on the head of this
pin is that 3168 redefines bits that were formerly reserved.  Thus
it "updates" the description of those bits in 793 (they're no longer
reserved).  *Regardless* of the fact that 3168 is itself optional,
those bits are no longer available in the way 793 describes.  *That*
is why it has to "update" even though it's optional itself.

The tcpsecure document does not "update" in that sense, as it only
contains optional alternative state machine arcs; the arcs defined
in 793 are still able to be used in the way 793 describes ... they
aren't "updated", but there's now an alternative to them.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 30 Sep 2008 10:46:38 -0700

Wes, 

> aren't "updated", but there's now an alternative to them.

Are you saying that we should construe that "alternate processing" doesn't update the RFC?. Now, the update itself can be optional. In other words, my point is that the current meaning and usage of "updates" is to be used for any updates to the RFC, irrespective of the fact it is minor, major or optional. Agreed that, currently there is fine granularity in describing an update i.e, "minor update, medium update or conditinal update " etc., until such a granularity is available, we should use the existing documented mechanisms. This is the reason I think it would be expedient to seek the advice of IESG in this matter.

Thanks,
-Anantha

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Tue, 30 Sep 2008 12:58:00 -0500

>From: Anantha Ramaiah (ananth) [mailto:[email-masked]] 
>Sent: Tuesday, September 30, 2008 1:47 PM
>To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert; 
>[email-masked]
>Cc: Alfred HÎnes; Mitesh Dalal (mdalal); [email-masked]; 
>ext Joe Touch
>Subject: RE: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
>
>Wes, 
>
>> 
>> 
>Are you saying that we should construe that "alternate 
>processing" doesn't update the RFC?. Now, the update itself 
>can be optional. In other words, my point is that the current 
>meaning and usage of "updates" is to be used for any updates 
>to the RFC, irrespective of the fact it is minor, major or 
>optional. Agreed that, currently there is fine granularity in 
>describing an update i.e, "minor update, medium update or 
>conditinal update " etc., until such a granularity is 
>available, we should use the existing documented mechanisms. 
>This is the reason I think it would be expedient to seek the 
>advice of IESG in this matter.

My position is very simple:
What part of RFC 793 is no longer correct?  Which text is no
longer accurate in RFC 793?

With ECN, it's very clear, the answer is "the 2 reserved bits
are not reserved anymore".  With tcpsecure, the answer is also
very clear: "nothing".  You need to point to some part of 793
that is actually updated and not just alternatively defined,
IMO.  If 2581, 1323, and others don't update 793, then I don't
see how tcpsecure can have any valid claim to.

That's just my personal opinion, though.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 30 Sep 2008 13:47:44 -0700

> >Are you saying that we should construe that "alternate processing" 
> >doesn't update the RFC?. Now, the update itself can be optional. In 
> >other words, my point is that the current meaning and usage of 
> >"updates" is to be used for any updates to the RFC, 
> irrespective of the 
> >fact it is minor, major or optional. Agreed that, currently there is 
> >fine granularity in describing an update i.e, "minor update, medium 
> >update or conditinal update " etc., until such a granularity is 
> are not reserved anymore".  With tcpsecure, the answer is 
> also very clear: "nothing".  You need to point to some part 
> of 793 that is actually updated and not just alternatively 
> defined, IMO.  If 2581, 1323, and others don't update 793, 
> then I don't see how tcpsecure can have any valid claim to.

So, in other words, are we saying that only changes to TCP header is considered as an update and not the stuff that changes the semantics ? This is probably a general question w.r.t updates, nothing specific to 793 update.

"Alternatively defined" is also trying to change the RFC 793 semantics i.e, in the current case segment processing rules w.r.t RST, SYN and Data. 

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

> That's just my personal opinion, though.

Sure, my opinion is similar but I am confused with the meaning and applicability of the term "updates". We need to have a consistent story. That is the reason I suggested seeking IESG advice in this matter.

-Anantha

---

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

> That's just my personal opinion, though.

This makes sense to me.

Joe