Re: [IPsec] Updated version of RFC5996bis

Paul Wouters <paul@cypherpunks.ca> Thu, 17 October 2013 15:22 UTC

Return-Path: <paul@cypherpunks.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79E021F9EB6 for <ipsec@ietfa.amsl.com>; Thu, 17 Oct 2013 08:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level:
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Amf6TvM1a5Hr for <ipsec@ietfa.amsl.com>; Thu, 17 Oct 2013 08:22:46 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id F2E1321F9EB0 for <ipsec@ietf.org>; Thu, 17 Oct 2013 08:22:43 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d0vJJ597szCCm; Thu, 17 Oct 2013 11:22:40 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id dKdfCyu5EjV6; Thu, 17 Oct 2013 11:22:40 -0400 (EDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 17 Oct 2013 11:22:39 -0400 (EDT)
Received: by bofh.nohats.ca (Postfix, from userid 500) id AB7BC800C4; Thu, 17 Oct 2013 11:22:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9D6E580097; Thu, 17 Oct 2013 11:22:40 -0400 (EDT)
Date: Thu, 17 Oct 2013 11:22:40 -0400
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: Yoav Nir <ynir@checkpoint.com>
In-Reply-To: <D10154ED-78C8-4FB7-8C49-5DDFC123C56B@checkpoint.com>
Message-ID: <alpine.LFD.2.10.1310171106550.27671@bofh.nohats.ca>
References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <alpine.LFD.2.10.1310171004250.29460@bofh.nohats.ca> <D10154ED-78C8-4FB7-8C49-5DDFC123C56B@checkpoint.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, Tero Kivinen <kivinen@iki.fi>
Subject: Re: [IPsec] Updated version of RFC5996bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2013 15:22:53 -0000

On Thu, 17 Oct 2013, Yoav Nir wrote:

> On Oct 17, 2013, at 5:13 PM, Paul Wouters <paul@cypherpunks.ca> wrote:
>> While updating the retransmit timers in libreswan, I found no useful
>> information in 5996. Is that something we could add? I know it is
>> local policy but perhaps it would be good to add some guidance for
>> implementors. Do people use sub-second retries? exponential backoff?
>> How do people deal with slow wakeup stacks (eg 3G) and preventing of
>> firsts of duplicate first packets?
>
> I agree with Yaron. The only guidance is "at least 12 retransmission over at least two minutes"

I guess I was hoping for more operation experiences. I was not asking
for specific values, but for some more guidance.

> To be sure, I'm using a laptop connected to a smartphone hotspot, connected to a 3G cellular network from a moving train half-way around the world. But still, sub-second retries would have you send unnecessary retransmissions, and packet loss is pretty low.

Yet some implementations do sub-second retries. Packet loss is high
within the first second when you are waking up your 3G chipset for
example. If the first packet hits the wakeup, and you wait one second,
that's plenty of opportunity for packet leaks. But sending more packets
will likely result in a burst of initial packets being sent out.

The world is now much more depending on sub-second times than it was
before.

> My own policy is 1 second between first and second transmissions, and the wait time is multiplied by sqrt(2) for each additional transmission, so the 12th transmission is 107 seconds after the first. Close enough, sort of.
>
> While it's possible to add a paragraph giving such a policy as an example, I don't see why we should even imply that this is a requirement.

I see widely different times from sub-zero to 20 seconds. It suggests
implementors have pretty different ideas on what it should be.

Paul