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

From: David Borman <[email-masked]>
Date: Wed, 1 Oct 2008 14:33:29 -0500

Ok, Wes and I count four opinions against and two opinions for having  
"Updates: 793" in the header of tcpsecure.  Unless other folks chime  
in, the resolution we see is:

1) "Updates: 793" is not put in the header of tcpsecure
2) When we send tcpsecure up to the IESG, we will note this issue and  
the discussion, and if the IESG feels that is appropriate to have  
"Updates: 793" in the header, then it can be added in.

We think everyone has been heard and understood, but don't see this  
conversation coming to full agreement.

			-David Borman & Wes Eddy, TCPM co-chairs

On Sep 30, 2008, at 5:03 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
>>> -----Original Message-----
>>> 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,
>>>
>>>>
>>>> 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.
>>> 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.
>
>
> This makes sense to me.
>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkjioioACgkQE5f5cImnZrvyfACgk+tXUy6Q1TdshUpvN9Zixv/i
> 2FEAoNoBwdYFzVM+r0wokwbAaJKLJ3PI
> =q5ru
> -----END PGP SIGNATURE-----

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

---

From: "Mitesh Dalal (mdalal)" <[email-masked]>
Date: Wed, 1 Oct 2008 16:15:29 -0700

vote for updates. 

I personally feel we are reading too much into the updates lingo. 
I didn't care one way or the other until somebody (Alfred ?) brought 
this up. Given that this is standards track document, the entire 
interne community will be well served if we clearly highlight where
we are coming from. Updates in my mind does not mean a tcp V2 
nor it means MUST implement. It simply means a new piece of 
information found that concerns a base spec and sheds some new
light on it.

Thanks
Mitesh 

> From: David Borman [mailto:[email-masked]] 
> Sent: Wednesday, October 01, 2008 12:33 PM
> To: [email-masked]
> Cc: Eddy, Wesley M. (GRC-RCN0)[VZ]; Anantha Ramaiah (ananth); 
> Lars Eggert; Alfred HÎnes; Mitesh Dalal (mdalal); Randy 
> Stewart; Joe Touch
> Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
> 
> "Updates: 793" in the header of tcpsecure.  Unless other 
> folks chime in, the resolution we see is:
> 
> 2) When we send tcpsecure up to the IESG, we will note this 
> issue and the discussion, and if the IESG feels that is 
> appropriate to have
> We think everyone has been heard and understood, but don't 
> see this conversation coming to full agreement.
> 
> >>> Cc: Alfred HÎnes; Mitesh Dalal (mdalal); 
> [email-masked]; ext 
> >>> Joe Touch
> >>>> 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 
> 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.
> >>
> >>
> >> 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.
> >>

---

From: Ted Faber <[email-masked]>
Date: Wed, 1 Oct 2008 17:16:25 -0700

> vote for updates. 

I do not believe this draft updates 793.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Murali Bashyam" <[email-masked]>
Date: Wed, 1 Oct 2008 17:25:23 -0700

It seems to me that if the rules of the processing of TCP segments are
modified , then it updates RFC 793. By that definition, this draft does
revise RFC 793  especially w.r.t handling rules for those (SYN , RST)
segments. My vote is for having "Updates : 793" in the header.

On Wed, Oct 1, 2008 at 12:33 PM, David Borman <[email-masked]>wrote:

