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
- [IPsec] Updated version of RFC5996bis Tero Kivinen
- Re: [IPsec] Updated version of RFC5996bis Paul Wouters
- Re: [IPsec] Updated version of RFC5996bis Yaron Sheffer
- Re: [IPsec] Updated version of RFC5996bis Yoav Nir
- Re: [IPsec] Updated version of RFC5996bis Paul Wouters
- Re: [IPsec] Updated version of RFC5996bis Tero Kivinen
- [IPsec] Editorial changes to RFC5996 Valery Smyslov
- Re: [IPsec] Editorial changes to RFC5996 Yaron Sheffer
- Re: [IPsec] Editorial changes to RFC5996 Valery Smyslov
- Re: [IPsec] Editorial changes to RFC5996 Yaron Sheffer
- Re: [IPsec] Editorial changes to RFC5996 Yoav Nir
- Re: [IPsec] Editorial changes to RFC5996 Yaron Sheffer
- Re: [IPsec] Editorial changes to RFC5996 Valery Smyslov
- Re: [IPsec] Editorial changes to RFC5996 Yaron Sheffer
- [IPsec] One more editorial issue in RFC5996 Valery Smyslov
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- Re: [IPsec] RFC5996bis editorial change in sectio… Yaron Sheffer
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- Re: [IPsec] RFC5996bis editorial change in sectio… Valery Smyslov
- Re: [IPsec] RFC5996bis editorial change in sectio… Yaron Sheffer
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 3.… Tero Kivinen
- [IPsec] RFC5996bis section 3.1 comment Paul Wouters
- [IPsec] RFC5996bis section 3.1 comment Tero Kivinen