Re: [IPsec] Charter update

Paul Wouters <paul@nohats.ca> Sat, 19 July 2014 20:10 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356B61A029D for <ipsec@ietfa.amsl.com>; Sat, 19 Jul 2014 13:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 jpO3v5nAa2TB for <ipsec@ietfa.amsl.com>; Sat, 19 Jul 2014 13:10:42 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACF21A00AD for <ipsec@ietf.org>; Sat, 19 Jul 2014 13:10:41 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 141458008E; Sat, 19 Jul 2014 16:10:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1405800641; bh=Ftel/S3efDlJz2wK1Krc+MiWX6csqvc/j1voVBfjW/g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iLz8OQSPffukVQplR+KAPi/a9YwbPRnJu1n1vjDhlEpcO3ljaYLojf6Xm4UYTQmDp NwRBzEeIJS9Y7Q4XqDVBH/2GDJXAv9Wyr4w3a5fLDwrp3tuHLACt2UgWURAAe+VbG5 7tnvIhjpx7cu/IpnoEd1PsmkRUM0EMh+yAdLkTzY=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6JKAei1024593; Sat, 19 Jul 2014 16:10:40 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Sat, 19 Jul 2014 16:10:40 -0400
From: Paul Wouters <paul@nohats.ca>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <53CACDD6.1090707@gmail.com>
Message-ID: <alpine.LFD.2.10.1407191608180.22651@bofh.nohats.ca>
References: <53CAA14C.80301@gmail.com> <alpine.LFD.2.10.1407191539350.22651@bofh.nohats.ca> <53CACDD6.1090707@gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/cPgcYLU3JeSZAahH0Jn_79vxT7I
Cc: IPsecME WG <ipsec@ietf.org>
Subject: Re: [IPsec] Charter update
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 19 Jul 2014 20:10:43 -0000

On Sat, 19 Jul 2014, Yaron Sheffer wrote:

>>>    Recently discovered incorrect behavior of ISPs poses a
>>>    challenge to IKE, whose UDP messages (especially #3 and #4)
>>>    sometimes get fragmented at the IP level and then dropped
>>>    by these ISPs. There is interest in solving this issue by
>>>    allowing transport of IKE over TCP; this is currently
>>>    implemented by some vendors. The group will standardize such
>>>    a solution.
>> 
>> The working group had already reached consensus not to support two
>> different fragmentation solutions and to only support
>> draft-smyslov-ipsecme-ikev2-fragmentation, after Yoav's IKE TCP
>> presentation, I believe in London? So I don't think this item belongs
>> on the agenda, unless we are looking at revising that earlier decision.
>
> We have a fragmentation draft (almost) past IESG review. So we're not 
> revising any decision. "The group will standardize such a solution" is still 
> correct, until we actually publish the document.

You are revising the decision NOT to have IKE TCP:

 	"There is interest in solving this issue by
 	 allowing transport of IKE over TCP; this is currently
 	 implemented by some vendors. The group will standardize such
 	 a solution."

If you remove the first sentence, then it only talks about UDP and how
we are working on standarising fragmentation support using UDP.

Paul