> "Updates: 793" in the header of tcpsecure.  Unless other folks chime in, the
> resolution we see is:
>
> 2) When we send tcpsecure up to the IESG, we will note this issue and the
> discussion, and if the IESG feels that is appropriate to have "Updates: 793"
> in the header, then it can be added in.
>
>>>>> it "updates" the description of those bits in 793 (they're no longer
>>>>> those bits are no longer available in the way 793 describes.  *That*

-- 
Rgds,
Murali Bashyam
(c) (510)6736915

----------------------------- CONFIDENTIAL  --------------------
*****************************************************
This telecommunication and any data attached to, or included in it
is considered confidential, and is intended only for use by the named
recipient. The contents may be legally protected as any one or more of:
copyrighted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any other legally available means. If you received this material in
error, please notify the sender and destroy the original and all copies,
whether electronic or otherwise. Thank you.
*****************************************************

---

From: Lars Eggert <[email-masked]>
Date: Thu, 2 Oct 2008 19:55:49 +0300

Hi,

FYI, Pasi Eronen pointed me at RFC2223, which defines what "updates"  
means. In Section 12, it says:

    12.  Relation to other RFCs

    Sometimes an RFC adds information on a topic discussed in a previous
    RFC or completely replaces an earlier RFC.  There are two terms used
    for these cases respectively, Updates and Obsoletes.  A document  
that
    obsoletes an earlier document can stand on its own.  A document that
    merely updates an earlier document cannot stand on its own; it is
    something that must be added to or inserted into the previously
    existing document, and has limited usefulness independently.  The
    terms Supercedes and Replaces are no longer used.

    Updates

       To be used as a reference from a new item that cannot be used
       alone (i.e., one that supplements a previous document), to refer
       to the previous document.  The newer publication is a part that
       will supplement or be added on to the existing document; e.g., an
       addendum, or separate, extra information that is to be added to
       the original document.

Nothing in that text talks about conditional applicability, and the  
argument that tcpsecure is an addendum to be added as an optional  
component to RFC793 can be made.

The unfortunate thing is that the IETF's running code has been  
different from what RFC2223 describes, at least to some degree even  
back then and certainly since. I other words, according to the  
definition in RFC2223, many more RFCs should have been updating RFC793  
over the years, not to speak of other RFC/protocol families.

Lars

---

From: Stefanos Harhalakis <[email-masked]>
Date: Thu, 2 Oct 2008 20:10:59 +0300

> information found that concerns a base spec and sheds some new

When I read 'updated by' for an RFC I understand that if I want to implement a 
current version of that RFC then I need to also read the 'updated by' 
document. 

A good example is RFC 4032 (Update to the Session Initiation Protocol (SIP)) 
which says:

(Abstract)
   This document updates RFC 3312, which defines the framework for
   preconditions in SIP.  We provide guidelines for authors of new
   precondition types and describe how to use SIP preconditions in
   situations that involve session mobility.

(Introduction)
   This document updates RFC 3312,  provides guidelines for authors of
   new precondition types and explains which topics they need to discuss
   when defining them.  In addition, it updates some of the procedures
   in RFC 3312 for using SIP preconditions in situations that involve
   session mobility as described below.

Since tcpsecure does something simillar it may just need a sentence like "This 
document updates RFC 793 blah blah". The rationale is that whoever implements 
a current version of RFC 793 should also have in mind tcpsecure.

So, FWIW, I believe that tcpsecure should update RFC 793.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 10:19:29 -0700

FWIW, we're dealing not only with what RFC2223 says in this regard, but
the current IETF culture of when to use "updates".

As I've noted, there are other extensions to TCP that are more "updates"
than this. We have a roadmap document to more clearly explain the
relationship of components to 793; when that document is updated,
tcpsecure should be added to that. Given the complexity of that
document, this label isn't going to help, and IMO will misdirect
implementers to include this where it wasn't necessary.

I see no reason to lead the charge of changing IETF culture on this
issue with this document, and specific reasons NOT to use this document
as the defining case.

Joe

Lars Eggert wrote:
>    for these cases respectively, Updates and Obsoletes.  A document that
> The unfortunate thing is that the IETF's running code has been different
> from what RFC2223 describes, at least to some degree even back then and
> certainly since. I other words, according to the definition in RFC2223,
> many more RFCs should have been updating RFC793 over the years, not to
> speak of other RFC/protocol families.
> 
> Lars

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 2 Oct 2008 19:34:57 +0200 (MESZ)

In <[email-masked]>, Lars Eggert wrote:

> ...
> definition in RFC2223, many more RFCs should have been updating
> RFC793 over the years, not to speak of other RFC/protocol families.
> 
> Lars

That's exactly what I personally feel and 'preach', also based on
feedback from networking practitioners not familar with the details
of the procedures within the IETF -- also our 'customers', isn't it?

Nevertheless, quit a couple of such "Updates" <--> "Updated by"
metadata relationships have been added to the RFC index
'after the fact', based on RFC Errata and less formal discussion,
and the last such addition I am aware of happened only a few weeks ago.

BTW:
 The personal copy of the RFC index I maintain contains additional
 tags like "eff. Updated by ...", "eff. Historic",  etc.
 [For anybody wanting to be assured, "eff." stands for "effectively".]

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: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 2 Oct 2008 10:52:04 -0700

> Given the 
> complexity of that document, this label isn't going to help, 
> and IMO will misdirect implementers to include this where it 
> wasn't necessary.

We have already addressed the "mis-direction" case, by adding the qualifiers (SHOULD, MAY etc.,) and more importantly the applicability statement. Actually not adding "updates" would mis-direct the implementers, IMO.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 10:59:10 -0700

> We have already addressed the "mis-direction" case, by adding the qualifiers (SHOULD, MAY etc.,) and more importantly the applicability statement. Actually not adding "updates" would mis-direct the…

Presumably we agree that most current mods to 793 don't include "Updates."

By that logic, adding "Updates" here flags this as more important or
more relevant than the current mods. Since I do not believe that is
accurate, that is the kind of misdirection I'm speaking to.

Joe

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Thu, 2 Oct 2008 12:59:42 -0500

>From: Joe Touch [mailto:[email-masked]] 
>Sent: Thursday, October 02, 2008 1:19 PM
>

It's just my personal opinion, but I'm in full agreement with Joe.
Further, I think that if people are interpreting "updates" as "we
should read and consider implementing", then I'm especially hesitant
to have IPR-encumbered documents "update" 793, as it becomes an
advertisement attached to the base of TCP.

I also feel that tcpsecure is really a stop-gap to handle packets
with spoofed addresses, that could've/should've been caught
elsewhere (RFC 4953) and in more powerful ways (ingress filters,
ipsec, md5, gtsm, etc.) depending on deployment particulars.  It
happens to be a nice and effective stop-gap, but the long-term
solution is to make spoofed packets become nonexistent, at which
point we'll no longer need tcpsecure.

---

From: David Borman <[email-masked]>
Date: Thu, 2 Oct 2008 14:12:00 -0500

At this point I count 5 for (Alfred, Anantha, Mitesh, Murali &  
Stefanos) and 5 against (Lars, Joe, David, Wes & Ted).  We have  
conflicting interpretations of what "Updates" means; what is written  
down in the RFC index and in RFC 2223, what as been done in practice,  
and personal opinions.  I don't see those converging on the TCPM  
mailing list.  So, whether or not "Updates: 793" is put into the  
draft, this issue will be explicitly noted when it is sent up to the  
IESG.
			-David Borman

On Oct 1, 2008, at 2:33 PM, David Borman wrote:

> Ok, Wes and I count four opinions against and two opinions for  
> having "Updates: 793" in the header of tcpsecure.  Unless other  
> 2) When we send tcpsecure up to the IESG, we will note this issue  
> and the discussion, and if the IESG feels that is appropriate to  
> have "Updates: 793" in the header, then it can be added in.
>

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Thu, 2 Oct 2008 22:25:54 -0700

> "Updates: 793" in the header, then it can be added in.

  My opinion is that since we believe these are 'good changes' and would
  expect newer code to follow these recomendataions, 'Updates' would be
  appropriate. (Off late, we, the IETF are so caught up in just defining
  words that it is hard to take a position on anything clearly :).. my
  choice is simply based on whether I will put this into code or not...
  I have no clue how the IESG may think and it seems that it will probably
  just 'veto' one of the choices, based on their wisdom, on this anyway)

  Regards,
  Chandra.

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 22:30:30 -0700

Chandrashekhar Appanna wrote:
>   appropriate. 

That's exactly what I don't expect. I expect these mods to be deployed
ONLY where necessary, not in all newer code, FWIW. The idea that this is
generally useful is the kind of misperception I would like to avoid...

Joe

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Thu, 2 Oct 2008 22:44:36 -0700

> generally useful is the kind of misperception I would like to avoid...
  Joe :)

  While I do notice that you embody 'TCPM', and the chairs are just
  window dressing I would prefer that you
  let us provide out opinions and not jump in to mischaracterize my
  words to your ends ;)

  I __did not__ say anthying to imply generally useful. But to _me_
  code is key.. it may be that you are more interested in a purely
  academic angle which does not affect the 'working internet'.. now
  I am putting words in your mouth.. are'nt I?

  Regards,
  Chandra.

> iEYEARECAAYFAkjlrfUACgkQE5f5cImnZrtMsQCfYjyH2vnVgEteELEXV1G+w70Q
> seAAoIc23DQmZ8h88NRqdxmuWnD58vfa
> =DUXb

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 23:27:29 -0700

>>   I am putting words in your mouth.. are'nt I?

The working Internet is composed of more than just routers - at least
that's what I teach my students. ;-)

You made the case that newer code would add this mod. That implies
generality I think should be avoided.

Joe

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Thu, 2 Oct 2008 23:44:16 -0700

> that's what I teach my students. ;-)

  Well.. good I guess ;)

> generality I think should be avoided.

  When I have some time, I will think through what you think I must
  have meant but for now..

  My opinion as written stands and is directed to the chairs for the
  question they posed. 

  Chandra.
 
> iEYEARECAAYFAkjlu1EACgkQE5f5cImnZrvbAwCgqeCmiyvqDR2lXcqAWec4HC1K
> fHkAoIPvQvgeatS0mam1LoSTRdEWiKry
> =xV9q

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 3 Oct 2008 10:20:59 +0200

Trouble is, the long-standing precedent is not to specify 'Updates: 793'

Underlying that, the update tree (mesh?) for TCP is so complex that it needs
another representation, such as RFC4614 so perhaps 'Updates: 4614'; or
RFC4614bis before too long?

Tom Petch

----- Original Message -----

From: "Lars Eggert" <[email-masked]>
To: "ext Joe Touch" <[email-masked]>
Cc: "Alfred HÎnes" <[email-masked]>; <[email-masked]>; "ext Anantha Ramaiah
(ananth)" <[email-masked]>; <[email-masked]>; "Mitesh Dalal (mdalal)"
<[email-masked]>
Sent: Tuesday, September 30, 2008 11:43 AM
Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]