Re: [IPsec] Updated version of RFC5996bis

Yoav Nir <ynir@checkpoint.com> Thu, 17 October 2013 15:04 UTC

Return-Path: <ynir@checkpoint.com>
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 A734211E820C for <ipsec@ietfa.amsl.com>; Thu, 17 Oct 2013 08:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.414
X-Spam-Level:
X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 y9UeDaqDmhEU for <ipsec@ietfa.amsl.com>; Thu, 17 Oct 2013 08:04:54 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D6AD021F923D for <ipsec@ietf.org>; Thu, 17 Oct 2013 08:04:42 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9HF3xUW028049; Thu, 17 Oct 2013 18:04:00 +0300
X-CheckPoint: {525FFC20-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Thu, 17 Oct 2013 18:03:49 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Paul Wouters <paul@cypherpunks.ca>
Thread-Topic: [IPsec] Updated version of RFC5996bis
Thread-Index: AQHOy0B6EYWWbwbZc0K/EwR9Ix0YZJn4vW8AgAAN+wA=
Date: Thu, 17 Oct 2013 15:03:49 +0000
Message-ID: <D10154ED-78C8-4FB7-8C49-5DDFC123C56B@checkpoint.com>
References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <alpine.LFD.2.10.1310171004250.29460@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1310171004250.29460@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.76]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C063ED889A4DB04993D4A62C56501E71@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:04:59 -0000

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"

RTT varies wildly on the Internet. I've just tried pinging www.ietf.org, and got this:
--- www.ietf.org ping statistics ---
29 packets transmitted, 28 packets received, 3.4% packet loss
round-trip min/avg/max/stddev = 275.850/542.648/1665.121/321.721 ms

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. 

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.

Yoav