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

Lars Eggert <lars.eggert@nokia.com> Wed, 06 August 2008 14:06 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 0BA553A6891; Wed, 6 Aug 2008 07:06:21 -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 81AA03A6891 for <tcpm@core3.amsl.com>; Wed, 6 Aug 2008 07:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Level:
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 SFLigVf+PVNj for <tcpm@core3.amsl.com>; Wed, 6 Aug 2008 07:06:18 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 86D653A63D3 for <tcpm@ietf.org>; Wed, 6 Aug 2008 07:06:18 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m76E4Oc4000674; Wed, 6 Aug 2008 09:06:31 -0500
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 17:06:29 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 17:06:21 +0300
Received: from [192.168.1.116] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 17:06:20 +0300
Message-Id: <045CB0E7-78B2-49B8-91C9-B2AB19C47A05@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Eric Rescorla <ekr@networkresonance.com>
In-Reply-To: <20080806133734.7721D527252@kilo.rtfm.com>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Wed, 06 Aug 2008 17:06:14 +0300
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>
X-Mailer: Apple Mail (2.926)
X-OriginalArrivalTime: 06 Aug 2008 14:06:21.0196 (UTC) FILETIME=[9A77D4C0:01C8F7CD]
X-Nokia-AV: Clean
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"; DelSp="yes"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On 2008-8-6, at 16:37, ext 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 don't think we need to require that the new key be used. I was  
trying to argue that we shouldn't require that the old key be used.

> I don't know a lot about
> TCP stack implementations, but do any of them currently save
> existing packets and just retransmit them? That's legal, right?
> If so, this would break that.

I don't think saving sent segments makes a lot of sense. It may work,  
but ACK/SACK and timestamp information of the old packets would be out  
of sync relative to the current connection state, so I'd expect there  
could at the very least be inefficiencies. Unless I'm misremembering,  
all the stacks that I'm familiar with create a new segment for  
retransmitting lost data with TCP control information that accurately  
reflects the current connection state.

Lars

> I would argue that if we are to use internal key rollover to handle
> seqno rollover that you then use the old key even when you  
> retransmit. [0]
> Otherwise, you end up with ambiguity about which key is in play.
>
> -Ekr
>
> [0] Incidentally, this is an argument for ESNs, I believe. If you
> have a key-id transition at the same time as a seqno rollover, you
> might have ambiguity about whether the key had rolled over in
> between in the face of packet loss.
>
>
>

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