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