Re: [tcpm] TCP-AO review comments.

Chandrashekhar Appanna <achandra@cisco.com> Mon, 04 August 2008 18:45 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 8333E3A691E; Mon, 4 Aug 2008 11:45:36 -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 8DD593A68E8 for <tcpm@core3.amsl.com>; Mon, 4 Aug 2008 11:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 pAJCVm1iG6AH for <tcpm@core3.amsl.com>; Mon, 4 Aug 2008 11:45:33 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DC0623A6BAA for <tcpm@ietf.org>; Mon, 4 Aug 2008 11:45:31 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,306,1215388800"; d="scan'208";a="61299003"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2008 18:45:58 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m74IjwNk031353; Mon, 4 Aug 2008 11:45:58 -0700
Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m74IjwP5013642; Mon, 4 Aug 2008 18:45:58 GMT
Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA07075; Mon, 4 Aug 2008 11:45:52 -0700 (PDT)
Date: Mon, 4 Aug 2008 11:45:52 -0700
From: Chandrashekhar Appanna <achandra@cisco.com>
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <wesley.m.eddy@nasa.gov>
Message-ID: <20080804184552.GG29466@cisco.com>
References: <48971214.6070303@isi.edu> <B5A5E01F9387F4409E67604C0257C71E324E65@NDJSEVS25A.ndc.nasa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <B5A5E01F9387F4409E67604C0257C71E324E65@NDJSEVS25A.ndc.nasa.gov>
User-Agent: Mutt/1.4i
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3140; t=1217875558; x=1218739558; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20<achandra@cisco.com> |Subject:=20Re=3A=20[tcpm]=20TCP-AO=20review=20comments. |Sender:=20; bh=O5lVdojCla5DfR0GXZJ+82nUjs/s3FxcI13UiUO6J7g=; b=Ww8N0LjHD75TCtQPiz2Q7kk7EfSVbvVzwFVyb96U1q+8HSw7QMJGITv3Ll FHXnsam2h4yJrwJP9M+Q2mh0lxj75cfe7JHrOau4nprfjcdy2Ph7SOU80oP5 /zCHzVTBb2etP3vL591FLgheGpcTLGCTzcLPSvX8786xDktmVDZVw=;
Authentication-Results: sj-dkim-1; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Cc: tcpm@ietf.org, Joe Touch <touch@ISI.EDU>
Subject: Re: [tcpm] TCP-AO review comments.
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Mon, Aug 04, 2008 at 10:01:39AM -0500, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> >-----Original Message-----
> >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> >Behalf Of Joe Touch
> >Sent: Monday, August 04, 2008 10:29 AM
> >
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Hi, Ananth,
> >
> >Just a few remaining points to clarify...
> >
> >Anantha Ramaiah (ananth) wrote:
> >|> | #1
> >|> |    I have problem with the term "obsoletes 2385" [ I did
> >|> bring this up
> >|> | before] It is going to be a long time before deployments
> >|> move over to
> >|> | the new TCP auth option.
> >|>
> >|> Practically, "obsoletes" doesn't obsolete anything. It does
> >|> indicate that the IETF wants a protocol to be replaced by
> >|> something else. That doesn't mean the older one can't be used
> >|> for legacy support, e.g., AFAICT - and that clearly should
> >|> apply here. If the IESG thinks that this is consistent with
> >|> "Obsoltes", would that be OK?
> >|
> >| Sure, ok let me rephrase the question here : "TCP MD5 option would
> >| continue to exist and should be supported for quite sometime" Does
> >| "obselete" allow this fact?
> >
> >My impression is that it does, i.e., it recommends replacement, but
> >doesn't prevent it being used for legacy purposes.
> >
> >< I would have preferred "Updates/Revises"
> >| which gives some leeway for co-existence to support legacy.
> >
> >We're not changing anything in TCP MD5, so we neither update 
> >nor revise it.
> >
> >It seems like those of us replying are in agreement on this overall
> >point, but don't quite know what the best language to use is (if others
> >want to debate that point, though, please do). It might be 
> >useful to ask
> >the IESG for advice (which I will do).
> 
> 
> 
> I think that "obsoletes" is correct.  There are problems with 2385, and
> AO is the solution that we're creating to replace it.  We *do* want to
> discourage 2385 use when AO is ready, so obsoleting seems like the right
> thing to do.  Of course someone could still use 2385; the status of a
> document has no power over what's in an implementation or enabled in a
> deployment, we just don't want to encourage it.
>

  Not sure if this will obselete that.. this is a new option with different
  goals and we are not even sure if at this point how much consensus there
  is about moving AO forward.. there is much discussion on the keying aspects,
  the design team seems to be just one person speaking up mostly; and
  given the comments from other design team members at the mike at the ietf
  I would not be in favour of making AO obselete the other method.. like you
  say the status of the document has no power and therefore it is better
  to not think it has some if it does not line up ;).. forcing a document
  through without the implied working code and rough consensus may end up
  doing more harm to the doc itself..

  Rgds,
  Chandra. 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm