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

"Murali Bashyam" <mbcoder@gmail.com> Thu, 02 October 2008 00:25 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65213A69C6; Wed, 1 Oct 2008 17:25:01 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF8D3A69C6 for <tcpm@core3.amsl.com>; Wed, 1 Oct 2008 17:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsYEDD3VPcXR for <tcpm@core3.amsl.com>; Wed, 1 Oct 2008 17:24:59 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id AF87F3A69B1 for <tcpm@ietf.org>; Wed, 1 Oct 2008 17:24:59 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so757703rvf.49 for <tcpm@ietf.org>; Wed, 01 Oct 2008 17:25:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=P56xihvVhDCVvnr6K7eX4gpl/1czbMuiPAvD7U5nAOw=; b=UWcyFefan9E158TLvHauCTTLBXIPgwO9+K8HNVFpER6zKa91KbLLbItZpf/xI4zZ37 sYUaCcegPxHP9tWVnXVn+HdCjeie4O57lyjTG7vhGqfAW1wzP4EoZm720Qg3l3IdSYw4 LKYgQZTy4bNcvw44lCdEk/LFggo5FeHDeUsQg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=MmLwelEn0fePupXRlkpgLhHcoUX1FTHm/gjLucLBohbZl1/Tqbw7rQZnl5xBNrVlYz K65bAxCSdBI1gjDQMpwd5BxNA7LYVej0QA64bSPHHDEztIa3m6GWtMMfpytMgfeXXRoS wA5ILs1VtWFqz4rfy1AahIqyNPMtz8mkwyR+k=
Received: by 10.142.229.5 with SMTP id b5mr3603751wfh.50.1222907123951; Wed, 01 Oct 2008 17:25:23 -0700 (PDT)
Received: by 10.142.116.4 with HTTP; Wed, 1 Oct 2008 17:25:23 -0700 (PDT)
Message-ID: <9c8209a10810011725u5014bf04tceef1608fa79ca31@mail.gmail.com>
Date: Wed, 1 Oct 2008 17:25:23 -0700
From: "Murali Bashyam" <mbcoder@gmail.com>
To: "David Borman" <david.borman@windriver.com>
In-Reply-To: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com>
MIME-Version: 1.0
References: <200808140650.IAA05627@TR-Sys.de> <48E110DE.8050903@isi.edu> <724ED3DF-B4E5-4FF8-93BF-5B84688CC940@nokia.com> <3B570CE3-309B-4473-9A19-99905A93986A@windriver.com> <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com> <B5A5E01F9387F4409E67604C0257C71E56038C@NDJSEVS25A.ndc.nasa.gov> <0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <B5A5E01F9387F4409E67604C0257C71E5603CD@NDJSEVS25A.ndc.nasa.gov> <48E2A22A.8000209@isi.edu> <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com>
Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= <ah@tr-sys.de>, tcpm@ietf.org, Joe Touch <touch@isi.edu>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, Randy Stewart <randall@lakerest.net>, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy@nasa.gov>
Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0858902306=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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 <david.borman@windriver.com>wrote;wrote:

> 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:ananth@cisco.com]
>>>> Sent: Tuesday, September 30, 2008 1:47 PM
>>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert;
>>>> tcpm@ietf.org
>>>> Cc: Alfred HÎnes; Mitesh Dalal (mdalal); randall@lakerest.net;
>>>> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>



-- 
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.
*****************************************************
------------------------------ CONFIDENTIAL  --------------------
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm