Re: [IPsec] Proposed wording for a revised charter

Tommy Pauly <tpauly@apple.com> Fri, 04 March 2016 17:05 UTC

Return-Path: <tpauly@apple.com>
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 2397C1A1AA7 for <ipsec@ietfa.amsl.com>; Fri, 4 Mar 2016 09:05:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 cX7bFkE8CZvA for <ipsec@ietfa.amsl.com>; Fri, 4 Mar 2016 09:05:46 -0800 (PST)
Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5971A1A58 for <ipsec@ietf.org>; Fri, 4 Mar 2016 09:05:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1457111145; x=2321024745; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=grvJpvkIpzd0TBQUcNCxJAKo5NJseOrqg2aZf2ytVgo=; b=MtAp48vtWINJTh9vXbJJx+GFDcCPQmXYNItq4Wv8I3Wlq1JLJaBEwxSR5A6dLp/G 2XR4Yn21k+iB8lPVZzyj6qlOZlpaS9IiOc+rvjUM2vGMPHAMezO43hWK0klt+Tbr MU8AxosKe8zVe3zD/8+PTI3nAgHRKRV1AT+ZLIGQubMeo/JklteLG8FWPrwogzY0 JwquOcrmF8xvXenfaz/tehKbcb4CLbcq55KLGsYcdJ/ziIkhsbkrKerpOtuwgINp /FhnQ8Or210CQoWGZEipSYqdzRqUUIpSdxnAWc6OraH73Tki5XQU/r/tL2bdivBQ UB+cxiIFju6cP7SLpvVDmg==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 8D.76.25552.960C9D65; Fri, 4 Mar 2016 09:05:45 -0800 (PST)
X-AuditID: 11973e16-f79bc6d0000063d0-4d-56d9c069b8eb
Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 4C.10.18091.960C9D65; Fri, 4 Mar 2016 09:05:45 -0800 (PST)
Received: from [17.153.62.167] by chive.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O3I009KSY5KJW10@chive.apple.com> for ipsec@ietf.org; Fri, 04 Mar 2016 09:05:45 -0800 (PST)
Sender: tpauly@apple.com
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 10.0 \(3167\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <ED97373A-7510-421C-956D-56ED6D443C37@nohats.ca>
Date: Fri, 04 Mar 2016 09:05:43 -0800
Content-transfer-encoding: quoted-printable
Message-id: <5281C22F-97EE-4994-829E-1121BEDE8E36@apple.com>
References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> <ED97373A-7510-421C-956D-56ED6D443C37@nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3167)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FAYpZt54GaYQUu3mcX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcf7NJfaCP7IVXXd6WRoYN0l0MXJySAiYSHyYvYkJwhaTuHBv PVsXIxeHkMBeRombjW2MMEVfPn5ghEhMY5K41/SZFcL5xCjR9HsSexcjB4ewgITE5j2JICaz gLrElCm5ICavgL7ErzPhIGOEBawlVky+wQpiswmoSBz/toEZxOYUsJXYNvUBC0g5i4CqxPI3 0SBhZgFXiT1XnrNA2NoST95dYIWYaCPx7DxYp5BAnsSf23vAjhQRUJSYdOYRC8TBshJ3jp9m AblRQmAJm8ShVXfZJjCKzEK4bRbCbbOQLFjAyLyKUSg3MTNHNzPPXC+xoCAnVS85P3cTIyio p9uJ7WB8uMrqEKMAB6MSD++NhuthQqyJZcWVuYcYpTlYlMR5NwsBhQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTDKFYpr8wpsrtAMk3lTlJNppVLoMFFf0si4++38iTp7sjP1tBl4G0++V5Sw 4Is4dJPpYLT4vrjkjg29fzea+DyftfDN224Nw10vxdV+fCp6p3TXQSvtQqijo3KUhbvc5eKn JV27E6W1wpa+3yMxZffS9skbp6qqcosqObHN6LA93h+sFchiq8RSnJFoqMVcVJwIALaGbPJL AgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUi2FDMr5t54GaYQdcFA4v9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/ybS+wFf2Qruu70sjQwbpLoYuTkkBAwkfjy8QMjhC0mceHe erYuRi4OIYFpTBL3mj6zQjifGCWafk9i72Lk4BAWkJDYvCcRxGQWUJeYMiUXxOQV0Jf4dSYc ZIywgLXEisk3WEFsNgEViePfNjCD2JwCthLbpj5gASlnEVCVWP4mGiTMLOAqsefKcxYIW1vi ybsLrBATbSSenQfrFBLIk/hzew/YkSICihKTzjxigThYVuLO8dMsExgFZyGcMwvhnFlIZi5g ZF7FKFCUmpNYaaaXWFCQk6qXnJ+7iREchIVROxgbllsdYhTgYFTi4b3RcD1MiDWxrLgy9xCj BAezkgjv2t03w4R4UxIrq1KL8uOLSnNSiw8xJgM9MpFZSjQ5HxgheSXxhiYmBibGxmbGxuYm 5qQJK4nzmp24GiYkkJ5YkpqdmlqQWgSzhYmDU6qBMasnZcURf06m+3IhrjLG2Sf/f+tNKt3G /+Xu8QIh244bguXWfycGaqetcozPaV33rG5KxP3qgNVc6tH3dh+INeuryldelcA15dQZB4Gg q5OyLtsxVS5mYkw65aK+8mrfsvtqU7fptwrZL1nF+a08ovHx4SMx92e7hC7KsVb/9IVL9qbK XuG7SizFGYmGWsxFxYkALbyjHoYCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/MbXMFYQ2GtlDvHO_sole1xDFoJg>
Cc: IPsecME WG <ipsec@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [IPsec] Proposed wording for a revised charter
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 04 Mar 2016 17:05:48 -0000

I would also like to see the draft for TCP encapsulation added as an item, since we’ve gotten a fair amount of support for it. For the purposes of the charter, it may be good to have a broader explanation of the goal—something to the effect that the working group should focus on making sure that IKEv2 can be deployed more universally by taking into account limitations of various networks. Previous RFCs like IKE fragmentation have contributed to this; TCP encapsulation tries to solve another set of problematic networks; and we can imagine that there may be more to investigate, such as taking into account the limitations and requirements of IoT networks, etc.

Tommy

> On Mar 1, 2016, at 12:32 PM, Paul Wouters <paul@nohats.ca> wrote:
> 
> S/mostly// 
> 
> Add IKE over tcp and DNS extensions for ikev2?
> 
> Sent from my iPhone
> 
>> On Mar 1, 2016, at 11:18, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>> 
>> Greetings. We need to update our charter to reflect our current and expected work. Dave and I propose the following text. Please let us know within the next week if you have suggestions for changes.
>> 
>> --Paul Hoffman and Dave Waltermire
>> 
>> 
>> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs),
>> IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is
>> widely deployed in VPN gateways, VPN remote access clients, and as a
>> substrate for host-to-host, host-to-network, and network-to-network
>> security.
>> 
>> The IPsec Maintenance and Extensions Working Group continues the work of
>> the earlier IPsec Working Group which was concluded in 2005. Its purpose is
>> to maintain the IPsec standard and to facilitate discussion of clarifications,
>> improvements, and extensions to IPsec, mostly to IKEv2.
>> The working group also serves as a focus point for other IETF Working Groups
>> who use IPsec in their own protocols.
>> 
>> The current work items include:
>> 
>> IKEv2 contains the cookie mechanism to protect against denial of service
>> attacks. However this mechanism cannot protect an IKE end-point (typically,
>> a large gateway) from "distributed denial of service", a coordinated attack by
>> a large number of "bots". The working group will analyze the problem and
>> propose a solution, by offering best practices and potentially by extending
>> the protocol.
>> 
>> IKEv2 utilizes a number of cryptographic algorithms in order to provide
>> security services. To support interoperability a number of mandatory-to-
>> implement (MTI) algorithms are defined in RFC4307. There is interest in
>> updating the MTIs in
>> RFC4307 based on new algorithms, changes to the understood security
>> strength of existing algorithms, and the degree of adoption of previously
>> introduced algorithms. The group will revise RFC4307 proposing updates to
>> the MIT algorithms used by IKEv2 to address these changes.
>> 
>> There is interest in supporting Curve25519 and Curve448 for ephemeral key
>> exchange in the IKEv2 protocol. The group will extend the
>> IKEv2 protocol to support key agreement using these curves and their
>> related functions.
>> 
>> This charter will expire in August 2016. If the charter is not updated before
>> that time, the WG will be closed and any remaining documents revert back to
>> individual Internet-Drafts.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec