Re: [tcpm] tcp-auth-opt issue: replay protection

Ron Bonica <rbonica@juniper.net> Fri, 08 August 2008 17:32 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 BEA8B3A6D59; Fri, 8 Aug 2008 10:32:42 -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 C86453A6D52 for <tcpm@core3.amsl.com>; Fri, 8 Aug 2008 10:32:41 -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 rSiENxqdJw50 for <tcpm@core3.amsl.com>; Fri, 8 Aug 2008 10:32:41 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 554123A6D58 for <tcpm@ietf.org>; Fri, 8 Aug 2008 10:32:35 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 10:32:31 PDT
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 10:32:24 -0700
Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 10:32:24 -0700
Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 13:32:23 -0400
Received: from [172.28.13.57] ([172.28.13.57] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 13:32:22 -0400
Message-ID: <489C8323.70605@juniper.net>
Date: Fri, 08 Aug 2008 13:32:19 -0400
From: Ron Bonica <rbonica@juniper.net>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <F32F8EC5-70C9-4A7B-A2D2-B00CA43AECFA@nokia.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> <48935983.80701@isi.edu> <3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com> <20080806133734.7721D527252@kilo.rtfm.com>
In-Reply-To: <20080806133734.7721D527252@kilo.rtfm.com>
X-Enigmail-Version: 0.95.6
X-OriginalArrivalTime: 08 Aug 2008 17:32:22.0894 (UTC) FILETIME=[B770C0E0:01C8F97C]
Cc: Adam Langley <agl@imperialviolet.org>, tcpm@ietf.org, ext Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] tcp-auth-opt issue: replay protection
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org


Eric Rescorla wrote:
> At Wed, 6 Aug 2008 14:32:02 +0300,
> Lars Eggert wrote:
>> On 2008-8-1, at 21:44, ext Joe Touch wrote:
>>> IMO: retransmitted packets would use the currently active keyID  
>>> (even if
>>> different from what was previously transmitted).
>> I agree. TCP retransmits previous data, not previous segments.
> 
> I agree it should be permissible to use the new key-id, but
> should it be required? 

I think that implementations SHOULD use the new key, but MAY use the old 
one, too. Either should work, so long as the receiving system doesn't 
delete the old key too quickly after having obsoleted it.

                                 Ron
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm