Re: [Tcpcrypt] New version of the charter text
Tero Kivinen <kivinen@iki.fi> Mon, 05 May 2014 13:31 UTC
Return-Path: <kivinen@iki.fi>
X-Original-To: tcpcrypt@ietfa.amsl.com
Delivered-To: tcpcrypt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6456D1A0326 for <tcpcrypt@ietfa.amsl.com>; Mon, 5 May 2014 06:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPknnxwXorJK for <tcpcrypt@ietfa.amsl.com>; Mon, 5 May 2014 06:31:01 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 080591A032D for <tcpcrypt@ietf.org>; Mon, 5 May 2014 06:31:00 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.7) with ESMTP id s45DUj4J015507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 May 2014 16:30:45 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.7/Submit) id s45DUhNB003564; Mon, 5 May 2014 16:30:43 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21351.37507.317352.47211@fireball.kivinen.iki.fi>
Date: Mon, 05 May 2014 16:30:43 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Joe Touch <touch@isi.edu>
In-Reply-To: <53611219.2030106@isi.edu>
References: <53576572.5030805@it.uc3m.es> <53589161.4090700@mti-systems.com> <20140424155532.GR43976@funkthat.com> <21342.18899.736731.804370@fireball.kivinen.iki.fi> <535E71E8.6020001@isi.edu> <21344.65512.465866.311361@fireball.kivinen.iki.fi> <53611219.2030106@isi.edu>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 15 min
X-Total-Time: 16 min
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/bi5aaisEp_NKRNI3MnpoQkjjt7w
Cc: Wesley Eddy <wes@mti-systems.com>, John-Mark Gurney <jmg@funkthat.com>, tcpcrypt@ietf.org
Subject: Re: [Tcpcrypt] New version of the charter text
X-BeenThere: tcpcrypt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpcrypt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpcrypt>, <mailto:tcpcrypt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpcrypt/>
List-Post: <mailto:tcpcrypt@ietf.org>
List-Help: <mailto:tcpcrypt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpcrypt>, <mailto:tcpcrypt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 13:31:03 -0000
Joe Touch writes: > > If the out-of-order packet is delayed by more than 5-10 seconds before > > it finally arrive to the other peer, it might already be dropped by > > the replay window checks (depending how big window you are using), and > > it would most likely already been considered as being lost by the > > upper layers. > > But in that case the replay prevention would be dropping packets that > could be valid (i.e., they're only replayed if the particular byte range > overlaps, but merely if it's "earlier than expected". That is not related to the rekey. For rekey each SA have separate replay windows, so that is not on issue there. I meant that if you have situation where the network commonly delays packets for 5 seconds and send them all out of order then that will quite often cause IPsec replay window to drop the packets which are too old. The IPsec replay window size is normally something like 32-128 packets so after you the peer has received that many newer packets it will drop the old packet when it arrives. > > I.e. in normal case there is no lost packets. > > You just said that replay would drop them - that's a drop TCP would see > too. The normal case we were talking about is a rekey case, and rekey normally do not loose any packets. Replay window will drop packets in general (i.e. cases not related to rekey) if packets get too much out of order. Thats why IPsec architecture asks you to create separate SAs for cases where packets might get delayed different amounts. I.e. one IPsec SA per traffic class if you are doing class based QoS etc. IPsec rekey does not cause packets to be lost. Also TCP usually will already do actions when it sees that one packet has not been received for 5 seconds and there has been other newer packets coming in all the time (i.e. do SACK and that will cause the other end to retransmit the packet when it receives that information, and if both of the packets do arrive to the other end then later one of them is simply dropped, as TCP has already received the earlier one). Anyways I think we are getting quite far away from the charter text. -- kivinen@iki.fi
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text Scharf, Michael (Michael)
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text John-Mark Gurney
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text Tero Kivinen
- Re: [Tcpcrypt] New version of the charter text Wesley Eddy
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text Wesley Eddy
- Re: [Tcpcrypt] New version of the charter text John-Mark Gurney
- Re: [Tcpcrypt] New version of the charter text Wesley Eddy
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text ianG
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text ianG
- Re: [Tcpcrypt] New version of the charter text Tony Arcieri
- Re: [Tcpcrypt] New version of the charter text Stephen Farrell
- Re: [Tcpcrypt] New version of the charter text ianG
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text ianG
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text Tero Kivinen
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text Tero Kivinen