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
- [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