From mglt.ietf@gmail.com Wed Aug 1 10:25:20 2012 Return-Path: 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 2F10211E822A; Wed, 1 Aug 2012 10:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=2.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 GJSmAF7m4uXQ; Wed, 1 Aug 2012 10:25:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B52F111E818B; Wed, 1 Aug 2012 10:25:00 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so14271091obb.31 for ; Wed, 01 Aug 2012 10:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jLMMtU6WhcaOoO+Otul4G8z59xVgMdiZ8DJyXOgWBkw=; b=Bq2lwCSq92DdDNju0xY09Oskb50YgDjZhY5bSfNN838z5HL9BLTPPUxkRmS8Bj63JI 3g6yjD76SA7+vDQRHO8g3YOvdIKt7xfUPYoMCe34zeXTvs5lAxNswPX30Pk+9TVwEmuW abTIdb7OblVyCWdDYnF0Va/BG9UZCBlcaELnR0BepWCegyA1gbHV/i8zYdB+I0N9cDJt vfvJFZHscbVWjyIQF0R8SMdYPFus90twTbTkcbbNrF9xhvmreggAsMQ9E1AkTbZ4FfOx IrsAgbkmA0D6O1HinyPapj/dxNnl+iXUNurGPhEyB8FKS9DrCYNMz0hMtm0lIxUEwXZ6 PwlQ== MIME-Version: 1.0 Received: by 10.182.2.233 with SMTP id 9mr30111943obx.11.1343841900346; Wed, 01 Aug 2012 10:25:00 -0700 (PDT) Received: by 10.182.111.34 with HTTP; Wed, 1 Aug 2012 10:25:00 -0700 (PDT) In-Reply-To: References: <20120730045037.978.65071.idtracker@ietfa.amsl.com> Date: Wed, 1 Aug 2012 19:25:00 +0200 Message-ID: From: Daniel Migault To: mif@ietf.org, ipsec@ietf.org, multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=f46d0444ea811abf3a04c6379351 Subject: Re: [IPsec] New Version Notification for draft-mglt-mif-security-requirements-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:25:20 -0000 --f46d0444ea811abf3a04c6379351 Content-Type: text/plain; charset=ISO-8859-1 Hi, We will be presenting MIF security requirements for IPsec at the mif meeting at 1pm. If you have free time, we would appreciate you come and participate in the discussion. BR, Daniel On Mon, Jul 30, 2012 at 6:59 AM, Daniel Migault wrote: > Please find the new version of IPsec security requirements with Multiple > Interfaces. > > Comments and suggestions are welcome > > BR > > Daniel > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 30, 2012 at 6:50 AM > Subject: New Version Notification for > draft-mglt-mif-security-requirements-02.txt > To: mglt.ietf@gmail.com > Cc: carlw@mcsr-labs.org > > > > A new version of I-D, draft-mglt-mif-security-requirements-02.txt > has been successfully submitted by Daniel Migault and posted to the > IETF repository. > > Filename: draft-mglt-mif-security-requirements > Revision: 02 > Title: IPsec Multiple Interfaces Requirements > Creation date: 2012-07-30 > WG ID: Individual Submission > Number of pages: 16 > URL: > http://www.ietf.org/internet-drafts/draft-mglt-mif-security-requirements-02.txt > Status: > http://datatracker.ietf.org/doc/draft-mglt-mif-security-requirements > Htmlized: > http://tools.ietf.org/html/draft-mglt-mif-security-requirements-02 > Diff: > http://tools.ietf.org/rfcdiff?url2=draft-mglt-mif-security-requirements-02 > > Abstract: > Multiple Interface Nodes (MIF Nodes) may use their Multiple > Interfaces to perform Mobility, Multihoming. Then, these MIF Nodes > may also manage traffic between these Multiple Interfaces. Because > IPsec has not been designed for Multiple Interfaces, MIF Nodes have > difficulties to benefit from MIF features with IPsec protected > communications. > > This document provides use cases where IPsec protected communications > would take advantage of MIF features. From these uses cases, we > identify the different IPsec features MIF Nodes would require. Then, > we expose the limitations of the IPsec related protocols IKEv2 and > MOBIKE regarding to these MIF features before listing the MIF IPsec > Security Requirements that should be address by a extension of IKEv2 > or MOBIKE. > > > > > The IETF Secretariat > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d0444ea811abf3a04c6379351 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

We will be presenting MIF security requirements for IPsec at th= e mif meeting at 1pm. If you have free time, we would appreciate you come a= nd participate in the discussion.

BR,
Daniel

On Mon, Jul 30, 2012 at 6:59 AM, Daniel Migault <mglt.ietf@gmail.com= > wrote:
Please find the new version of IPsec security requirements with Multiple In= terfaces.

Comments and suggestions are welcome

BR

Dani= el


---------- Forwarded message ----------
From: <internet-drafts@ietf.org<= /a>>
Date: Mon, Jul 30, 2012 at 6:50 AM
Subject: New Versio= n Notification for draft-mglt-mif-security-requirements-02.txt
To: mglt.ietf@gmai= l.com
Cc: c= arlw@mcsr-labs.org



A new version of I-D, draft-mglt-mif-security-requirements-02.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-mif-security-requirements
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 IPsec Multiple Interfaces Requirements
Creation date: =A0 2012-07-30
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 16
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.= ietf.org/internet-drafts/draft-mglt-mif-security-requirements-02.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.= org/doc/draft-mglt-mif-security-requirements
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/d= raft-mglt-mif-security-requirements-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://tools.= ietf.org/rfcdiff?url2=3Ddraft-mglt-mif-security-requirements-02

Abstract:
=A0 =A0Multiple Interface Nodes (MIF Nodes) may use their Multiple
=A0 =A0Interfaces to perform Mobility, Multihoming. =A0Then, these MIF Node= s
=A0 =A0may also manage traffic between these Multiple Interfaces. =A0Becaus= e
=A0 =A0IPsec has not been designed for Multiple Interfaces, MIF Nodes have<= br> =A0 =A0difficulties to benefit from MIF features with IPsec protected
=A0 =A0communications.

=A0 =A0This document provides use cases where IPsec protected communication= s
=A0 =A0would take advantage of MIF features. =A0From these uses cases, we =A0 =A0identify the different IPsec features MIF Nodes would require. =A0Th= en,
=A0 =A0we expose the limitations of the IPsec related protocols IKEv2 and =A0 =A0MOBIKE regarding to these MIF features before listing the MIF IPsec<= br> =A0 =A0Security Requirements that should be address by a extension of IKEv2=
=A0 =A0or MOBIKE.




The IETF Secretariat



--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58



--
Daniel Mi= gault
Orange Labs -- Security
+33 6 70 72 69 58
--f46d0444ea811abf3a04c6379351-- From paul.hoffman@vpnc.org Wed Aug 1 11:06:01 2012 Return-Path: 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 8F49711E8155 for ; Wed, 1 Aug 2012 11:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 rYoegGXh6835 for ; Wed, 1 Aug 2012 11:06:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0826E11E812E for ; Wed, 1 Aug 2012 11:06:00 -0700 (PDT) Received: from dhcp-2066.meeting.ietf.org (dhcp-2066.meeting.ietf.org [130.129.32.102]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q71HEkaJ072729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Aug 2012 10:14:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Wed, 1 Aug 2012 11:05:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120730045037.978.65071.idtracker@ietfa.amsl.com> To: Daniel Migault X-Mailer: Apple Mail (2.1278) Cc: IPsecme WG Subject: Re: [IPsec] New Version Notification for draft-mglt-mif-security-requirements-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:06:01 -0000 On Aug 1, 2012, at 10:25 AM, Daniel Migault wrote: > We will be presenting MIF security requirements for IPsec at the mif = meeting at 1pm. If you have free time, we would appreciate you come and = participate in the discussion. Thanks for the heads-up about the draft discussion. I hope that = IPsec-concerned people come to the MIF WG today but, even if not, = participate in the discussion of the draft. --Paul Hoffman= From paul.hoffman@vpnc.org Mon Aug 6 17:23:17 2012 Return-Path: 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 2CBA811E80F4 for ; Mon, 6 Aug 2012 17:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 aXzCC0BMoLgo for ; Mon, 6 Aug 2012 17:23:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3911E80A5 for ; Mon, 6 Aug 2012 17:23:16 -0700 (PDT) Received: from [10.20.30.100] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q770NE0M079386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 6 Aug 2012 17:23:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 6 Aug 2012 17:23:14 -0700 Message-Id: To: IPsecme WG Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPsec] Draft minutes from last week's meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 00:23:17 -0000 Please submit any changes. --Paul Hoffman From hallam@gmail.com Fri Aug 17 10:34:25 2012 Return-Path: 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 4343211E80E2; Fri, 17 Aug 2012 10:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.482 X-Spam-Level: X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=-1.883, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdkwKHB3UY-b; Fri, 17 Aug 2012 10:34:24 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A17711E80E1; Fri, 17 Aug 2012 10:34:24 -0700 (PDT) Received: by yenm5 with SMTP id m5so4649227yen.31 for ; Fri, 17 Aug 2012 10:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pyz+h07eJ2JjkrztKv3mXFDJGz0JVVJvc6ne06eCt6s=; b=AT+HonX+n3ELhMtcfQRVwHoJ5i8NANeLvSYSdaDFt/M4ki2ugLjf6nBHFxgGDJlS81 zhtQkMY1Wvexmhf3OEeg9yxZ67gMux140fzbLKw6t9HPYDnKVcGOEELIMDcIl1C89L2T 7/HOjZm3O5drIS3arvdhjRR6jb/YNC7WbQth/Br3l6XGSivKpVZf079NDT5GLgETouEq EWR/brBwDghkwsmEgp0n7RPR2xqbVlJPB/hOQRa598L0Mr6Tiw62Vc+EcN/EsgGpOSQC 5SjwQEF0yBXYcjjnqenmDXvylYIWPELUN79pKUJq/2eNlZDv2wy9ll3Dy+CP1VjuMcE2 MFWQ== MIME-Version: 1.0 Received: by 10.60.170.229 with SMTP id ap5mr4386894oec.101.1345224863810; Fri, 17 Aug 2012 10:34:23 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Fri, 17 Aug 2012 10:34:23 -0700 (PDT) In-Reply-To: <25977.1343775649@obiwan.sandelman.ca> References: <4896.1343757791@obiwan.sandelman.ca> <25977.1343775649@obiwan.sandelman.ca> Date: Fri, 17 Aug 2012 13:34:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org WG" , Paul Wouters , dane WG list Subject: Re: [IPsec] [dane] IPSEC & DANE (RFC4025) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:34:25 -0000 Is the answer to this problem possibly that DNS records to configure IPSEC should go in the reverse DNS? On Tue, Jul 31, 2012 at 7:00 PM, Michael Richardson wrote: > >>>>>> "Paul" == Paul Wouters writes: > Paul> So what happens in my case? Either google is blocked, or google is > Paul> downgraded to plaintext. Or the application could distinguish between > Paul> my suggested boguspublic-key versus the real google > > Google is plaintext, you never had the right to speak for it. > > Paul> Yes, and what I'm saying is that current methods for tying DANE to IPSEC > Paul> fail, because there is no binding to the legitimacy of the proclaimed > Paul> gateway. > > I assume by "current methods", you mean RFC4322? > Or is there another proposal that I've missed? > > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Website: http://hallambaker.com/ From paul@cypherpunks.ca Mon Aug 20 10:34:25 2012 Return-Path: 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 83C4521F8678; Mon, 20 Aug 2012 10:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l6RB+ma+7qV; Mon, 20 Aug 2012 10:34:25 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCE721F8667; Mon, 20 Aug 2012 10:34:25 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id B847580555; Mon, 20 Aug 2012 13:33:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AAD65804D0; Mon, 20 Aug 2012 13:33:47 -0400 (EDT) Date: Mon, 20 Aug 2012 13:33:47 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4896.1343757791@obiwan.sandelman.ca> <25977.1343775649@obiwan.sandelman.ca> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" , Michael Richardson , dane WG list Subject: Re: [IPsec] [dane] IPSEC & DANE (RFC4025) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 17:34:25 -0000 On Fri, 17 Aug 2012, Phillip Hallam-Baker wrote: > Is the answer to this problem possibly that DNS records to configure > IPSEC should go in the reverse DNS? Been there, done that in 1995, did not work. Paul From iesg-secretary@ietf.org Tue Aug 21 08:34:05 2012 Return-Path: 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 437A521F8770; Tue, 21 Aug 2012 08:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYNT-7i8xjrJ; Tue, 21 Aug 2012 08:34:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BC921F8771; Tue, 21 Aug 2012 08:34:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120821153404.10327.43514.idtracker@ietfa.amsl.com> Date: Tue, 21 Aug 2012 08:34:04 -0700 Cc: ipsecme WG Subject: [IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:34:05 -0000 The IP Security Maintenance and Extensions (ipsecme) working group in the Security Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Current Status: Active Working Group Chairs: Paul Hoffman Yaron Sheffer Assigned Area Director: Sean Turner Mailing list Address: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Charter of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 5996), 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: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and helping publish Informational documents describing current vendor proprietary solutions. 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, using draft-nir-ipsecme-ike-tcp as a starting point. This charter will expire in August 2014 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Done - WG last call on IPv6 configuration payloads Done - WG last call on IPsec roadmap Done - WG last call on session resumption Done - WG last call on redirect Done - WG last call on IKEv2bis Done - WG last call on ESP NULL traffic visibility Done - WG last call on HA requirements Done - WG last call on quick crash discovery Done - WG last call on EAP-only authentication Nov 2012 - IETF Last Call on large scale VPN use cases and requirements Feb 2013 - IETF Last Call on IKE over TCP Jun 2013 - IETF Last Call on large scale VPN protocol From hallam@gmail.com Tue Aug 21 17:13:15 2012 Return-Path: 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 9B52B21F855D; Tue, 21 Aug 2012 17:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlrdLUg8Y17o; Tue, 21 Aug 2012 17:13:15 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7AB821F8555; Tue, 21 Aug 2012 17:13:14 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so534676obb.31 for ; Tue, 21 Aug 2012 17:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DmRX5bxh+I5elS97TOY9xZWdn3eWz2/O/eieYbMaBNI=; b=Ccss5I0NONyFjvWDeIzPO+EI4NB1dbkqOoeNk045OsZz4brZw07jeMfSJR4B/aaltn W3fqq3p416VWlZqS1Z626kJMTtDjjw2LrLCiT99q3Ip2kC2zGdPhAfBY1zL3+6BMVKxP M9MZkhTieB7yThfGLBs0FeTTV/f2ypMKVWUwFBYOEJCkUcl1lMwb7htgUyw74eKlv6Uw Qi/ZDLhiYXwPWxpTsGtTlKu7fYI4+BDNie5DiXhviUlCcz0foMR9XrAOoS+hEBbriGrR 2f1vOGtUjbOA6b8rlOQt1iECtERLrIbRarkkOmzjiw+QVjYmRUbdjKULCHxgC9xPPxBC fPXQ== MIME-Version: 1.0 Received: by 10.182.118.71 with SMTP id kk7mr14103401obb.81.1345594394582; Tue, 21 Aug 2012 17:13:14 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Tue, 21 Aug 2012 17:13:14 -0700 (PDT) In-Reply-To: References: <4896.1343757791@obiwan.sandelman.ca> <25977.1343775649@obiwan.sandelman.ca> Date: Tue, 21 Aug 2012 20:13:14 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org WG" , Michael Richardson , dane WG list Subject: Re: [IPsec] [dane] IPSEC & DANE (RFC4025) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 00:13:15 -0000 On Mon, Aug 20, 2012 at 1:33 PM, Paul Wouters wrote: > On Fri, 17 Aug 2012, Phillip Hallam-Baker wrote: > >> Is the answer to this problem possibly that DNS records to configure >> IPSEC should go in the reverse DNS? > > > Been there, done that in 1995, did not work. When people make claims like that, I prefer to see a reason. Or are we meant to take the fact that you could not make it work to mean that it is impossible? -- Website: http://hallambaker.com/ From paul@cypherpunks.ca Tue Aug 21 17:27:00 2012 Return-Path: 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 C823D11E808D; Tue, 21 Aug 2012 17:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V14Qk60hG+lO; Tue, 21 Aug 2012 17:27:00 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 59F0711E808A; Tue, 21 Aug 2012 17:27:00 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 33ABB80555; Tue, 21 Aug 2012 20:26:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 266AB804B7; Tue, 21 Aug 2012 20:26:23 -0400 (EDT) Date: Tue, 21 Aug 2012 20:26:23 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4896.1343757791@obiwan.sandelman.ca> <25977.1343775649@obiwan.sandelman.ca> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" , dane WG list Subject: Re: [IPsec] [dane] IPSEC & DANE (RFC4025) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 00:27:00 -0000 On Tue, 21 Aug 2012, Phillip Hallam-Baker wrote: >>> Is the answer to this problem possibly that DNS records to configure >>> IPSEC should go in the reverse DNS? >> >> >> Been there, done that in 1995, did not work. > > When people make claims like that, I prefer to see a reason. Or are we > meant to take the fact that you could not make it work to mean that it > is impossible? It was called The FreeS/WAN Project and was founded by John Gilmore. It's Opportuistic Encryption used TXT records in the reverse. The two main problems were no one could add anything in their "own" reverse, and massive deployment of NAT meant people couldn't make their machines visible and reachable. Additionally, I see lots of signs the reverse for IPv6 is going to be even worse - even ISPs aren't really caring about it. Paul From internet-drafts@ietf.org Thu Aug 23 01:46:45 2012 Return-Path: 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 C379021F85AF; Thu, 23 Aug 2012 01:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0eCycbWgwNk; Thu, 23 Aug 2012 01:46:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7415921F85A7; Thu, 23 Aug 2012 01:46:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120823084641.22887.18356.idtracker@ietfa.amsl.com> Date: Thu, 23 Aug 2012 01:46:41 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 08:46:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-ad-vpn-problem-00.txt Pages : 15 Date : 2012-08-23 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution is chartered to address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shanna@juniper.net Thu Aug 23 09:03:40 2012 Return-Path: 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 9F15221F8594 for ; Thu, 23 Aug 2012 09:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2u72RTZ7N2o for ; Thu, 23 Aug 2012 09:03:40 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 041FC21F84B2 for ; Thu, 23 Aug 2012 09:03:39 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUDZUWx8sKsLKBvXLIColFavJdxY9K1fg@postini.com; Thu, 23 Aug 2012 09:03:40 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Aug 2012 09:03:09 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 23 Aug 2012 12:02:35 -0400 From: Stephen Hanna To: IPsecme WG Date: Thu, 23 Aug 2012 12:02:35 -0400 Thread-Topic: Revised AD VPN Requirements Thread-Index: Ac2BSLWwfjV5zyS9TEiCigvHiMXCmQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Revised AD VPN Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:03:40 -0000 Vishwas and I have updated the AD VPN Problem Statement and Requirements draft to address the comments received on the previous version and remaining comments from earlier email discussions. The new version is available at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem A summary of the changes in this version is included at the end of this message. Please review this document and provide any comments on the existing requirements or suggestions for new ones. For requirement 3, Vishwas will be starting an email thread soon so that the WG can discuss what this text means, whether we want to keep it, and how it can be made clearer. Thanks, Steve ------------ Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt * Changed draft name from p2p-vpn to ad-vpn. * Added a paragraph for each requirement, explaining how that requirement is driven by the use cases. * In requirement 1, defined what we mean by minimizing configuration changes. * In requirement 2, explained that this requirement implies that SPD entries and other configuration based on peer IP address will need to be automatically updated when the peer's IP address changes. * Split requirement 4 into two requirements (now 4 and 5). * In requirement 6 (formerly 5), explained what we mean by "easy handoff of sessions": avoid TCP session breakage and packet loss, when possible. * In requirement 8 (formerly 7), acknowledged the difficulty of handling cases where gateways are behind NATs or where two endpoints are both behind separate NATs. In those cases, we may need to use workarounds such as port forwarding by the NATs or falling back to a hub and spoke architecture. * Added new requirement 9 around manageability. * Added new requirement 10 around cross-organization use. * Added new requirement 11 saying that administrators should be able to limit topologies for security and other reasons. * Fixed typos and other minor wording issues. From internet-drafts@ietf.org Tue Aug 28 00:34:23 2012 Return-Path: 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 BF10F11E80D1; Tue, 28 Aug 2012 00:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVgplKyc97+L; Tue, 28 Aug 2012 00:34:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544A111E808D; Tue, 28 Aug 2012 00:34:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120828073423.10539.76101.idtracker@ietfa.amsl.com> Date: Tue, 28 Aug 2012 00:34:23 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 07:34:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : A TCP transport for the Internet Key Exchange Author(s) : Yoav Nir Filename : draft-ietf-ipsecme-ike-tcp-00.txt Pages : 8 Date : 2012-08-27 Abstract: This document describes using TCP for IKE messages. This facilitates the transport of large messages over paths where fragments are either dropped, or where packet loss makes the use of large UDP packets unreliable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ike-tcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ike-tcp-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Johannes.Merkle@secunet.com Tue Aug 28 00:41:31 2012 Return-Path: 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 9186511E80C5 for ; Tue, 28 Aug 2012 00:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[AWL=-1.173, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvhW7eltfw8z for ; Tue, 28 Aug 2012 00:41:29 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id B75E011E808D for ; Tue, 28 Aug 2012 00:41:29 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 3B2841A0079; Tue, 28 Aug 2012 09:41:28 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 43AFE1A005D; Tue, 28 Aug 2012 09:41:26 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Aug 2012 09:41:25 +0200 Message-ID: <503C7624.4060302@secunet.com> Date: Tue, 28 Aug 2012 09:41:24 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipsec@ietf.org, kivinen@iki.fi References: <500EC87A.5020106@gmail.com> In-Reply-To: <500EC87A.5020106@gmail.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2012 07:41:25.0861 (UTC) FILETIME=[872EA150:01CD84F0] Subject: [IPsec] ECDSA in IKEv2 - reanimation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 07:41:31 -0000 Hi all, it's been some time since our discussion on this list has dried up. Did we achieve a consensus on the general design decisions? Tero, as you are the designated team leader, what is you suggestion for going ahead? -- Johannes From yaronf.ietf@gmail.com Tue Aug 28 09:05:50 2012 Return-Path: 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 788D711E80A5; Tue, 28 Aug 2012 09:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaxwE7eotYcM; Tue, 28 Aug 2012 09:05:49 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5E511E808D; Tue, 28 Aug 2012 09:05:48 -0700 (PDT) Received: by bkty12 with SMTP id y12so1437273bkt.31 for ; Tue, 28 Aug 2012 09:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y8Z275qQJVu23z8+c6/36N46WB9IiUjbu6Pe7QzzbuI=; b=QYXs0xkMB+yq8K6+L7q3Fv0BJ8ncom/hrt+4PSUyg+lI/wdstq2SYOWSohp4qh60o4 PcKqLc6audWn4Azvuo71ST6sTw0XWL5TevLHE2WDrYB9vdszPsh9deWdjuQn1kx9u/tK s0CMFpXDvai4bTsnRp301TxNodumhJi2p7nOsco/Jse2Tal7YfdRWkIREfnnrCzw7wVL uMYvOVeYs1BszgW62xVD2KITD+JDM96VXhNI8bc8HhHWvbky0Bzdzjq+XqFMYfsxlLP3 RY/T3pTQHb8fWAKWOOzQ+3HCanZdjeNdOwRzdbhhELCEcAX8EQeFpe32I8upJFU+DZ3Y C8DQ== Received: by 10.204.157.18 with SMTP id z18mr5292381bkw.16.1346169947727; Tue, 28 Aug 2012 09:05:47 -0700 (PDT) Received: from [10.0.0.8] ([109.67.151.97]) by mx.google.com with ESMTPS id n5sm13150103bkv.14.2012.08.28.09.05.46 (version=SSLv3 cipher=OTHER); Tue, 28 Aug 2012 09:05:47 -0700 (PDT) Message-ID: <503CEC59.9080601@gmail.com> Date: Tue, 28 Aug 2012 19:05:45 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Dan Harkins References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , "dharkins@arubanetworks.com" , "Polk, William T." , "secdir@ietf.org" Subject: Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:05:50 -0000 Hi Tim, Dan, can you please move this discussion to the ipsecme mailing list (copied)? I believe that is a more appropriate venue to discuss IKE code points. Thanks, Yaron On 08/28/2012 06:48 PM, Dan Harkins wrote: > > Hi Tim, > > On Tue, August 28, 2012 7:28 am, Polk, William T. wrote: >> hi Dan, >> >> Thanks for getting this work underway. >> >> First observation: I think a reference to RFC 6090 is warranted. > > Yes, good point. I'll add a reference to it at the start of section 2 where > the equation for the curves is noted. > >> Second Observation: 80 bit crypto is on its last legs. Do we really need >> to specify curves with less than 112 bit strength? > > There is the notion that "if it's worth protecting, it's worth protecting > properly" and I'm not sure of the current usefulness of 80-bit crypto but > this is more for completeness. The Brainpool defined them and I'm just > asking for a magic numbers to be assigned to all the defined curves. > > That also is the the answer to the "14 code points, oh my!" comments. > Note that we still have over 32,000 code points available so we're talking > about taking 4/100th of 1%. > >> Third Observation: The security considerations section does not address >> the security strength of 192 or 384 bit curves. It feels incomplete, >> although I guess most readers can work it out for themselves. > > I refer the reader to RFC 5639 which mentions the security considerations > of the curves. If you like I can also mention something about how the best > known attacks run on the order of the square root of the order. Would that > be satisfactory? > >> General observation: my experience is that specifying so many curves >> dilutes implementer enthusiasm. We finally started to get some interest >> in ECC support for FIPS 201 when we pared the list down from six curves in >> three families to two prime curves (P-256 and P-384). > > That is a very good observation. I guess we should talk to the Brainpool. > Their consortium seems to have some large and important companies in > it. The concern is that one of the members would promote the use of a > particular curve in some operational or regulatory fashion and it's > important that the users of the IKEv1 registry be able to work anywhere. > >> Specifying two alternatives for each security level feels like an >> implementer's nightmare. Are Brainpool implementations general enough to >> handle the normal and twisted curves at a particular level? If the >> implementations are agnostic, maybe that should get noted in yout >> insecurity considerations. > > You're right, it is a nightmare! As it turns out quite a few of my test > vectors are wrong. I think implementations will be agnostic and I will > mention agnosticism. > > thanks for your comments! > > Dan. > >> Tim >> >> ________________________________ >> From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of Yoav >> Nir [ynir@checkpoint.com] >> Sent: Tuesday, August 28, 2012 7:52 AM >> To: Stephen Farrell >> Cc: secdir@ietf.org >> Subject: Re: [secdir] I-D Action: >> draft-harkins-brainpool-ike-groups-00.txt >> >> >> On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote: >> >>> >>> >>> On 28 Aug 2012, at 12:24, Sean Turner wrote: >>> >>>> BTW - Dan's submitted a draft about the topic we had in Vancouver. >>>> Comments are welcome. >>> >>> I've one: I didn't realize Dan wanted 14 code points. That seems a lot. >> >> BTW: Johannes Merkle submitted >> http://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00 that >> requests points for the same curves for IKEv2. >> >> I'm wondering if we really need 7 different strengths as opposed to, say, >> 3, and whether we need both a twisted and non-twisted variation for each. >> Neither document discusses the why one would prefer the twisted to the >> non-twisted variant, or the non-twisted to the twisted. RFC 5639 does not >> give such considerations either, but documents that relate to protocols >> should IMO. >> >> Yoav >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From dharkins@lounge.org Tue Aug 28 10:49:04 2012 Return-Path: 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 6E4BF21F85FC; Tue, 28 Aug 2012 10:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q56aoAlw-7D; Tue, 28 Aug 2012 10:49:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 99C4E21F8597; Tue, 28 Aug 2012 10:49:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E8ECA1022404A; Tue, 28 Aug 2012 10:49:02 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 28 Aug 2012 10:49:03 -0700 (PDT) Message-ID: In-Reply-To: <503CEC59.9080601@gmail.com> References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> <503CEC59.9080601@gmail.com> Date: Tue, 28 Aug 2012 10:49:03 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , "dharkins@arubanetworks.com" , "secdir@ietf.org" Subject: Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:49:04 -0000 Hi Yaron, On Tue, August 28, 2012 9:05 am, Yaron Sheffer wrote: > Hi Tim, Dan, > > can you please move this discussion to the ipsecme mailing list > (copied)? I believe that is a more appropriate venue to discuss IKE code > points. When the IEEE liaison brought up this issue, your co-chairman said, "Yaron and I should "not* be part of this discussion because the issue is *not* an IPsecME WG issue. It is not in our charter to make additions to the obsoleted-but-still-widely-used IKEv1 protocol." He is also the one who insisted on the note that the draft adds to the registry, which sort of makes this not an IKE code point discussion. If this is an IKE discussion, I'd be happy to discuss this on the ipsecme list and I'd be, therefore, happy to remove the note and the corresponding "Insecurity Considerations" from the draft. But maybe you guys should go off and decide what you want. Dan. > > Thanks, > Yaron > > On 08/28/2012 06:48 PM, Dan Harkins wrote: >> >> Hi Tim, >> >> On Tue, August 28, 2012 7:28 am, Polk, William T. wrote: >>> hi Dan, >>> >>> Thanks for getting this work underway. >>> >>> First observation: I think a reference to RFC 6090 is warranted. >> >> Yes, good point. I'll add a reference to it at the start of section 2 >> where >> the equation for the curves is noted. >> >>> Second Observation: 80 bit crypto is on its last legs. Do we really >>> need >>> to specify curves with less than 112 bit strength? >> >> There is the notion that "if it's worth protecting, it's worth >> protecting >> properly" and I'm not sure of the current usefulness of 80-bit crypto >> but >> this is more for completeness. The Brainpool defined them and I'm just >> asking for a magic numbers to be assigned to all the defined curves. >> >> That also is the the answer to the "14 code points, oh my!" comments. >> Note that we still have over 32,000 code points available so we're >> talking >> about taking 4/100th of 1%. >> >>> Third Observation: The security considerations section does not address >>> the security strength of 192 or 384 bit curves. It feels incomplete, >>> although I guess most readers can work it out for themselves. >> >> I refer the reader to RFC 5639 which mentions the security >> considerations >> of the curves. If you like I can also mention something about how the >> best >> known attacks run on the order of the square root of the order. Would >> that >> be satisfactory? >> >>> General observation: my experience is that specifying so many curves >>> dilutes implementer enthusiasm. We finally started to get some >>> interest >>> in ECC support for FIPS 201 when we pared the list down from six curves >>> in >>> three families to two prime curves (P-256 and P-384). >> >> That is a very good observation. I guess we should talk to the >> Brainpool. >> Their consortium seems to have some large and important companies in >> it. The concern is that one of the members would promote the use of a >> particular curve in some operational or regulatory fashion and it's >> important that the users of the IKEv1 registry be able to work anywhere. >> >>> Specifying two alternatives for each security level feels like an >>> implementer's nightmare. Are Brainpool implementations general enough >>> to >>> handle the normal and twisted curves at a particular level? If the >>> implementations are agnostic, maybe that should get noted in yout >>> insecurity considerations. >> >> You're right, it is a nightmare! As it turns out quite a few of my >> test >> vectors are wrong. I think implementations will be agnostic and I will >> mention agnosticism. >> >> thanks for your comments! >> >> Dan. >> >>> Tim >>> >>> ________________________________ >>> From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of >>> Yoav >>> Nir [ynir@checkpoint.com] >>> Sent: Tuesday, August 28, 2012 7:52 AM >>> To: Stephen Farrell >>> Cc: secdir@ietf.org >>> Subject: Re: [secdir] I-D Action: >>> draft-harkins-brainpool-ike-groups-00.txt >>> >>> >>> On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote: >>> >>>> >>>> >>>> On 28 Aug 2012, at 12:24, Sean Turner wrote: >>>> >>>>> BTW - Dan's submitted a draft about the topic we had in Vancouver. >>>>> Comments are welcome. >>>> >>>> I've one: I didn't realize Dan wanted 14 code points. That seems a >>>> lot. >>> >>> BTW: Johannes Merkle submitted >>> http://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00 that >>> requests points for the same curves for IKEv2. >>> >>> I'm wondering if we really need 7 different strengths as opposed to, >>> say, >>> 3, and whether we need both a twisted and non-twisted variation for >>> each. >>> Neither document discusses the why one would prefer the twisted to the >>> non-twisted variant, or the non-twisted to the twisted. RFC 5639 does >>> not >>> give such considerations either, but documents that relate to protocols >>> should IMO. >>> >>> Yoav >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From paul.hoffman@vpnc.org Tue Aug 28 11:18:32 2012 Return-Path: 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 1D0F721F85DA; Tue, 28 Aug 2012 11:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5fHfPQZTAr9; Tue, 28 Aug 2012 11:18:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7D221F85F7; Tue, 28 Aug 2012 11:18:31 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7SIIQ6M013774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Aug 2012 11:18:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 (Normal) In-Reply-To: Date: Tue, 28 Aug 2012 11:18:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> <503CEC59.9080601@gmail.com> To: Dan Harkins X-Mailer: Apple Mail (2.1486) Cc: IPsecme WG , secdir Subject: Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:18:32 -0000 On Aug 28, 2012, at 10:49 AM, Dan Harkins wrote: > When the IEEE liaison brought up this issue, your co-chairman > said, "Yaron and I should "not* be part of this discussion because > the issue is *not* an IPsecME WG issue. It is not in our charter > to make additions to the obsoleted-but-still-widely-used IKEv1 > protocol." He is also the one who insisted on the note that the > draft adds to the registry, which sort of makes this not an IKE > code point discussion. I was with you until that last phrase. It most certainly is an IKEv1 = code point discussion. > If this is an IKE discussion, I'd be happy to discuss this on the > ipsecme list and I'd be, therefore, happy to remove the note and the > corresponding "Insecurity Considerations" from the draft. >=20 > But maybe you guys should go off and decide what you want. What I want is for you to be less snarky in your communication, both = on-list and in the Internet-Drafts you write. I would also want you to = be clearer in your drafts when you are talking about IKEv1 or IKEv2: in = this draft, even in the filename, you kind of hid that. Whether or not you want to do those, I want the ADs to decide whether it = is appropriate to do more work on IKEv1, such as adding these curves to = the IKEv1 registries. If they think the work is appropriate, they can = also say where it should be done. --Paul Hoffman= From dharkins@lounge.org Tue Aug 28 11:54:10 2012 Return-Path: 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 8C24621F860E; Tue, 28 Aug 2012 11:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnwXmhWmsPiu; Tue, 28 Aug 2012 11:54:10 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1144721F860B; Tue, 28 Aug 2012 11:54:10 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9DCFB1022404A; Tue, 28 Aug 2012 11:54:09 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 28 Aug 2012 11:54:09 -0700 (PDT) Message-ID: <6c1ddd2baf1480f6e7abeab6ac618402.squirrel@www.trepanning.net> In-Reply-To: References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> <503CEC59.9080601@gmail.com> Date: Tue, 28 Aug 2012 11:54:09 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , secdir Subject: Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:54:10 -0000 On Tue, August 28, 2012 11:18 am, Paul Hoffman wrote: > > On Aug 28, 2012, at 10:49 AM, Dan Harkins wrote: > >> When the IEEE liaison brought up this issue, your co-chairman >> said, "Yaron and I should "not* be part of this discussion because >> the issue is *not* an IPsecME WG issue. It is not in our charter >> to make additions to the obsoleted-but-still-widely-used IKEv1 >> protocol." He is also the one who insisted on the note that the >> draft adds to the registry, which sort of makes this not an IKE >> code point discussion. > > I was with you until that last phrase. It most certainly is an IKEv1 code > point discussion. If you insist that the registry say "not for IKEv1" then the code points are not for IKEv1 and any discussion about code points that are not for IKEv1 is not an IKEv1 code point discussion. >> If this is an IKE discussion, I'd be happy to discuss this on the >> ipsecme list and I'd be, therefore, happy to remove the note and the >> corresponding "Insecurity Considerations" from the draft. >> >> But maybe you guys should go off and decide what you want. > > What I want is for you to be less snarky in your communication, both > on-list and in the Internet-Drafts you write. I would also want you to be > clearer in your drafts when you are talking about IKEv1 or IKEv2: in this > draft, even in the filename, you kind of hid that. Please rephrase your wants into specific comments on the draft that I can then accept, counter, or reject. And please do not send them to the IPsecME list because, as you said, this "is *not* an IPsecME WG issue" (emphasis yours). > Whether or not you want to do those, I want the ADs to decide whether it > is appropriate to do more work on IKEv1, such as adding these curves to > the IKEv1 registries. If they think the work is appropriate, they can also > say where it should be done. They already did; you were there. Dan. From kent@bbn.com Wed Aug 29 05:57:33 2012 Return-Path: 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 873E221F863F for ; Wed, 29 Aug 2012 05:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifJygsflK0Lg for ; Wed, 29 Aug 2012 05:57:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABCE21F84C9 for ; Wed, 29 Aug 2012 05:57:33 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40187 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6hpq-0004Om-7y; Wed, 29 Aug 2012 08:57:30 -0400 Message-ID: <503E11B9.2040308@bbn.com> Date: Wed, 29 Aug 2012 08:57:29 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipsec@ietf.org, dharkins@lounge.org References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> <503CEC59.9080601@gmail.com> <6c1ddd2baf1480f6e7abeab6ac618402.squirrel@www.trepanning.net> In-Reply-To: <6c1ddd2baf1480f6e7abeab6ac618402.squirrel@www.trepanning.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 12:57:33 -0000 Dan, My recollection is that the agreement at the SECDIR meeting was that a waring of the form "not for use with IKEv1" was part pf the deal. I still believe this is a very questionable way to accommodate the IEEE's unwillingness to maintain their own registry, and their slow doc rev cycle time that is causing us to do a silly (at best) thing. Steve From kivinen@iki.fi Wed Aug 29 07:45:25 2012 Return-Path: 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 971AB21F8525; Wed, 29 Aug 2012 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.716 X-Spam-Level: X-Spam-Status: No, score=-102.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8qQg7Y8MdvH; Wed, 29 Aug 2012 07:45:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9639F21F8528; Wed, 29 Aug 2012 07:45:24 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q7TEjMo9018138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 17:45:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q7TEjLTK012338; Wed, 29 Aug 2012 17:45:21 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20542.11009.577257.29490@fireball.kivinen.iki.fi> Date: Wed, 29 Aug 2012 17:45:21 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <6c1ddd2baf1480f6e7abeab6ac618402.squirrel@www.trepanning.net> References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie> <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> <503CEC59.9080601@gmail.com> <6c1ddd2baf1480f6e7abeab6ac618402.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: IPsecme WG , secdir Subject: Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:45:25 -0000 Dan Harkins writes: > > I was with you until that last phrase. It most certainly is an > > IKEv1 code point discussion. > > If you insist that the registry say "not for IKEv1" then the > code points are not for IKEv1 and any discussion about code points > that are not for IKEv1 is not an IKEv1 code point discussion. That registry is for IKEv1. Meaning ANY changes to those registries are still IKEv1 issues. Regardless whether we say that those points are not for IKEv1 use. Are you saying that if I want to add 2000 new cipher suites to TLS registry (from the Specification Required space) and say that they are not for TLS use, I do not need to ask anything from the TLS working group? So I myself at least do consider this to be also IKE issue even when the groups are not for IKEv1 use, just because it changes IKEv1 registry. > Please rephrase your wants into specific comments on the draft that > I can then accept, counter, or reject. And please do not send them to > the IPsecME list because, as you said, this "is *not* an IPsecME WG > issue" (emphasis yours). Remove the completely stupid "5. Insecurity Considerations" containing your own biased opionions of the reality. Add proper note why these things are to be added at all. You say in the section 1 that "Other pprotocols, ...", but do not point out any other than IEEE802.11, is there some other protocols referencing this registry than the IEEE802.11? Also it would be better to say that in the IEEE 802.11 only the SAE uses this registry. Also how widely supported SAE is? I have not seen it in any of the user interfaces for wlan systems I have configured at? Also the point that these groups are not for IKE is bit misleading when the title says IKE, and abstract talks about adding groups to "registry established by Teh Internet Key Exchange (IKE)", but does not point out that it is not for that protocol at all... > > Whether or not you want to do those, I want the ADs to decide whether it > > is appropriate to do more work on IKEv1, such as adding these curves to > > the IKEv1 registries. If they think the work is appropriate, they can also > > say where it should be done. > > They already did; you were there. I was there too, but I think I missed it too. Can you tell me what did they decide? Is it approriate to do any more work on IKEv1? And if so where should it be done? -- kivinen@iki.fi From gandhar.ietf@gmail.com Thu Aug 30 03:40:05 2012 Return-Path: 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 3464321F8605 for ; Thu, 30 Aug 2012 03:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMZeAe9ak8SW for ; Thu, 30 Aug 2012 03:40:04 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD6021F8466 for ; Thu, 30 Aug 2012 03:40:04 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1997076vcb.31 for ; Thu, 30 Aug 2012 03:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=H7kv8M8UpFfSlhKhEX7Puqd7fLrm5i7XtTu9clj3coA=; b=NLIehZIRABkO/BOH6n6bbFiqw8NLc0r/s42DgT7t+F8r2nEjTn1n/XqjUIug7ivG9B QLwU3+f5xBRNRILrnjY3bSYKVN/SclgjZgVHcFmCdwIHxQj0Uye4gR0fFmIie3EuRFjd Lyop6wcg5Zi6VM4OZJdyp1JtnO3Lbxmhv1SnBzebsc71rg/gdponGfUWpEF/BNBU6t+B VBzARh95PDxQF6dy9OFeneWRUis1lc0kz/tN1j4jjQmz1RUoqLrhQqmzRHSTA7tm/fRr PtyaL/bq8mLx4DM8fYqs5/QgEcD+3IuN7Mlhp9rGicE/IZ/KY9q1lI6VXCdV6klkz06M vviw== MIME-Version: 1.0 Received: by 10.58.114.20 with SMTP id jc20mr2964492veb.15.1346323203603; Thu, 30 Aug 2012 03:40:03 -0700 (PDT) Received: by 10.52.103.102 with HTTP; Thu, 30 Aug 2012 03:40:03 -0700 (PDT) Date: Thu, 30 Aug 2012 16:10:03 +0530 Message-ID: From: Gandhar Gokhale To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d33204dbb7704c8794c43 Subject: [IPsec] Pre-fragmentation of IPsec tunneled packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 10:40:05 -0000 --047d7b5d33204dbb7704c8794c43 Content-Type: text/plain; charset=ISO-8859-1 Hi, RFC 4301, section 5.1 says that if pre-fragmentation is to be supported then the policy lookup has to happen on fragmented packets and the non-initial fragments will not match any policy with non-trivial ports. I've a doubt in this. After searching on the Internet for earlier results I could not find if it was discussed previously on this list nor did I find it in the RFC 4301 errata. Here's the relevant excerpt: *"Note: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or BITW implementation MAY fragment packets before applying IPsec. (This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them.) The device SHOULD have a configuration setting to disable this. The resulting fragments are evaluated against the SPD in the normal manner. Thus, fragments not containing port numbers (or ICMP message type and code, or Mobility Header type) will only match rules having port (or ICMP message type and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for more details.)"* For deciding whether to fragment a packet we need to know the packet's length and MTU (or PMTU but to k) ofthe interface. IPsec tunnel alters length of the packet and possibly outgoing interface as well. It means the policy affects the decision of whether a packet would get frameneted or not. However, RFC section 5.1 requires implementation to perform policy lookup on the fragmented packet. How can the implementation decide if the a packet should be fragmented before knowing what policy (and SA) will match? Moreover, the section 7.3 (reassembly for policy verification) becomes redundant if implementation has conformed to section 5.1 since the non-initial fragments are required to match only 3-tuple policy at sender. That means, at the receiver non-initial fragements must be matched only to policy rules without non-trivial ports. Can someone please help me understand what I'm missing here? Thanks and regards, Gandhar Gokhale Networking Components Group LSI --047d7b5d33204dbb7704c8794c43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
RFC 4301, section 5.1 says that if pre-fragmentation is to be supporte= d then the policy lookup has to happen on fragmented packets and the non-in= itial fragments will not match any policy with non-trivial ports. I've = a doubt in this. After searching on the Internet for earlier results I coul= d not find if it was discussed previously on this list nor did I find it in= the RFC 4301 errata.
Here's the relevant excerpt:
"Note: With the exceptio= n of IPv4 and IPv6 transport mode, an SG,=A0BITS, or BITW implementation MA= Y fragment packets before applying IPsec. (This applies only to IPv4. For I= Pv6 packets, only the=A0originator is allowed to fragment them.) The device= SHOULD have a=A0configuration setting to disable this.=A0 The resulting fr= agments are=A0evaluated against the SPD in the normal manner.=A0Thus, fragm= ents not=A0containing port numbers (or ICMP message type and code, or Mobil= ity=A0Header type) will only match rules having port (or ICMP message type= =A0and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for mor= e details.)"
=A0
For deciding whether to fragment a packet we need to know the packet&#= 39;s length and MTU (or PMTU but to k) ofthe interface. IPsec tunnel alters= length of the packet and possibly outgoing interface as well. It means the= policy affects the decision of whether a packet would get frameneted or no= t. However, RFC section 5.1 requires implementation to perform policy looku= p on the fragmented packet. How can the implementation decide if the a pack= et should be fragmented before knowing what policy (and SA) will match?
Moreover, the section 7.3 (reassembly for policy verification) becomes= redundant if implementation has conformed to section 5.1 since the non-ini= tial fragments are required to match only 3-tuple policy at sender. That me= ans, at the receiver non-initial fragements must be matched only to policy = rules without non-trivial ports.
=A0
Can someone please help me understand what I'm missing here?
=A0
Thanks and regards,
Gandhar Gokhale
Networking Components Group
LSI
--047d7b5d33204dbb7704c8794c43-- From gandhar.ietf@gmail.com Thu Aug 30 06:24:12 2012 Return-Path: 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 0780221F85AF for ; Thu, 30 Aug 2012 06:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7MtN-hcbJhj for ; Thu, 30 Aug 2012 06:24:10 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 641C621F85A8 for ; Thu, 30 Aug 2012 06:24:10 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2211938vcb.31 for ; Thu, 30 Aug 2012 06:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LOdEokiSYhYXoK+5JASq9FPbCkRT5oDoGHIPGBEvUc4=; b=DVFywFRBKxCoHkUfNhqnkD9FPSRZo7amBzBslo3mewiPOGNY7jXihZLAGTtmPWFo6j TYtOcON+s+1mcVM7BqWHByj0vSP5w/6ATub8QaWxIwn3fwtwiQNUIDH8zRdDum3527sq gkZw+2l31J3UQER5CwZ2Rw8b9Vzn931EZFaR7DSkTJyqc/aN5bkruXDxmlttKwzY3zeH oJOVX118rF39ozQMzpc4sd6Fq4NEJ6JNwyZpgaGzeG5bXc016jNiFle6mT+otHe0qtgg mXtTxKEaFl5oYq7+tL+2fLayVdlXOUlhN9wEkAohvmQT/JqO/JyoHUBUV1OgusIv0fjD gmWw== MIME-Version: 1.0 Received: by 10.220.37.194 with SMTP id y2mr3163261vcd.44.1346333049508; Thu, 30 Aug 2012 06:24:09 -0700 (PDT) Received: by 10.52.103.102 with HTTP; Thu, 30 Aug 2012 06:24:09 -0700 (PDT) In-Reply-To: <17273.1346328665@obiwan.sandelman.ca> References: <17273.1346328665@obiwan.sandelman.ca> Date: Thu, 30 Aug 2012 18:54:09 +0530 Message-ID: From: Gandhar Gokhale To: Michael Richardson Content-Type: multipart/alternative; boundary=bcaec54eea8e2a52ab04c87b97d3 Cc: ipsec@ietf.org Subject: Re: [IPsec] Pre-fragmentation of IPsec tunneled packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 13:24:12 -0000 --bcaec54eea8e2a52ab04c87b97d3 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Thanks for sharing your thoughts. If the IPsec "implementation" receives a fragmented plain text packet for encrypting and sending out then it is not really a pre-fragmentation. Pre-fragmentation requires the IPsec itself needs to decide whether to fragment an incoming plain text fragment before encrypting it. The question is, how to make that decision if MTU & packet size is decided by policy and SA. RFC asks us to use a policy with layer 3 selectors only for the non initial fragments. However, the decision to fragment can not be made without doing policy lookup. This is a circular dependancy. My suspicion is that RFC expects us to look the full L4 policy for the full packet and a subsequent policy lookup for each individual (non-initial) fragment though it does not explictly state so. This is not quite obvious from the description of the outbound processing in the RFC though and therefore my suspicion may be invalid. Thanks and regards, Gandhar Gokhale Networking Components Group LSI On Thu, Aug 30, 2012 at 5:41 PM, Michael Richardson wrote: > > >>>>> "Gandhar" == Gandhar Gokhale writes: > Gandhar> relevant excerpt: *"Note: With the exception of IPv4 and > Gandhar> IPv6 transport mode, an SG, BITS, or BITW implementation > Gandhar> MAY fragment packets before applying IPsec. (This applies > Gandhar> only to IPv4. For IPv6 packets, only the originator is > Gandhar> allowed to fragment them.) The device SHOULD have a > > So, it's important to realize the "SG", "BITS" and "BITW" parts all put > the IPsec at a distance from the IP layer. So the fragmentation already > occurred before (and maybe some distance) from the IPsec policy layer. > > Gandhar> For deciding whether to fragment a packet we need to know > Gandhar> the packet's length and MTU (or PMTU but to k) ofthe > Gandhar> interface. IPsec tunnel alters length of the packet and > Gandhar> possibly outgoing interface as well. It means the policy > Gandhar> affects the decision of whether a packet would get > Gandhar> frameneted or not. However, RFC section 5.1 requires > > What we decided that we would not require, was for the SG/BITS/BITW to > assemble the fragmented packet before applying the policy. For *many* > (95%) site-to-site policies, we never need to look beyong layer-3 anyway, > so let's not make reassembly a requirement. > > Gandhar> implementation to perform policy lookup on the fragmented > Gandhar> packet. How can the implementation decide if the a packet > Gandhar> should be fragmented before knowing what policy (and SA) > Gandhar> will match? Moreover, the section 7.3 (reassembly for > Gandhar> policy verification) becomes redundant if implementation > > 7.3 is a MAY, and it's use is signaled. > If your system (because it's built into the stack) can do policy based > upon non-trivial port information, and will then fragment the packet > before tunnelling, it will therefore put packets in the tunnel which > the other end point will be unable to verify properly. > > Gandhar> Can someone please help me understand what I'm missing > Gandhar> here? > > Gandhar> Thanks and regards, Gandhar Gokhale Networking Components > Gandhar> Group LSI > > My guess is that you are building hardware, and you are trying to fit > all of the IPsec stack into your BITS hardware, not realizing that parts > can simply not be done unless the host stack is aware of your BITS. > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > > then sign the petition. > > > --bcaec54eea8e2a52ab04c87b97d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,
=A0
Thanks for sharing your thoughts.=A0If the IPsec "implementation&= quot;=A0receives a fragmented plain text packet for encrypting and sending = out then it is not really a pre-fragmentation. Pre-fragmentation requires t= he IPsec itself needs to decide whether to fragment an incoming plain text = fragment before encrypting it. The question is, how to make that decision i= f MTU & packet size is decided by policy and SA. RFC asks us to use a p= olicy with layer 3 selectors only for the non initial fragments. However, t= he decision to fragment can not be made without doing=A0policy lookup. This= is a circular dependancy.
My suspicion is that RFC expects us to look the full L4 policy for the= full packet and a subsequent policy lookup for each individual (non-initia= l) fragment though it does not explictly state so. This is not quite obviou= s from the description of the outbound processing in the RFC though and the= refore my suspicion may be invalid.
=A0
Thanks and regards,
Gandhar Gokhale
Networking Components Group
LSI
On Thu, Aug 30, 2012 at 5:41 PM, Michael Richard= son <mcr+ietf@sandelman.ca> wrote:

>>>>> "Gandha= r" =3D=3D Gandhar Gokhale <gandhar.ietf@gmail.com> writes:
=A0 =A0 Gandhar> relevant excerpt: *"Note: With the exception of IP= v4 and
=A0 =A0 Gandhar> IPv6 transport mode, an SG, BITS, or BITW imp= lementation
=A0 =A0 Gandhar> MAY fragment packets before applying IPs= ec. (This applies
=A0 =A0 Gandhar> only to IPv4. For IPv6 packets, only the originator is<= br>=A0 =A0 Gandhar> allowed to fragment them.) The device SHOULD have a<= br>
So, it's important to realize the "SG", "BITS&quo= t; and "BITW" parts all put
the IPsec at a distance from the IP layer. =A0So the fragmentation already<= br>occurred before (and maybe some distance) from the IPsec policy layer.
=A0 =A0 Gandhar> For deciding whether to fragment a packet we need= to know
=A0 =A0 Gandhar> the packet's length and MTU (or PMTU but to k) ofth= e
=A0 =A0 Gandhar> interface. IPsec tunnel alters length of the packe= t and
=A0 =A0 Gandhar> possibly outgoing interface as well. It means = the policy
=A0 =A0 Gandhar> affects the decision of whether a packet would get
= =A0 =A0 Gandhar> frameneted or not. However, RFC section 5.1 requires
What we decided that we would not require, was for the SG/BITS/BITW to=
assemble the fragmented packet before applying the policy. =A0For *many= *
(95%) site-to-site policies, we never need to look beyong layer-3 anyway,so let's not make reassembly a requirement.

=A0 =A0 Gandhar>= ; implementation to perform policy lookup on the fragmented
=A0 =A0 Gand= har> packet. How can the implementation decide if the a packet
=A0 =A0 Gandhar> should be fragmented before knowing what policy (and SA= )
=A0 =A0 Gandhar> will match? =A0Moreover, the section 7.3 (reassemb= ly for
=A0 =A0 Gandhar> policy verification) becomes redundant if imp= lementation

7.3 is a MAY, and it's use is signaled.
If your system (because = it's built into the stack) can do policy based
upon non-trivial port= information, and will then fragment the packet
before tunnelling, it wi= ll therefore put packets in the tunnel which
the other end point will be unable to verify properly.

=A0 =A0 Gandh= ar> Can someone please help me understand what I'm missing
=A0 = =A0 Gandhar> here?

=A0 =A0 Gandhar> Thanks and regards, Gandha= r Gokhale Networking Components
=A0 =A0 Gandhar> Group LSI

My guess is that you are building hard= ware, and you are trying to fit
all of the IPsec stack into your BITS ha= rdware, not realizing that parts
can simply not be done unless the host = stack is aware of your BITS.

--
] =A0 =A0 =A0 He w= ho is tired of Weird Al is tired of life! =A0 =A0 =A0 =A0 =A0 | =A0firewall= s =A0[
] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON = =A0 =A0|net architect[
] m= cr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[<= br> =A0 =A0Kyoto Plus: watch the video <http://www.youtube.com/watch?v=3Dkzx= 1ycLXQSE>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0then sig= n the petition.



--bcaec54eea8e2a52ab04c87b97d3--