From hipsec-bounces@lists.ietf.org Wed Mar 01 02:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELki-0002xf-6G; Wed, 01 Mar 2006 02:28:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELj0-0006YT-8y for hipsec@ietf.org; Wed, 01 Mar 2006 02:26:18 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FELei-00011z-SL for hipsec@ietf.org; Wed, 01 Mar 2006 02:21:57 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B57BE212CBE for ; Wed, 1 Mar 2006 09:21:50 +0200 (EET) Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id 8355D212CBC for ; Wed, 1 Mar 2006 09:21:50 +0200 (EET) From: Jan Mikael Melen To: HIP Date: Wed, 1 Mar 2006 09:21:59 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_XuUBEpTXEI1HpEy" Message-Id: <200603010921.59826.Jan.Melen@nomadiclab.com> X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Subject: [Hipsec] Fwd: I-D ACTION:draft-nikander-esp-beet-mode-05.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --Boundary-00=_XuUBEpTXEI1HpEy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46YI! =2D--------- Forwarded Message ---------- Subject: I-D ACTION:draft-nikander-esp-beet-mode-05.txt Date: Wednesday 01 March 2006 01:50 =46rom: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bound End-to-End Tunnel (BEET) mode for ESP Author(s) : J. Melen, P. Nikander Filename : draft-nikander-esp-beet-mode-05.txt Pages : 31 Date : 2006-2-28 This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-esp-beet-mode-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nikander-esp-beet-mode-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =2D------------------------------------------------------ =2D-=20 Jan M. Mel=E9n Research Scientist, NomadicLab, IP Networks,=20 Ericsson Research, Corporate Unit.=20 Tel. + 358 9 2993056=20 =46ax. + 358 9 2992448 Mobile + 358 400 836926 --Boundary-00=_XuUBEpTXEI1HpEy Content-Type: Message/External-body; name="draft-nikander-esp-beet-mode-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2006-2-28150147.I-D@ietf.org> --Boundary-00=_XuUBEpTXEI1HpEy Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --Boundary-00=_XuUBEpTXEI1HpEy-- From hipsec-bounces@lists.ietf.org Wed Mar 01 04:32:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FENgn-0006dn-KT; Wed, 01 Mar 2006 04:32:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FENgm-0006Yj-5l for hipsec@ietf.org; Wed, 01 Mar 2006 04:32:08 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FENgk-0005UZ-Qu for hipsec@ietf.org; Wed, 01 Mar 2006 04:32:08 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 01A2F2F35; Wed, 1 Mar 2006 11:32:05 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.0-niksula20040914 (2005-09-13) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 22EF42E43; Wed, 1 Mar 2006 11:32:03 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k219W2B19522; Wed, 1 Mar 2006 11:32:02 +0200 (EET) Date: Wed, 1 Mar 2006 11:32:02 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org, hipsec-rg@honor.trusecure.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Hipsec] HIP extensions for NAT traversal X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : HIP Extensions for the Traversal of Network Address Translators Author(s) : V. Schmitt, et al. Filename : draft-schmitt-hip-nat-traversal-00.txt Pages : 24 Date : 2006-2-28 This document specifies extensions to Host Identity Protocol (HIP) to support traversal of Network Address Translator (NAT) middleboxes. The traversal mechanism tunnels HIP control and data traffic over UDP and enables HIP initiators behind NATs to contact HIP responders in the global Internet. Future revisions of this document will describe mechanisms to contact HIP responders behind NATs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schmitt-hip-nat-traversal-00.txt On the courtesy of Petri Jokela from Ericsson, I opened up an issue tracker for the NAT draft: http://hip4inter.net/cgi-bin/roundup.cgi/hip-nat/index -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 01 15:57:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEYNY-0003Pn-Gc; Wed, 01 Mar 2006 15:57:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEYGq-0003fc-MN; Wed, 01 Mar 2006 15:50:04 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEYGq-0007xz-KC; Wed, 01 Mar 2006 15:50:04 -0500 Received: from [156.154.24.129] (helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEYGo-0005xG-DS; Wed, 01 Mar 2006 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k21Ko29W006343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEYGo-00012O-0t; Wed, 01 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 01 Mar 2006 15:50:02 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-mm-03.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : End-Host Mobility and Multihoming with the Host Identity Protocol Author(s) : P. Nikander Filename : draft-ietf-hip-mm-03.txt Pages : 48 Date : 2006-3-1 This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-mm-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-mm-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-1115739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-mm-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-mm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-1115739.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Thu Mar 02 17:08:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvy5-0008OJ-LA; Thu, 02 Mar 2006 17:08:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvy3-0008MQ-Pe for hipsec@ietf.org; Thu, 02 Mar 2006 17:08:15 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvy2-0007rK-Ey for hipsec@ietf.org; Thu, 02 Mar 2006 17:08:15 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA15878 for ; Thu, 2 Mar 2006 14:08:13 -0800 (PST) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k22M8Di13170 for ; Thu, 2 Mar 2006 14:08:13 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 14:08:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Mar 2006 14:07:35 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EDD6@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-hip-mm-03.txt Thread-Index: AcY9cztGvGPg+EnpSsqo+XOc5R/FpAA0ki/w From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 02 Mar 2006 22:08:08.0231 (UTC) FILETIME=[C9955370:01C63E45] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Hipsec] RE: I-D ACTION:draft-ietf-hip-mm-03.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 This draft has been revised and aligned with revisions to UPDATE processing in forthcoming base and ESP draft revisions. Appendix A.6 summarizes the main changes. According to our milestone schedule and meeting comments at IETF-64, we should be nearing WGLC on this document. Tom=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-03.txt >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 02 17:16:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEw5p-0004ea-Or; Thu, 02 Mar 2006 17:16:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEw5o-0004eG-Ef for hipsec@ietf.org; Thu, 02 Mar 2006 17:16:16 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEw5n-0008Br-5t for hipsec@ietf.org; Thu, 02 Mar 2006 17:16:16 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA22733; Thu, 2 Mar 2006 16:16:08 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k22MG7i28089; Thu, 2 Mar 2006 14:16:07 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 14:16:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Start re-chartering discussion in Vancouver? Date: Thu, 2 Mar 2006 14:15:49 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EDD7@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Start re-chartering discussion in Vancouver? Thread-Index: AcY3iS31eBf4KoAERl2NCA2RRtJB8AGvQZqg From: "Henderson, Thomas R" To: "Lars Eggert" X-OriginalArrivalTime: 02 Mar 2006 22:16:02.0557 (UTC) FILETIME=[E44DBAD0:01C63E46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: hipsec-rg@honor.trusecure.com, HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 > Sent: Wednesday, February 22, 2006 12:20 AM > Cc: HIP > Subject: Re: [Hipsec] Start re-chartering discussion in Vancouver? >=20 > Hi, >=20 > so we started the rechartering discussion in Vancouver, but=20 > it didn't =20 > carry over onto the mailing list. Has anyone started to put together =20 > a revised charter proposal? >=20 > Lars Pekka and I would like to propose that advancing the following informational draft be considered as one of the new charter items. Tom -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, March 01, 2006 12:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-henderson-hip-applications-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using HIP with Legacy Applications Author(s) : T. Henderson, P. Nikander Filename : draft-henderson-hip-applications-02.txt Pages : 12 Date : 2006-3-1 =09 The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family (e.g., AF_HOST), but it may be a long time until such HIP- aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is HIP-aware but the applications are not. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-02. txt _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Mar 05 02:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFo0J-0007aY-Lh; Sun, 05 Mar 2006 02:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFo0E-0007WI-BV; Sun, 05 Mar 2006 02:50:06 -0500 Received: from [156.154.16.129] (helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFo09-0007RI-Uy; Sun, 05 Mar 2006 02:50:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k257o1vP019973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 Mar 2006 07:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FFo09-00039y-HP; Sun, 05 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 05 Mar 2006 02:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-esp-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Using ESP transport format with HIP Author(s) : P. Jokela, et al. Filename : draft-ietf-hip-esp-02.txt Pages : 33 Date : 2006-3-4 This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-esp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-esp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-esp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-4205800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-esp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-esp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-4205800.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Sun Mar 05 02:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFo0H-0007Yy-Kd; Sun, 05 Mar 2006 02:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFo0E-0007W7-5Q; Sun, 05 Mar 2006 02:50:06 -0500 Received: from [156.154.16.129] (helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFo09-0007RJ-VY; Sun, 05 Mar 2006 02:50:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k257o1vP019974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 Mar 2006 07:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FFo09-0003A3-Hz; Sun, 05 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 05 Mar 2006 02:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-05.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-05.txt Pages : 100 Date : 2006-3-4 This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public-key identifiers from a new Host Identity name space for mutual peer authentication. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the- middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper layer protocols, suchs as TCP and UDP. Discussion related to this document is going on at the IETF HIP Working Group mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-4210157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-4210157.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Thu Mar 09 06:33:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJOQ-00023l-K5; Thu, 09 Mar 2006 06:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJOP-000200-JE for hipsec@ietf.org; Thu, 09 Mar 2006 06:33:17 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHJOO-0006lS-2o for hipsec@ietf.org; Thu, 09 Mar 2006 06:33:17 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 674A14F0003; Thu, 9 Mar 2006 12:33:15 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 12:33:10 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 12:33:06 +0100 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 03EC524A7; Thu, 9 Mar 2006 13:33:06 +0200 (EET) Message-ID: <44101271.7060703@ericsson.com> Date: Thu, 09 Mar 2006 13:33:05 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 11:33:06.0168 (UTC) FILETIME=[3BE02780:01C6436D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Hipsec] Agenda requests X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, you can send me your agenda requests if you want to present something in the session in Dallas. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Mar 13 01:06:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIgCd-0006NB-Sl; Mon, 13 Mar 2006 01:06:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIgCc-0006N6-S6 for hipsec@ietf.org; Mon, 13 Mar 2006 01:06:46 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIgCX-00027h-Uv for hipsec@ietf.org; Mon, 13 Mar 2006 01:06:46 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B344F5D1; Mon, 13 Mar 2006 07:06:40 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 07:06:40 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 07:06:40 +0100 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 234A724A7; Mon, 13 Mar 2006 08:06:40 +0200 (EET) Message-ID: <44150BEF.3090305@ericsson.com> Date: Mon, 13 Mar 2006 08:06:39 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 06:06:40.0332 (UTC) FILETIME=[4B75C0C0:01C64664] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Hipsec] WGLC draft-ietf-hip-mm-03.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, we would like to working group last call the following draft. This working group last call will end on April 2nd.. http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-03.txt Send your comments to this list. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Mar 13 01:38:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIghM-0001tx-Iw; Mon, 13 Mar 2006 01:38:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIghM-0001ts-16 for hipsec@ietf.org; Mon, 13 Mar 2006 01:38:32 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIghG-0002YO-Fi for hipsec@ietf.org; Mon, 13 Mar 2006 01:38:32 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A4ECA4F0002 for ; Mon, 13 Mar 2006 07:38:25 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 07:38:25 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 07:38:25 +0100 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E6D9524A7 for ; Mon, 13 Mar 2006 08:38:24 +0200 (EET) Message-ID: <44151360.7020500@ericsson.com> Date: Mon, 13 Mar 2006 08:38:24 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 06:38:25.0211 (UTC) FILETIME=[BADB38B0:01C64668] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Hipsec] Draft status X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, FYI: you can find the current status of our WG items at the following site: http://hip.piuha.net/drafts/ As you can see, as soon as the Security area directors propose somebody to perform the Belovin-Resorla analysis on the main spec, we will be able to request the publication of all our current WG items. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Mar 13 02:14:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIhGM-0008Rj-7j; Mon, 13 Mar 2006 02:14:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIhGK-0008RY-H8 for hipsec@ietf.org; Mon, 13 Mar 2006 02:14:40 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIhGE-0003Ka-KV for hipsec@ietf.org; Mon, 13 Mar 2006 02:14:40 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C51074F0001; Mon, 13 Mar 2006 08:14:33 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 08:14:33 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 08:14:33 +0100 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4DC3424A7; Mon, 13 Mar 2006 09:14:33 +0200 (EET) Message-ID: <44151BD8.1070609@ericsson.com> Date: Mon, 13 Mar 2006 09:14:32 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 07:14:33.0354 (UTC) FILETIME=[C72B96A0:01C6466D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Hipsec] Draft agenda, IETF 65 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, this is the draft agenda for the upcoming face-to-face meeting in Dallas. http://www3.ietf.org/proceedings/06mar/agenda/hip.html Any comments? Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Mar 13 18:15:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIwGZ-000214-N4; Mon, 13 Mar 2006 18:15:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIwGX-00020V-Jp for hipsec@ietf.org; Mon, 13 Mar 2006 18:15:54 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIwGV-00019k-24 for hipsec@ietf.org; Mon, 13 Mar 2006 18:15:53 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA29607; Mon, 13 Mar 2006 15:15:46 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2DNFjC17139; Mon, 13 Mar 2006 15:15:45 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 15:15:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Draft status Date: Mon, 13 Mar 2006 15:15:44 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EE4F@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <44151360.7020500@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Draft status Thread-Index: AcZGaMgtgLSY9FELTKiyOYHkPzVK9wAitdPw From: "Henderson, Thomas R" To: "Gonzalo Camarillo" , "HIP" X-OriginalArrivalTime: 13 Mar 2006 23:15:43.0904 (UTC) FILETIME=[0D7F2A00:01C646F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Gonzalo, could you please clarify a procedural question? A number of our drafts have dependencies (both "normative" and "informative") on I-Ds, some of which may or may not live on as RFCs. What happens when we request publication of our I-Ds as experimental; will they be held up in RFC Editor's queue pending publication of normative references, informative references, etc.? Should experimental drafts even distinguish between normative and informative references? If there is an RFC where this is defined for experimental drafts, can you please point me to it? Thanks, Tom=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Sunday, March 12, 2006 10:38 PM > To: HIP > Subject: [Hipsec] Draft status >=20 > Folks, >=20 > FYI: you can find the current status of our WG items at the=20 > following site: > http://hip.piuha.net/drafts/ >=20 > As you can see, as soon as the Security area directors=20 > propose somebody=20 > to perform the Belovin-Resorla analysis on the main spec, we will be=20 > able to request the publication of all our current WG items. >=20 > Cheers, >=20 > Gonzalo >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Mar 14 02:43:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ4BF-0003B7-LX; Tue, 14 Mar 2006 02:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ4BD-0003B2-JY for hipsec@ietf.org; Tue, 14 Mar 2006 02:42:55 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ4B8-0008TM-Lk for hipsec@ietf.org; Tue, 14 Mar 2006 02:42:55 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2083253E; Tue, 14 Mar 2006 08:42:50 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 08:42:49 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 08:42:49 +0100 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4AFAD2574; Tue, 14 Mar 2006 09:42:49 +0200 (EET) Message-ID: <441673F8.4080508@ericsson.com> Date: Tue, 14 Mar 2006 09:42:48 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] Draft status References: <77F357662F8BFA4CA7074B0410171B6D01A2EE4F@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EE4F@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 07:42:49.0276 (UTC) FILETIME=[E46E7FC0:01C6473A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, RFCs-to-be are never held up due to their informative references. Only normative references matter for the RFC editor when it comes to publishing the RFC. I am not sure whether this is also the case for experimental RFCs. I will try and figure it out. In any case, distinguishing between informative and normative references is always useful, even in Informational RFCs. Normative references are the ones you need to understand in order to understand the specification. Informative references are nice to read, but not essential. Cheers, Gonzalo Henderson, Thomas R wrote: > Gonzalo, could you please clarify a procedural question? A number of > our drafts have dependencies (both "normative" and "informative") on > I-Ds, some of which may or may not live on as RFCs. What happens when > we request publication of our I-Ds as experimental; will they be held up > in RFC Editor's queue pending publication of normative references, > informative references, etc.? Should experimental drafts even > distinguish between normative and informative references? > > If there is an RFC where this is defined for experimental drafts, can > you please point me to it? > > Thanks, > Tom > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Sunday, March 12, 2006 10:38 PM >> To: HIP >> Subject: [Hipsec] Draft status >> >> Folks, >> >> FYI: you can find the current status of our WG items at the >> following site: >> http://hip.piuha.net/drafts/ >> >> As you can see, as soon as the Security area directors >> propose somebody >> to perform the Belovin-Resorla analysis on the main spec, we will be >> able to request the publication of all our current WG items. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Mar 14 12:19:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDBC-0006wN-6s; Tue, 14 Mar 2006 12:19:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDBA-0006qr-NS for hipsec@ietf.org; Tue, 14 Mar 2006 12:19:28 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDB9-00081W-BQ for hipsec@ietf.org; Tue, 14 Mar 2006 12:19:28 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA02819; Tue, 14 Mar 2006 09:19:16 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2EHJFC03863; Tue, 14 Mar 2006 09:19:15 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 09:19:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Draft agenda, IETF 65 Date: Tue, 14 Mar 2006 09:19:13 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EE61@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <44151BD8.1070609@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Draft agenda, IETF 65 Thread-Index: AcZGbdQ/fl3zSMuvRXWfQJDmFDEXDgBHBh3w From: "Henderson, Thomas R" To: "Gonzalo Camarillo" , "HIP" X-OriginalArrivalTime: 14 Mar 2006 17:19:14.0008 (UTC) FILETIME=[6A89CD80:01C6478B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org If you intend to discuss NAT traversal (as possible new charter item), there are additional drafts that have been worked on in the RG, if you want to have a broader discussion: Title : Traversing HIP-aware NATs and Firewalls: Problem Statement and Requirements Author(s) : H. Tschofenig, M. Shanmugam Filename : draft-tschofenig-hiprg-hip-natfw-traversal-04.txt Title : Preferred Alternatives for Tunnelling HIP (PATH) Author(s) : P. Nikander, et al. Filename : draft-nikander-hip-path-01.txt Title : Middlebox Traversal Issues of Host Identity Protocol (HIP) Communication Author(s) : M. Stiemerling Filename : draft-irtf-hiprg-nat-01.txt In particular, the latter document is a problem statement that might be suitable for the WG if it recharters to cover legacy NAT traversal. It is currently in the queue for IRSG approval as Informational. I also would like to propose that the following draft (and subject matter) be considered in the rechartering discussion: Title : Using HIP with Legacy Applications Author(s) : T. Henderson, P. Nikander Filename : draft-henderson-hip-applications-02.txt Tom > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Sunday, March 12, 2006 11:15 PM > To: HIP > Subject: [Hipsec] Draft agenda, IETF 65 >=20 > Folks, >=20 > this is the draft agenda for the upcoming face-to-face=20 > meeting in Dallas. > http://www3.ietf.org/proceedings/06mar/agenda/hip.html >=20 > Any comments? >=20 > Thanks, >=20 > Gonzalo > HIP co-chair >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 15 01:55:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJPv1-0001I0-83; Wed, 15 Mar 2006 01:55:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJPu7-0000kp-3d for hipsec@ietf.org; Wed, 15 Mar 2006 01:54:43 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJPkm-00052o-5b for hipsec@ietf.org; Wed, 15 Mar 2006 01:45:09 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ED6CD4F003F; Wed, 15 Mar 2006 07:44:44 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 07:44:44 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 07:44:44 +0100 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 38E252441; Wed, 15 Mar 2006 08:44:44 +0200 (EET) Message-ID: <4417B7DB.7050700@ericsson.com> Date: Wed, 15 Mar 2006 08:44:43 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Hipsec] Draft status References: <77F357662F8BFA4CA7074B0410171B6D01A2EE4F@XCH-NW-5V1.nw.nos.boeing.com> <441673F8.4080508@ericsson.com> In-Reply-To: <441673F8.4080508@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2006 06:44:44.0375 (UTC) FILETIME=[F1AE8E70:01C647FB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, FYI: a discussion in the IESG about this issue has started. It is not clear yet what the conclusion will be. I will keep you updated. Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi, > > RFCs-to-be are never held up due to their informative references. Only > normative references matter for the RFC editor when it comes to > publishing the RFC. > > I am not sure whether this is also the case for experimental RFCs. I > will try and figure it out. > > In any case, distinguishing between informative and normative references > is always useful, even in Informational RFCs. Normative references are > the ones you need to understand in order to understand the > specification. Informative references are nice to read, but not essential. > > Cheers, > > Gonzalo > > Henderson, Thomas R wrote: >> Gonzalo, could you please clarify a procedural question? A number of >> our drafts have dependencies (both "normative" and "informative") on >> I-Ds, some of which may or may not live on as RFCs. What happens when >> we request publication of our I-Ds as experimental; will they be held up >> in RFC Editor's queue pending publication of normative references, >> informative references, etc.? Should experimental drafts even >> distinguish between normative and informative references? >> >> If there is an RFC where this is defined for experimental drafts, can >> you please point me to it? >> >> Thanks, >> Tom >>> -----Original Message----- >>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: >>> Sunday, March 12, 2006 10:38 PM >>> To: HIP >>> Subject: [Hipsec] Draft status >>> >>> Folks, >>> >>> FYI: you can find the current status of our WG items at the following >>> site: >>> http://hip.piuha.net/drafts/ >>> >>> As you can see, as soon as the Security area directors propose >>> somebody to perform the Belovin-Resorla analysis on the main spec, we >>> will be able to request the publication of all our current WG items. >>> >>> Cheers, >>> >>> Gonzalo >>> _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 16 01:26:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJlwM-0004IH-Cz; Thu, 16 Mar 2006 01:26:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJlwL-0004IC-Q7 for hipsec@ietf.org; Thu, 16 Mar 2006 01:26:29 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJlwI-0006YK-BG for hipsec@ietf.org; Thu, 16 Mar 2006 01:26:29 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CC1E089875; Thu, 16 Mar 2006 08:26:24 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7706189843; Thu, 16 Mar 2006 08:26:24 +0200 (EET) Message-ID: <4419050B.4050100@piuha.net> Date: Thu, 16 Mar 2006 08:26:19 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] Draft status References: <77F357662F8BFA4CA7074B0410171B6D01A2EE4F@XCH-NW-5V1.nw.nos.boeing.com> <441673F8.4080508@ericsson.com> <4417B7DB.7050700@ericsson.com> In-Reply-To: <4417B7DB.7050700@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org >>> A number of >>> our drafts have dependencies (both "normative" and "informative") on >>> I-Ds, some of which may or may not live on as RFCs. >> Gonzalo and I looked at this yesterday in some detail. Out of all WG drafts in HIP WG, the normative references sections contain items of four types: 1. Already stable references such as RFCs. 2. References to drafts that have actually already been published as RFCs (e.g. NAI spec, some of the IPsec documents) 3. References to HIP WG's own RFCs. I would expect most of these to come in the natural order, e.g., arch comes first, base then, and then extensions building on top of base. No problem here, I think. 4. The one remaining exception that we were able to find was the KHI draft. The nature of the reference made me think that the WG probably wants KHI to be an RFC before your RFC becomes out. That is, you do no want to depend on a HIT format unless you are sure it doesn't collide with a real IPv6 address range. But its your call. If you do this then there is no procedural question, I think. For convenience of the reader I would in any case recommend normative/informative reference sections to be kept separate. But if KHI does not go forward and you still want to use it in the base RFC, then the procedural question is very relevant. As Gonzalo noted, the IESG is discussing what the actual requirement from Experimental RFCs is. Did we miss any problematic reference? What is your take on the KHI reference? --Jari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 16 04:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJofG-0004bt-4F; Thu, 16 Mar 2006 04:21:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJofF-0004bo-1p for hipsec@ietf.org; Thu, 16 Mar 2006 04:21:01 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJofD-0002bl-Ng for hipsec@ietf.org; Thu, 16 Mar 2006 04:21:01 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CE3C0212C52; Thu, 16 Mar 2006 11:20:57 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8CE0C212C4E; Thu, 16 Mar 2006 11:20:57 +0200 (EET) In-Reply-To: <4419050B.4050100@piuha.net> References: <77F357662F8BFA4CA7074B0410171B6D01A2EE4F@XCH-NW-5V1.nw.nos.boeing.com> <441673F8.4080508@ericsson.com> <4417B7DB.7050700@ericsson.com> <4419050B.4050100@piuha.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ACBF507-EDDA-4AB9-9C4B-1BDEEE3A5269@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Draft status Date: Thu, 16 Mar 2006 11:20:57 +0200 To: Jari Arkko X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > > What is your take on the KHI reference? Technically, KHI (or ORCHID which is the new name) is IMHO in pretty good shape. Procedurally, a problem is that I've run out of almost all IETF steam and can't motivate myself to care much about it. In other words, from my side KHI is a half-orphan looking for a step parent. I don't know about Julien's or Francis'es plans. http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-01.txt --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 16 04:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJp7P-0004c2-Q6; Thu, 16 Mar 2006 04:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJp7O-0004b6-4j for hipsec@ietf.org; Thu, 16 Mar 2006 04:50:06 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJp7M-0003CG-QR for hipsec@ietf.org; Thu, 16 Mar 2006 04:50:06 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D46542EF3; Thu, 16 Mar 2006 11:50:03 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.0-niksula20040914 (2005-09-13) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5A2B12EF0; Thu, 16 Mar 2006 11:50:03 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k2G9o2F21954; Thu, 16 Mar 2006 11:50:02 +0200 (EET) Date: Thu, 16 Mar 2006 11:50:02 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] Draft status In-Reply-To: <7ACBF507-EDDA-4AB9-9C4B-1BDEEE3A5269@nomadiclab.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2EE4F@XCH-NW-5V1.nw.nos.boeing.com> <441673F8.4080508@ericsson.com> <4417B7DB.7050700@ericsson.com> <4419050B.4050100@piuha.net> <7ACBF507-EDDA-4AB9-9C4B-1BDEEE3A5269@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 16 Mar 2006, Pekka Nikander wrote: > > What is your take on the KHI reference? > > Technically, KHI (or ORCHID which is the new name) is IMHO in pretty > good shape. > > Procedurally, a problem is that I've run out of almost all IETF steam > and can't motivate myself to care much about it. In other words, > from my side KHI is a half-orphan looking for a step parent. I don't > know about Julien's or Francis'es plans. > > http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-01.txt FYI: this is already known by the draft authors, but the latest published base draft references still 00 version. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 16 09:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJt1F-00076S-Rz; Thu, 16 Mar 2006 09:00:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJt1F-000766-3j for hipsec@ietf.org; Thu, 16 Mar 2006 09:00:01 -0500 Received: from mail.av.it.pt ([193.136.92.53] helo=av.it.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJt1D-0002fl-47 for hipsec@ietf.org; Thu, 16 Mar 2006 09:00:01 -0500 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.av.it.pt X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-TFF-CGPSA-Version: 1.4 X-TFF-CGPSA-Filter: Scanned Received: from [193.136.92.84] (account alfredo.matos [193.136.92.84] verified) by av.it.pt (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 4253907; Thu, 16 Mar 2006 13:57:58 +0000 Message-ID: <44196F6C.5010205@av.it.pt> Date: Thu, 16 Mar 2006 14:00:12 +0000 From: Alfredo Matos User-Agent: Mail/News 1.5 (X11/20060309) MIME-Version: 1.0 To: hipsec@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Marco Liebsch , Rui Aguiar , =?ISO-8859-1?Q?Jo=E3o_Gir=E3o?= Subject: [Hipsec] I-D ACTION:draft-matos-hip-privacy-extensions-01.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Dear all, We have submitted a revision of draft-matos-hip-privacy-extensions. Diffs from version 00 are at: http://hng.av.it.pt/~alfmatos/files/draft-matos-hip-privacy-extensions-01-htmlwdiff.html Comments are appreciated. Best Regards, Alfredo Matos -------- Original Message -------- Subject: I-D ACTION:draft-matos-hip-privacy-extensions-01.txt Date: Thu, 09 Mar 2006 15:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Identity Protocol Location Privacy Extensions Author(s) : A. Matos, et al. Filename : draft-matos-hip-privacy-extensions-01.txt Pages : 36 Date : 2006-3-9 This memo describes a framework for the Host Identity Protocol that provides location privacy and mobility to end hosts. It discusses the introduction of a new functional entity that prevents HIP enabled nodes from revealing their location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-matos-hip-privacy-extensions-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-matos-hip-privacy-extensions-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-matos-hip-privacy-extensions-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 16 10:27:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuO4-0002E3-Lb; Thu, 16 Mar 2006 10:27:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuO3-0002Dy-MY for hipsec@ietf.org; Thu, 16 Mar 2006 10:27:39 -0500 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJuO3-0005RX-Dh for hipsec@ietf.org; Thu, 16 Mar 2006 10:27:39 -0500 Received: from [192.168.1.102] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 43F3475B015E79DF; Thu, 16 Mar 2006 16:20:10 +0100 From: Julien Laganier To: hipsec@lists.ietf.org Subject: Re: [Hipsec] Draft status Date: Thu, 16 Mar 2006 16:20:09 +0100 User-Agent: KMail/1.8.2 References: <77F357662F8BFA4CA7074B0410171B6D01A2EE4F@XCH-NW-5V1.nw.nos.boeing.com> <4419050B.4050100@piuha.net> <7ACBF507-EDDA-4AB9-9C4B-1BDEEE3A5269@nomadiclab.com> In-Reply-To: <7ACBF507-EDDA-4AB9-9C4B-1BDEEE3A5269@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603161620.10277.julien.IETF@laposte.net> X-Spam-Score: 1.8 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thursday 16 March 2006 10:20, Pekka Nikander wrote: > > What is your take on the KHI reference? > > Technically, KHI (or ORCHID which is the new name) is IMHO in > pretty good shape. > > Procedurally, a problem is that I've run out of almost all IETF > steam and can't motivate myself to care much about it. In other > words, from my side KHI is a half-orphan looking for a step parent. > I don't know about Julien's or Francis'es plans. I just sent an email to int-area (cross-posted on ipv6 and hipsec) asking how to move forward with this draft. Wait and see. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 16 10:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJufN-0007Nh-IT; Thu, 16 Mar 2006 10:45:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJufM-0007Nc-Sh for hipsec@ietf.org; Thu, 16 Mar 2006 10:45:32 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJufL-000679-G5 for hipsec@ietf.org; Thu, 16 Mar 2006 10:45:32 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA10020; Thu, 16 Mar 2006 07:45:18 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2GFjHw22433; Thu, 16 Mar 2006 09:45:17 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 07:45:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Draft status Date: Thu, 16 Mar 2006 07:45:15 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EE92@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <4419050B.4050100@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Draft status Thread-Index: AcZIwo6u/Rjkxd6nRXKTUsHy/YFzMgAS9n2w From: "Henderson, Thomas R" To: "Jari Arkko" X-OriginalArrivalTime: 16 Mar 2006 15:45:15.0611 (UTC) FILETIME=[9E9E32B0:01C64910] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > Did we miss any problematic reference? What is your take > on the KHI reference? >=20 The KHI is the main one that concerns me, because although I agree with Pekka that it is in good shape technically, it doesn't seem to be on a path to WG sponsorship AFAIK. =20 Is KHI (ORCHID) on the agenda for discussion anywhere in Dallas meeting? Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 16 10:48:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuiF-0007sx-Vw; Thu, 16 Mar 2006 10:48:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuiE-0007ss-S7 for hipsec@lists.ietf.org; Thu, 16 Mar 2006 10:48:30 -0500 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJuiE-0006D1-Jg for hipsec@lists.ietf.org; Thu, 16 Mar 2006 10:48:30 -0500 Received: from [192.168.1.102] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 43F3475B015E79DF; Thu, 16 Mar 2006 16:20:10 +0100 From: Julien Laganier To: hipsec@lists.ietf.org Subject: Re: [Hipsec] Draft status Date: Thu, 16 Mar 2006 16:20:09 +0100 User-Agent: KMail/1.8.2 References: <77F357662F8BFA4CA7074B0410171B6D01A2EE4F@XCH-NW-5V1.nw.nos.boeing.com> <4419050B.4050100@piuha.net> <7ACBF507-EDDA-4AB9-9C4B-1BDEEE3A5269@nomadiclab.com> In-Reply-To: <7ACBF507-EDDA-4AB9-9C4B-1BDEEE3A5269@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603161620.10277.julien.IETF@laposte.net> X-Spam-Score: 1.8 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thursday 16 March 2006 10:20, Pekka Nikander wrote: > > What is your take on the KHI reference? > > Technically, KHI (or ORCHID which is the new name) is IMHO in > pretty good shape. > > Procedurally, a problem is that I've run out of almost all IETF > steam and can't motivate myself to care much about it. In other > words, from my side KHI is a half-orphan looking for a step parent. > I don't know about Julien's or Francis'es plans. I just sent an email to int-area (cross-posted on ipv6 and hipsec) asking how to move forward with this draft. Wait and see. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 16 17:21:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0qD-0003N7-JM; Thu, 16 Mar 2006 17:21:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0qB-0003Ma-80; Thu, 16 Mar 2006 17:21:07 -0500 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0qA-0003fI-SF; Thu, 16 Mar 2006 17:21:07 -0500 Received: from [192.168.1.102] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 43839F3B03C185EF; Thu, 16 Mar 2006 16:24:11 +0100 From: Julien Laganier To: Internet Area User-Agent: KMail/1.8.2 MIME-Version: 1.0 Date: Thu, 16 Mar 2006 16:24:15 +0100 Content-Type: Multipart/Mixed; boundary="Boundary-00=_gMYGEpJiQIOCU4t" Message-Id: <200603161624.16174.julien.IETF@laposte.net> X-Spam-Score: 1.8 (+) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: HIP , ipv6@ietf.org Subject: [Hipsec] Fwd: I-D ACTION:draft-laganier-ipv6-khi-01.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --Boundary-00=_gMYGEpJiQIOCU4t Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline [ Cross-posted to HIP WG and IPv6 WG. ] [ Please reply _only_ to the INT area. ] Folks, draft-laganier-ipv6-khi-01.txt has been updated based on feedback received from IETFers. The HIP base specification currently has a hard dependency on this draft and therefore it would be desirable to have it published as an RFC as soon as possible, since the HIP base specification is now quite mature. This draft intent is to make it possible for existing applications running on a HIP node to use both HIP and IPv6 at the same time, in the hope that it will foster the HIP experiment. Your opinions on moving forward with this draft are more than welcomed. Best regards, --julien ---------- Forwarded Message ---------- Subject: I-D ACTION:draft-laganier-ipv6-khi-01.txt Date: Friday 03 March 2006 21:50 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) Author(s) : P. Nikander, et al. Filename : draft-laganier-ipv6-khi-01.txt Pages : 14 Date : 2006-3-3 This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as end- point identifiers at applications and APIs and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered as non-routable addresses from the IPv6 layer point of view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-laganier-ipv6-khi-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-laganier-ipv6-khi-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------- -- julien -- julien --Boundary-00=_gMYGEpJiQIOCU4t Content-Type: Message/External-body; name="draft-laganier-ipv6-khi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2006-3-3131321.I-D@ietf.org> --Boundary-00=_gMYGEpJiQIOCU4t Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --Boundary-00=_gMYGEpJiQIOCU4t-- From hipsec-bounces@lists.ietf.org Thu Mar 16 23:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK6nT-0003ss-UC; Thu, 16 Mar 2006 23:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK6nT-0003sn-K5 for hipsec@ietf.org; Thu, 16 Mar 2006 23:42:43 -0500 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK6nR-0008M4-9U for hipsec@ietf.org; Thu, 16 Mar 2006 23:42:43 -0500 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FK6nE-0004kx-00; Thu, 16 Mar 2006 23:42:28 -0500 From: Tim Shepard To: Pekka Nikander Subject: KHI/ORCHIRD (was Re: [Hipsec] Draft status ) In-reply-to: Your message of Thu, 16 Mar 2006 11:20:57 +0200. <7ACBF507-EDDA-4AB9-9C4B-1BDEEE3A5269@nomadiclab.com> Date: Thu, 16 Mar 2006 23:42:28 -0500 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-01.txt I just took a quick look at that draft, and unless I missed it, it lacks a field of bits to identify the hash function being used. BTW, I agree with the reasoning in section 4 about folding the context ID into the hash input. But we still need tag on the outside showing which crypto algorithm is being depended upon to secure the binding. > Procedurally, a problem is that I've run out of almost all IETF steam > and can't motivate myself to care much about it. In other words, > from my side KHI is a half-orphan looking for a step parent. I don't > know about Julien's or Francis'es plans. I'm thinking that this is perhaps not the best approach to deal with a legacy application. Something similar, that does not necessarily need this sort of KHI/ORCHID mechanism might be better: run the application in an environment where its library and/or system calls are intercepted. In other words, make a "hipify" program that works much like the "socksify" program can be used to make non-socks-enabled clients (of many different protocols) talk to the internet through a socks proxy. This then allows for a lot more flexibility in figuring out how to make "hipify" do-the-right-thing for a legacy (non-hip-aware) application. For example, the calls to DNS could be noted, along with the replies, and the context could be kept in the magic libraries that are wrapping or diverting the system and library calls. We wouldn't necessarily need to squeeze HITs accross an interface that was supposed to carry an IPv6 address (or if we do, then the magic is entirely confined to the magic library that hipify uses, and doesn't have to mess with the kernel). (The socksify program that I've used is part of the dante package which is open source and can be found at http://www.inet.no/dante/ ). ((Is this the right list for this thought?)) -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 16 23:54:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK6zJ-00046f-Un; Thu, 16 Mar 2006 23:54:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK6zJ-00046X-1p for hipsec@ietf.org; Thu, 16 Mar 2006 23:54:57 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK6zH-0000Av-Nj for hipsec@ietf.org; Thu, 16 Mar 2006 23:54:57 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4C919212C59; Fri, 17 Mar 2006 06:54:54 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id F1A8A212C4C; Fri, 17 Mar 2006 06:54:53 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: KHI/ORCHIRD (was Re: [Hipsec] Draft status ) Date: Fri, 17 Mar 2006 06:54:54 +0200 To: Tim Shepard X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org >> http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-01.txt > > I just took a quick look at that draft, and unless I missed it, it > lacks a field of bits to identify the hash function being used. > > BTW, I agree with the reasoning in section 4 about folding the context > ID into the hash input. > > But we still need tag on the outside showing which crypto algorithm is > being depended upon to secure the binding. That is discussed in security considerations. The prefix acts as that tag. (I don't have time right now to consider your other comment, sorry.) --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Mar 17 00:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK7zt-00027j-DD; Fri, 17 Mar 2006 00:59:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK7zs-00027e-Em for hipsec@ietf.org; Fri, 17 Mar 2006 00:59:36 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK7zr-0001mR-38 for hipsec@ietf.org; Fri, 17 Mar 2006 00:59:36 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id VAA18985; Thu, 16 Mar 2006 21:59:19 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2H5xIw29057; Thu, 16 Mar 2006 23:59:18 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 21:59:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: KHI/ORCHIRD (was Re: [Hipsec] Draft status ) Date: Thu, 16 Mar 2006 21:58:47 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EEA3@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KHI/ORCHIRD (was Re: [Hipsec] Draft status ) Thread-Index: AcZJfUEyJOT2zfe6SqynD12dmZuUMAACauXw From: "Henderson, Thomas R" To: "Tim Shepard" , "Pekka Nikander" X-OriginalArrivalTime: 17 Mar 2006 05:59:09.0685 (UTC) FILETIME=[E8817A50:01C64987] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 >=20 > I'm thinking that this is perhaps not the best approach to deal with a > legacy application. =20 >=20 I think that the library approach you mention is valid also, and offers different levels of granularity of invoking HIP, and different reliance on DNS, than does an approach that uses HITs as IP addresses at the API. Teemu Koponen mentioned that approach to me last month as well. I would prefer that both approaches are supportable for experimentation. > ((Is this the right list for this thought?)) Perhaps moving future responses to HIP RG list would be appropriate (since legacy application discussions have previously been declared out of our current WG charter). Please see also: http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-02. txt Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Mar 17 01:22:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK8Lo-00005c-CP; Fri, 17 Mar 2006 01:22:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK8Ln-00005X-LU for hipsec@ietf.org; Fri, 17 Mar 2006 01:22:15 -0500 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK8Ll-0002XN-Dt for hipsec@ietf.org; Fri, 17 Mar 2006 01:22:15 -0500 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FK8Lf-0004tx-00; Fri, 17 Mar 2006 01:22:07 -0500 From: Tim Shepard To: Pekka Nikander Subject: Re: KHI/ORCHIRD (was Re: [Hipsec] Draft status ) In-reply-to: Your message of Fri, 17 Mar 2006 06:54:54 +0200. Date: Fri, 17 Mar 2006 01:22:07 -0500 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > That is discussed in security considerations. The prefix acts as > that tag. Ah, indeed it does. I have now read it, and it is good. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Mar 17 03:47:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAc6-0008QG-KQ; Fri, 17 Mar 2006 03:47:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAc5-0008QA-4h for hipsec@ietf.org; Fri, 17 Mar 2006 03:47:13 -0500 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKAc2-0006BY-Gy for hipsec@ietf.org; Fri, 17 Mar 2006 03:47:12 -0500 Received: from [192.168.1.102] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 43C4E5FA024423CB; Fri, 17 Mar 2006 09:18:44 +0100 From: Julien Laganier To: Tim Shepard , HIP Subject: Re: KHI/ORCHIRD (was Re: [Hipsec] Draft status ) Date: Fri, 17 Mar 2006 09:18:10 +0100 User-Agent: KMail/1.8.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603170918.10341.julien.IETF@laposte.net> X-Spam-Score: 1.8 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Tim, Thanks for your thoughts on that matter, more below... On Friday 17 March 2006 05:42, Tim Shepard wrote: > > I'm thinking that this is perhaps not the best approach to deal > with a legacy application. > > Something similar, that does not necessarily need this sort of > KHI/ORCHID mechanism might be better: run the application in an > environment where its library and/or system calls are intercepted. > In other words, make a "hipify" program that works much like the > "socksify" program can be used to make non-socks-enabled clients > (of many different protocols) talk to the internet through a socks > proxy. > > This then allows for a lot more flexibility in figuring out how to > make "hipify" do-the-right-thing for a legacy (non-hip-aware) > application. For example, the calls to DNS could be noted, along > with the replies, and the context could be kept in the magic > libraries that are wrapping or diverting the system and library > calls. We wouldn't necessarily need to squeeze HITs accross an > interface that was supposed to carry an IPv6 address (or if we do, > then the magic is entirely confined to the magic library that > hipify uses, and doesn't have to mess with the kernel). I used this approach in the past to implement the client side of RSIP (RFC3103). Hence I naturally thought to use it with HIP as well. It has however a certain number of issues, amongst which the two mostly prominent are: - does not work with setuid programs. - If per-socket context has to be kept (e.g. based on DNS queries) in libraries, when to delete it? Some sockets are never closed, program just exit after fork and service. I never completely figured out how to solve these _and_ staying entirely in libraries, hence I tend to think that one has to go in kernel too. This end up with too much unwanted complexity, IMHO. The KHI/ORCHID approach has the advantage that it is both simple and working. We just want IANA not to allocate that prefix so we could use it safely as a tag saying that HIP is to be used. Cheers, --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Mar 17 14:40:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKo9-0001Il-7r; Fri, 17 Mar 2006 14:40:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKo8-0001Ig-Lo for hipsec@ietf.org; Fri, 17 Mar 2006 14:40:20 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKKo7-0002iG-7q for hipsec@ietf.org; Fri, 17 Mar 2006 14:40:20 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7F5BB212C59; Fri, 17 Mar 2006 21:40:17 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 73CB9212C4C; Fri, 17 Mar 2006 21:40:15 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F9D3863-B628-483F-9E30-162D698876BB@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: KHI/ORCHIRD (was Re: [Hipsec] Draft status ) Date: Fri, 17 Mar 2006 21:40:13 +0200 To: Tim Shepard X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > I'm thinking that this is perhaps not the best approach to deal with a > legacy application. > > Something similar, that does not necessarily need this sort of > KHI/ORCHID mechanism might be better: run the application in an > environment where its library and/or system calls are intercepted. In > other words, make a "hipify" program that works much like the > "socksify" program can be used to make non-socks-enabled clients (of > many different protocols) talk to the internet through a socks proxy. > > This then allows for a lot more flexibility in figuring out how to > make "hipify" do-the-right-thing for a legacy (non-hip-aware) > application. For example, the calls to DNS could be noted, along with > the replies, and the context could be kept in the magic libraries that > are wrapping or diverting the system and library calls. We wouldn't > necessarily need to squeeze HITs accross an interface that was > supposed to carry an IPv6 address (or if we do, then the magic is > entirely confined to the magic library that hipify uses, and doesn't > have to mess with the kernel). I don't think whether you use a library or patch system calls really makes any difference. The problem stems from the potential confusion cause by applications "leaking" ORCHIDs, e.g., as they do referrals. There is little you can do about that, independent on how you implement the stuff locally. See the second and third paragraph in Section 1.1. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Mar 21 22:52:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLuOo-0007ZG-7t; Tue, 21 Mar 2006 22:52:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLuOm-0007ZB-G2 for hipsec@ietf.org; Tue, 21 Mar 2006 22:52:40 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLuOl-0001wQ-VZ for hipsec@ietf.org; Tue, 21 Mar 2006 22:52:40 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id TAA07038; Tue, 21 Mar 2006 19:52:31 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2M3qUb09635; Tue, 21 Mar 2006 19:52:30 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 19:52:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 19:52:30 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BEET vs. tunnel/HCoIPsec Thread-Index: AcZNZAW94bylgy1SRU2TBQFLJBhNOg== From: "Henderson, Thomas R" To: "Pekka Nikander" X-OriginalArrivalTime: 22 Mar 2006 03:52:30.0397 (UTC) FILETIME=[0B0AE6D0:01C64D64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: HIP Subject: [Hipsec] BEET vs. tunnel/HCoIPsec X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Pekka, The mobike discussion on BEET was interesting to me because I became aware of the header compression over IPsec tunnel mode work: http://www.ietf.org/internet-drafts/draft-ietf-rohc-hcoipsec-01.txt As I have understood it, HIP has always assumed BEET mode, mainly for i) efficiency reasons and ii) because SA selectors have been based on destination addresses in IPsec. Now, it seems that RFC 4303 Section 2.1 allows selectors to be based only on SPI (which seems to be a relaxation from RFC 2406). So perhaps item ii) is no longer relevant when using currently defined IPsec. So is the main remaining difference the efficiency of BEET mode vs. (HCoIPsec) tunnel mode? The possible advantages of HCoIPsec may be: - do not have to reinvent header compression approaches that neglect IP headers (it is claimed in the HC documents that most HC techniques assume that they are working jointly on transport/IP header fields). Plus, HCoIPsec should be more efficient than BEET alone. - as far as BEET's present definition (I don't know whether this can be fixed), fragmentation support may be cleaner/more secure for tunnel mode (at least that is the point that Michael Richardson seemed to make at the meeting). I think he also argued that BEET was exposing additional header information (possibly modifiable) that tunnel mode does not, although I didn't catch the details. The possible advantages of BEET over HCoIPsec might be: - BEET seems to have (mostly) worked out how to handle different IP address families in inner and outer headers, whereas I don't see that capability in IPsec tunnel mode. - I don't know whether HCoIPsec will be harder to operationally use than BEET, leading to situation where most connections will run without it in practice. Do you see some other differences?=20 Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 22 12:04:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6lD-0005qO-UE; Wed, 22 Mar 2006 12:04:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6lC-0005qJ-PK for hipsec@ietf.org; Wed, 22 Mar 2006 12:04:38 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5hX-0004fF-MN for hipsec@ietf.org; Wed, 22 Mar 2006 10:56:47 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FM5CU-0003Sf-7p for hipsec@ietf.org; Wed, 22 Mar 2006 10:24:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k2MFOa0t006297; Wed, 22 Mar 2006 16:24:36 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k2MFOYUk006287; Wed, 22 Mar 2006 16:24:34 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k2MFOXsZ026412; Wed, 22 Mar 2006 16:24:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200603221524.k2MFOXsZ026412@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Henderson, Thomas R" Subject: Re: [Hipsec] BEET vs. tunnel/HCoIPsec In-reply-to: Your message of Tue, 21 Mar 2006 19:52:30 PST. <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> Date: Wed, 22 Mar 2006 16:24:33 +0100 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: -1.3 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org In your previous mail you wrote: ii) because SA selectors have been based on destination addresses in IPsec. Now, it seems that RFC 4303 Section 2.1 allows selectors to be based only on SPI (which seems to be a relaxation from RFC 2406). So perhaps item ii) is no longer relevant when using currently defined IPsec. => your use of the term "selector" here is fully wrong. I believe you refer to the SA lookup for incomming packets: RFC 4301 proposes the SPI only for unicast SAs. The possible advantages of BEET over HCoIPsec might be: - BEET seems to have (mostly) worked out how to handle different IP address families in inner and outer headers, whereas I don't see that capability in IPsec tunnel mode. => I strongly disagree: this is in IPsec from the beginning. Regards Francis.Dupont@point6.net _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 22 12:16:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6wr-0006mU-9a; Wed, 22 Mar 2006 12:16:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6wq-0006kM-5N for hipsec@ietf.org; Wed, 22 Mar 2006 12:16:40 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6wo-0000KR-Nb for hipsec@ietf.org; Wed, 22 Mar 2006 12:16:40 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C1A95212C59; Wed, 22 Mar 2006 19:16:37 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id ACAB0212C4C; Wed, 22 Mar 2006 19:16:35 +0200 (EET) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 22 Mar 2006 11:16:33 -0600 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: HIP Subject: [Hipsec] Re: BEET vs. tunnel/HCoIPsec X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Thomas, > As I have understood it, HIP has always assumed BEET mode, mainly > for i) > efficiency reasons and ii) because SA selectors have been based on > destination addresses in IPsec. My stance here is slightly different. To me, BEET is a way to implement the id/loc split within IPsec rather than outside of it. The benefit, from this point of view, is mainly security. You gain assurance that incoming packets are indeed coming from the source HIT. Sure, you could use tunnel mode for the same purposes but then you would need to have very strict policy of accepting only the certain source HIT from that tunnel. I tried to illustrate this, perhaps foolishly, by stating this little security benefit in implementation terms. In BEET, you overwrite the addresses with the information in the SPD. With tunnelling, you verify that the inner addresses match with the information in the SPD. Same end result, the difference being that the former configuration is more secure (less space for mistakes) and makes the inner header redundant. > Do you see some other differences? I tried to state above. IMHO, we should have both. They seem to be mostly orthogonal to me. When header compression is used with BEET, header compression can be applied to the transport header only, making it slightly more efficient. Now, that all said, I could change my architect's hat to a hacker's hat, and then I would mostly agree with what you wrote. In other words, the question in my mind is mostly architectural, and if you leave the architectural beauty aside, you *can* implement HIP, in an efficient way, just with inner header compression. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 22 21:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMG39-0006TY-MO; Wed, 22 Mar 2006 21:59:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMG38-0006TT-4r for hipsec@ietf.org; Wed, 22 Mar 2006 21:59:46 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMG36-0001au-Ne for hipsec@ietf.org; Wed, 22 Mar 2006 21:59:46 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA27320; Wed, 22 Mar 2006 18:59:37 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2N2xa910193; Wed, 22 Mar 2006 20:59:36 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 18:59:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] BEET vs. tunnel/HCoIPsec Date: Wed, 22 Mar 2006 18:59:35 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EEF1@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <200603221524.k2MFOXsZ026412@givry.rennes.enst-bretagne.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] BEET vs. tunnel/HCoIPsec Thread-Index: AcZNxL5XwW007/LoRuutjyuA7QOkJQAXyAlQ From: "Henderson, Thomas R" To: "Francis Dupont" X-OriginalArrivalTime: 23 Mar 2006 02:59:35.0821 (UTC) FILETIME=[D142CBD0:01C64E25] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@point6.net]=20 > Sent: Wednesday, March 22, 2006 7:25 AM > To: Henderson, Thomas R > Cc: Pekka Nikander; HIP > Subject: Re: [Hipsec] BEET vs. tunnel/HCoIPsec=20 >=20 > In your previous mail you wrote: >=20 > ii) because SA selectors have been based on destination addresses > in IPsec. Now, it seems that RFC 4303 Section 2.1 allows selectors > to be based only on SPI (which seems to be a relaxation from RFC > 2406). So perhaps item ii) is no longer relevant when using > currently defined IPsec. > =20 > =3D> your use of the term "selector" here is fully wrong. I believe > you refer to the SA lookup for incomming packets: RFC 4301 proposes > the SPI only for unicast SAs. Yes, you are right, I meant incoming SA lookup so should not have used the term selector in that context. But my point was that RFC 4303 language on this input processing differs from RFC 2401 Section 5.2.1, where it was said that SA selection depended on the destination IP address. >=20 > The possible advantages of BEET over HCoIPsec might be: > - BEET seems to have (mostly) worked out how to handle different IP > address families in inner and outer headers, whereas I=20 > don't see that > capability in IPsec tunnel mode. >=20 > =3D> I strongly disagree: this is in IPsec from the beginning. >=20 Thanks (also to Tero) for pointing this out. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 22 22:03:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMG6v-0007fj-Am; Wed, 22 Mar 2006 22:03:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMG6t-0007fd-RO for hipsec@ietf.org; Wed, 22 Mar 2006 22:03:39 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMG6s-0001hN-KF for hipsec@ietf.org; Wed, 22 Mar 2006 22:03:39 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id VAA10294; Wed, 22 Mar 2006 21:03:36 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2N33Z912900; Wed, 22 Mar 2006 21:03:35 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 19:03:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Mar 2006 19:03:34 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EEF3@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BEET vs. tunnel/HCoIPsec Thread-Index: AcZN1N+rCK+f/zD5RNulO/Erc5+54AAUWJ0w From: "Henderson, Thomas R" To: "Pekka Nikander" X-OriginalArrivalTime: 23 Mar 2006 03:03:34.0601 (UTC) FILETIME=[5F95BB90:01C64E26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: HIP Subject: [Hipsec] RE: BEET vs. tunnel/HCoIPsec X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 > > Do you see some other differences? >=20 > I tried to state above. >=20 > IMHO, we should have both. They seem to be mostly orthogonal=20 > to me. =20 Thanks for the clarification; I also see benefit to having both. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 23 07:09:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOcW-0005fs-Le; Thu, 23 Mar 2006 07:08:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOcW-0005fn-Be for hipsec@ietf.org; Thu, 23 Mar 2006 07:08:52 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMOcS-0007JH-0p for hipsec@ietf.org; Thu, 23 Mar 2006 07:08:52 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 295E789832; Thu, 23 Mar 2006 14:08:46 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DB4078982D; Thu, 23 Mar 2006 14:08:44 +0200 (EET) Message-ID: <44228FBB.6080105@piuha.net> Date: Thu, 23 Mar 2006 06:08:27 -0600 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Hipsec] BEET vs. tunnel/HCoIPsec References: <200603221524.k2MFOXsZ026412@givry.rennes.enst-bretagne.fr> In-Reply-To: <200603221524.k2MFOXsZ026412@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Francis Dupont wrote: > The possible advantages of BEET over HCoIPsec might be: > - BEET seems to have (mostly) worked out how to handle different IP > address families in inner and outer headers, whereas I don't see that > capability in IPsec tunnel mode. > >=> I strongly disagree: this is in IPsec from the beginning. > > I agree with Francis on this. I also implemented this. (This was a long time ago -- I do not remember the details but I did not recall any specific problems in the IPsec part. I do remember that we had issues with IPsec policies matching NDP traffic, but that's a separate issue and presumably applicable for both HIP and regular IPsec.) --Jari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 23 11:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSLP-0001dM-JV; Thu, 23 Mar 2006 11:07:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSLP-0001dG-87 for hipsec@ietf.org; Thu, 23 Mar 2006 11:07:27 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSLO-0001R2-C0 for hipsec@ietf.org; Thu, 23 Mar 2006 11:07:27 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 69C20212C59; Thu, 23 Mar 2006 18:07:24 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D04ED212C4C; Thu, 23 Mar 2006 18:07:22 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <46DC6D04-2E41-4130-8609-7D766A24B0B3@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Date: Thu, 23 Mar 2006 10:07:20 -0600 To: Gonzalo Camarillo , David Ward X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.2 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: HIP Subject: [Hipsec] Raw notes from the HIP meeting X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Notes from the HIP meeting on Thursday, Mar 23 at 9am. Aplogies for =20 typos. 0900 Status and agenda bash =96 Chairs Status of the working. Architecture draft in RFC editor queue. RFC =20 4423. HIP-based and HIP-esp post WG LC. [Pekka Nikander:] Security area reviewer Charlie Kaufman, promised to =20= do Bellowin-Rescorla analysis. [Gonzalo:] Another open issue. KHI / ORCHID pending on Internet =20 area. Talk to ADs. dns, rvs, registration ready to go, waiting for the base spec mobility and multi-homing in WG LC. Base spec -04 to -05. Clarifications, open issues: Bellovin-Resrocla =20= analysis, editorial. ESP -01 to -02. Rekeying updated. Open issues Bellovin-Rescorla =20 analysis. Re-chartering issues: - NAT traversal in HIP - interface HIP to legacy and new applications draft-schmitt-hip-nat-00 [Miika:] Goal to have a implementable draft, focus on clients behind =20 a NAT. Goal to have practical that works with existing NATs. Implementation =20= work going on. Two implementations being completed. NEC Germany =20 working on one, HIIT in Finland on another one. Concenctrate on the case with a client behind a NAT, future version =20 with a server behind a NAT. Only little about firewalls. If there =20 is a firewall, there must be firewall policies in place. Extensions for both base exchange and mobility and multi-homing. =20 Perform NAT detection with a separate protocol and not include that =20 functionality in the HIP control packets. Better compatibility with =20 future NAT boxes taht can be controlled by end-hosts (behave?) =20 Drawback is extra latency caused by extra roundtrips. Both HIP control and ESP packets carried in UDP. HIP control packet =20 format. No need to have a checksum in the HIP header since that is =20 in the UDP header; therefore a zero HIP checksum. Separate keep-=20 alive format, uses UPDATE packets, see the draft. ESP encapsulation compatible with RFC3948. Both data format and keep-=20= alive. Base exchange through a NAT. I1 punches a hole into the NAT, the =20 rest of the HIP traffic flow over that. However, it is possible that =20= I2 source port is different from I1 source port. Port numbers, separate ports for control and data. [Andrew:] Did you check with the IANA? [Answer:] No, but we checked =20 they are unallocated. Mobility. Four use cases: 1. Host moves from behind a NAT into a public network 2. Host moves behind the same NAT 3. Host moves from behind one NAT into another NATted network 4. Host mvoes from a public network to a NATted network Hosts must detect if there is a NAT and start using UDP encapsulation =20= if needed. Note that port numbers can be forged or there can be =20 reflection or replay attacks. Multihoming. Not much in the draft; more complicated. For example =20 one interface may be behind a NAT andother in a public network. =20 Could be asymmetric routes. SPI number used to distinquish between =20 routes??? [Erik Nordmark:] Multiple host itself interfaces vs. the destination =20 has multiple addresses. Effectively creating two mappins in your NAT. [Miika:] Firewall configuration. Firewall policies if want to allow =20 traffic through. Can use UDP connection tracking. Open issues: Issue 1. Share the control/data UDP port numbers with IKE (RFC 3947 / =20= 3948) [Pekka Nikander:] [Andrew McGregor:] Have both for the time being. Would be helpful. =20= Explain both scenarios. Two methods have different configurations in =20= the firewall. [Lars Eggert:] Not sure OK to re-use the existing UDP port. [Andrew:] Existing implementations are going to be OK. [Mark:] What is current IANA policy for those 256 preserved SPIs. =20 Good indication w.r.t how much damage this could do. [Mark:] Keepalives? [Answer:] Yes [Answer:] IANA policy. Requires publication of another RFC. [Mark:] Also a survey of implementations needed. Issue 3: Server behind the NAT. Not defined yet. Try to avoid triangular routing by UDP hole =20 punching, works only with p2p friendly NATs. Fallback triangular =20 routing with TURN. [Gonzalo:] Go to check TURN details in behave working group if =20 reflection is allowed. Design alternatives: ICE, subset of ICE [Gonzalo:] ICE is offer/answer oriented. I think you cannot directly =20= reuse ICE. Need to check if TURN is really an option. Open editorial issues. =20 Separate draft or not? WG or RG work? In any case, should work out =20 how client and server behind a NAT are compatible. [Andrew:] Without a third party both client and server behind a NAT =20 not possible. Depends on the behaviour of the particular NAT. [Lars:] Julien Laganier states in jabber that two drafts would be =20 overhead. [Gonzalo:] Server reachability behind a NAT is a quite a general problem Issue 4: Breaks the ucrrent simple rendezvous server Current rendezvous is relaying only I1. R1 will confuse some NATs, =20 causing R1 to be dropped. Allow rvs to relay R1's, too, when =20 encapsulated in UDP. [Andrew:] Which works but it is posisble that soma NATs will not =20 drop R1. Perhaps needs a few bits of information to figure out the =20 two cases. Issue 5: LOCATOR. What kind of addresses in the LOCATOR parameter. =20 Strawman proposal: even send the private address. Doesn't require =20 any changes in the mobility implemntation. Privacy problems. Detect =20= the public address and send those. No privacy problems, but not sure =20= of the benefit. Alternative three. Filter out private addresses and =20= punch a hole in the NAT. [Andrew:] Rely on mobility implementation to use the addresses from =20 the outer header. [Answer:] Yes [Andrews:] Experiment. You can't =20 use private addresses for anything. No use in sending them. [Erik:] You don't always know if you have a private address or not. =20 Question: How to filter out private addresses. How about a host =20 that is also behind the same NAT. Issue 6: Inner addresses as IPv4 / LSI Issue 7: Editorial notes Generalise the text and reduce the number of details. Issue 8: ESP data channel reactivation upon handovers Server does not know to which SA the keepalive is related to. Port =20 numbers for the ESP data channels. [Pekka:] Consequences of usign the same port number. Issue 9: Hairpin translation Both hosts behind the same NAT, detect the NAT but don't know that's =20 the same NAT. Solution: First try to send packets with UDP =20 encapsulation. [Pekka:] Reasons why you always want first to send control packets =20 without UDP encapsulation. --------------------- Rechartering [Gonzalo:] Proposal for two new WG items. Scope these in a way that =20 are acceptable. Drafts relevant to NAts (see slide). Different scope of different =20 drafts. WG charter to allow wide scale experimentation of HIP. =20 Scope of the WG not to be extended. Only concrete things that allow =20 experimentation and not go to research work. Documents relevant to legacy applications. Not to develop an API but =20= analyse how to use existing APIs when you have HIP below. =20 Recommendations to implemntors. Open mikes: [Andrei:] Native API draft? [G:] We don't work on APIs in that =20 sense. At least not in its original form. [Andrew:] Native API document should be but through as information =20 in research group or individual. Not right for the HIP WG. UDP =20 document we just talked about should be a WG document. Enough time =20 to get some actual implementation expence. Find out which techniques =20= work and what are consequences. May even have consquences on =20 encapsulation. Will take a little while. [David:] Lays out the issues. Your uggestion? [Andrew:] The UDP document is nearly there but we want to have some =20 implementation experience. Feed the results first to the UDP draft =20 before publishing it [D] Want to avoid open ended draft that would need a long wait. [G] Have alook at the behave WG documents [Mark Townsley] On API draft, it is not so true that the IETF does =20 not do APIs. [D] We've been here for quite long time. Legacy app doc enough. [Mark] Find out if you need it or not. [Geoff huston:] If you need an API, do it. If API is necessary, if =20 there is information taht oculd be transmitted up or down to make =20 apps to work _well_ with HIP, do it. [Yu] Support considering the API. In BTNS we are in the problem of =20 rethinking the APIs. If we just do an interface it is hard for =20 actual protocols to use it. Hoping that HIP doesn't make the same =20 mistake than IPsec Comment in jabber: IETF does API but not for interoperation. [D] Consensus call. API document will be taken to the WG, to be =20 verified on the list. [Miika] Additional working items? BOS packet, re-activate the work =20 on BOS. Makes interoperability testing easier. HIP bootstrap stuff =20 is very easy. Another issue, maybe for research group. M&M defines =20 the basic stuff, but should consider more advanced stuff. [Pekka:] Multi-homing and mobility. Should include everything needed =20= for more advanced stuff without really specifying how to do it. [Lars:] Question on HIP NAT. [G] Consensus on the first two items, decided to add the native API too. [Miika:] SHIM6 [Pekka:] Dave Thaler in SHIM6 askign for a document on HIP/SHIM6/MIP [Erik:] SHIM6 people working with SHIM6 and Mobile IP; don't know =20 what people will say about HIP. Clarification on the packet formats. [Geoff Huston:] SHIM6 proto document in WG LC. Interactions with =20 Mobile IPv6 and only that, only compatibility issues. Don't foresee =20 any issues. SHIM6 will not in its charter have anything to do with =20 HIP. In terms of compatability there is nothing in the charter, may =20 more grativate to HIP WG than SHIM6 WG. [Andrew:] Upgrate IPv6 to SHIM6 and then SHIM6 upgrade to HIP. =20 Research item. Would require rechartering. [D] If the IETF community would decide to turn SHIM6 to HIP, then we =20= could do it, but that is far in the future. [Geoff] IETF thought police. SHIM6 locator agility, not mobility. [D] Good discussion. Done here. See you in montreal. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 23 12:31:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTeg-0000Om-C9; Thu, 23 Mar 2006 12:31:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTee-0000LT-MW for hipsec@ietf.org; Thu, 23 Mar 2006 12:31:24 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTYt-0004n0-3y for hipsec@ietf.org; Thu, 23 Mar 2006 12:25:29 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k2NHPMBC023014; Thu, 23 Mar 2006 18:25:22 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k2NHPLLk025080; Thu, 23 Mar 2006 18:25:21 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 18:25:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Hipsec] Raw notes from the HIP meeting Date: Thu, 23 Mar 2006 18:25:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Raw notes from the HIP meeting Thread-Index: AcZOlL0+SwiIkAksQCekeZZd7TModgACe+ow From: "Tschofenig, Hannes" To: "Pekka Nikander" , "Gonzalo Camarillo" , "David Ward" X-OriginalArrivalTime: 23 Mar 2006 17:25:21.0037 (UTC) FILETIME=[C305BBD0:01C64E9E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Most of the slides are not on the webpage.=20 Could you please upload them now.=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Gesendet: Donnerstag, 23. M=E4rz 2006 10:07 > An: Gonzalo Camarillo; David Ward > Cc: HIP > Betreff: [Hipsec] Raw notes from the HIP meeting >=20 > Notes from the HIP meeting on Thursday, Mar 23 at 9am. Aplogies for =20 > typos. >=20 > 0900 Status and agenda bash - Chairs >=20 > Status of the working. Architecture draft in RFC editor queue. RFC =20 > 4423. HIP-based and HIP-esp post WG LC. >=20 > [Pekka Nikander:] Security area reviewer Charlie Kaufman,=20 > promised to =20 > do Bellowin-Rescorla analysis. >=20 > [Gonzalo:] Another open issue. KHI / ORCHID pending on Internet =20 > area. Talk to ADs. >=20 > dns, rvs, registration ready to go, waiting for the base spec >=20 > mobility and multi-homing in WG LC. >=20 > Base spec -04 to -05. Clarifications, open issues:=20 > Bellovin-Resrocla =20 > analysis, editorial. >=20 > ESP -01 to -02. Rekeying updated. Open issues Bellovin-Rescorla =20 > analysis. >=20 > Re-chartering issues: > - NAT traversal in HIP > - interface HIP to legacy and new applications >=20 > draft-schmitt-hip-nat-00 >=20 > [Miika:] Goal to have a implementable draft, focus on clients behind =20 > a NAT. >=20 > Goal to have practical that works with existing NATs. =20 > Implementation =20 > work going on. Two implementations being completed. NEC Germany =20 > working on one, HIIT in Finland on another one. >=20 > Concenctrate on the case with a client behind a NAT, future version =20 > with a server behind a NAT. Only little about firewalls. If there =20 > is a firewall, there must be firewall policies in place. >=20 > Extensions for both base exchange and mobility and multi-homing. =20 > Perform NAT detection with a separate protocol and not include that =20 > functionality in the HIP control packets. Better compatibility with =20 > future NAT boxes taht can be controlled by end-hosts (behave?) =20 > Drawback is extra latency caused by extra roundtrips. >=20 > Both HIP control and ESP packets carried in UDP. HIP control packet =20 > format. No need to have a checksum in the HIP header since that is =20 > in the UDP header; therefore a zero HIP checksum. Separate keep-=20 > alive format, uses UPDATE packets, see the draft. >=20 > ESP encapsulation compatible with RFC3948. Both data format=20 > and keep-=20 > alive. >=20 > Base exchange through a NAT. I1 punches a hole into the NAT, the =20 > rest of the HIP traffic flow over that. However, it is=20 > possible that =20 > I2 source port is different from I1 source port. >=20 > Port numbers, separate ports for control and data. >=20 > [Andrew:] Did you check with the IANA? [Answer:] No, but we checked =20 > they are unallocated. >=20 > Mobility. Four use cases: > 1. Host moves from behind a NAT into a public network > 2. Host moves behind the same NAT > 3. Host moves from behind one NAT into another NATted network > 4. Host mvoes from a public network to a NATted network >=20 > Hosts must detect if there is a NAT and start using UDP=20 > encapsulation =20 > if needed. Note that port numbers can be forged or there can be =20 > reflection or replay attacks. >=20 > Multihoming. Not much in the draft; more complicated. For example =20 > one interface may be behind a NAT andother in a public network. =20 > Could be asymmetric routes. SPI number used to distinquish between =20 > routes??? >=20 > [Erik Nordmark:] Multiple host itself interfaces vs. the destination =20 > has multiple addresses. Effectively creating two mappins in your NAT. >=20 > [Miika:] Firewall configuration. Firewall policies if want to allow =20 > traffic through. Can use UDP connection tracking. >=20 > Open issues: >=20 > Issue 1. Share the control/data UDP port numbers with IKE=20 > (RFC 3947 / =20 > 3948) >=20 > [Pekka Nikander:] >=20 > [Andrew McGregor:] Have both for the time being. Would be=20 > helpful. =20 > Explain both scenarios. Two methods have different=20 > configurations in =20 > the firewall. >=20 > [Lars Eggert:] Not sure OK to re-use the existing UDP port. >=20 > [Andrew:] Existing implementations are going to be OK. >=20 > [Mark:] What is current IANA policy for those 256 preserved SPIs. =20 > Good indication w.r.t how much damage this could do. >=20 > [Mark:] Keepalives? [Answer:] Yes >=20 > [Answer:] IANA policy. Requires publication of another RFC. >=20 > [Mark:] Also a survey of implementations needed. >=20 > Issue 3: Server behind the NAT. >=20 > Not defined yet. Try to avoid triangular routing by UDP hole =20 > punching, works only with p2p friendly NATs. Fallback triangular =20 > routing with TURN. >=20 > [Gonzalo:] Go to check TURN details in behave working group if =20 > reflection is allowed. >=20 > Design alternatives: ICE, subset of ICE >=20 > [Gonzalo:] ICE is offer/answer oriented. I think you cannot=20 > directly =20 > reuse ICE. >=20 > Need to check if TURN is really an option. Open editorial issues. =20 > Separate draft or not? WG or RG work? In any case, should work out =20 > how client and server behind a NAT are compatible. >=20 > [Andrew:] Without a third party both client and server behind a NAT =20 > not possible. Depends on the behaviour of the particular NAT. >=20 > [Lars:] Julien Laganier states in jabber that two drafts would be =20 > overhead. >=20 > [Gonzalo:] Server reachability behind a NAT is a quite a=20 > general problem >=20 > Issue 4: Breaks the ucrrent simple rendezvous server >=20 > Current rendezvous is relaying only I1. R1 will confuse some NATs, =20 > causing R1 to be dropped. Allow rvs to relay R1's, too, when =20 > encapsulated in UDP. >=20 > [Andrew:] Which works but it is posisble that soma NATs will not =20 > drop R1. Perhaps needs a few bits of information to figure out the =20 > two cases. >=20 > Issue 5: LOCATOR. What kind of addresses in the LOCATOR parameter. =20 > Strawman proposal: even send the private address. Doesn't require =20 > any changes in the mobility implemntation. Privacy problems.=20 > Detect =20 > the public address and send those. No privacy problems, but=20 > not sure =20 > of the benefit. Alternative three. Filter out private=20 > addresses and =20 > punch a hole in the NAT. >=20 > [Andrew:] Rely on mobility implementation to use the addresses from =20 > the outer header. [Answer:] Yes [Andrews:] Experiment. You can't =20 > use private addresses for anything. No use in sending them. >=20 > [Erik:] You don't always know if you have a private address or not. =20 > Question: How to filter out private addresses. How about a host =20 > that is also behind the same NAT. >=20 > Issue 6: Inner addresses as IPv4 / LSI >=20 > Issue 7: Editorial notes >=20 > Generalise the text and reduce the number of details. >=20 > Issue 8: ESP data channel reactivation upon handovers >=20 > Server does not know to which SA the keepalive is related to. Port =20 > numbers for the ESP data channels. >=20 > [Pekka:] Consequences of usign the same port number. >=20 > Issue 9: Hairpin translation >=20 > Both hosts behind the same NAT, detect the NAT but don't know that's =20 > the same NAT. Solution: First try to send packets with UDP =20 > encapsulation. >=20 > [Pekka:] Reasons why you always want first to send control packets =20 > without UDP encapsulation. >=20 > --------------------- >=20 > Rechartering >=20 > [Gonzalo:] Proposal for two new WG items. Scope these in a way that =20 > are acceptable. >=20 > Drafts relevant to NAts (see slide). Different scope of different =20 > drafts. WG charter to allow wide scale experimentation of HIP. =20 > Scope of the WG not to be extended. Only concrete things that allow =20 > experimentation and not go to research work. >=20 > Documents relevant to legacy applications. Not to develop an=20 > API but =20 > analyse how to use existing APIs when you have HIP below. =20 > Recommendations to implemntors. >=20 > Open mikes: >=20 > [Andrei:] Native API draft? [G:] We don't work on APIs in that =20 > sense. At least not in its original form. >=20 > [Andrew:] Native API document should be but through as information =20 > in research group or individual. Not right for the HIP WG. UDP =20 > document we just talked about should be a WG document. Enough time =20 > to get some actual implementation expence. Find out which=20 > techniques =20 > work and what are consequences. May even have consquences on =20 > encapsulation. Will take a little while. >=20 > [David:] Lays out the issues. Your uggestion? >=20 > [Andrew:] The UDP document is nearly there but we want to have some =20 > implementation experience. Feed the results first to the UDP draft =20 > before publishing it >=20 > [D] Want to avoid open ended draft that would need a long wait. >=20 > [G] Have alook at the behave WG documents >=20 > [Mark Townsley] On API draft, it is not so true that the IETF does =20 > not do APIs. >=20 > [D] We've been here for quite long time. Legacy app doc enough. >=20 > [Mark] Find out if you need it or not. >=20 > [Geoff huston:] If you need an API, do it. If API is necessary, if =20 > there is information taht oculd be transmitted up or down to make =20 > apps to work _well_ with HIP, do it. >=20 > [Yu] Support considering the API. In BTNS we are in the problem of =20 > rethinking the APIs. If we just do an interface it is hard for =20 > actual protocols to use it. Hoping that HIP doesn't make the same =20 > mistake than IPsec >=20 > Comment in jabber: IETF does API but not for interoperation. >=20 > [D] Consensus call. API document will be taken to the WG, to be =20 > verified on the list. >=20 > [Miika] Additional working items? BOS packet, re-activate the work =20 > on BOS. Makes interoperability testing easier. HIP bootstrap stuff =20 > is very easy. Another issue, maybe for research group. M&M defines =20 > the basic stuff, but should consider more advanced stuff. >=20 > [Pekka:] Multi-homing and mobility. Should include=20 > everything needed =20 > for more advanced stuff without really specifying how to do it. >=20 > [Lars:] Question on HIP NAT. >=20 > [G] Consensus on the first two items, decided to add the=20 > native API too. >=20 > [Miika:] SHIM6 >=20 > [Pekka:] Dave Thaler in SHIM6 askign for a document on HIP/SHIM6/MIP >=20 > [Erik:] SHIM6 people working with SHIM6 and Mobile IP; don't know =20 > what people will say about HIP. > Clarification on the packet formats. >=20 > [Geoff Huston:] SHIM6 proto document in WG LC. Interactions with =20 > Mobile IPv6 and only that, only compatibility issues. Don't foresee =20 > any issues. SHIM6 will not in its charter have anything to do with =20 > HIP. In terms of compatability there is nothing in the charter, may =20 > more grativate to HIP WG than SHIM6 WG. >=20 > [Andrew:] Upgrate IPv6 to SHIM6 and then SHIM6 upgrade to HIP. =20 > Research item. Would require rechartering. >=20 > [D] If the IETF community would decide to turn SHIM6 to HIP,=20 > then we =20 > could do it, but that is far in the future. >=20 > [Geoff] IETF thought police. SHIM6 locator agility, not mobility. >=20 > [D] Good discussion. Done here. See you in montreal. >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Mar 27 02:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNm16-0005pu-1F; Mon, 27 Mar 2006 02:19:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNm14-0005mK-Rt for hipsec@lists.ietf.org; Mon, 27 Mar 2006 02:19:54 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNm0y-0006ip-Ex for hipsec@lists.ietf.org; Mon, 27 Mar 2006 02:19:51 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 905382ECC; Mon, 27 Mar 2006 10:19:47 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20040914 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id D7F8D2E40 for ; Mon, 27 Mar 2006 10:19:44 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k2R7Jii12379; Mon, 27 Mar 2006 10:19:44 +0300 (EEST) Date: Mon, 27 Mar 2006 10:19:44 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@lists.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Hipsec] IETF65 interoperability summary X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Jeff, Jan, Kristian and me did some interopping every now and then during the past two weeks. The following features were successfully interoperated both on IPv4 and IPv6: * Base exchange * CLOSE * Rekeying without new DH The following features still need to interoperated: * Mobility and multihoming extensions * Rekeying with DH The interops were based on base-05, esp-02, mm-03 and khi-00. We did not find any errors from the drafts, and all of the problems were just implementation problems. Most of the problems were related to handling of the ESP_INFO and new KHI. Since I am writing this email, I'll also add a small advertisement here :) InfraHIP HIPL implementation was interoperated first time in full userspace mode, based on our on-going efforts on Linux kernel 2.6.x BEET IPsec mode: http://infrahip.hiit.fi/beet/simple-beet-patch-v1.0-2.6.13.1 http://infrahip.hiit.fi/beet/interfamily-beet-patch-v1.0-2.6.13.1 The beet directory also contains patches for later kernels (with BEET pseudoheader implemented). Special thanks for Diego Beltrami and Herbert Xu for their dedication on the patches. We are working on to polish and finalize the patches to get them accepted in the vanilla kernel. The implementations are available for download from the following URLs: http://infrahip.hiit.fi/hipl/ http://www.openhip.org/ http://www.hip4inter.net/ -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 30 01:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqzG-0006vW-2C; Thu, 30 Mar 2006 01:50:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqyv-0006F1-3d for hipsec@ietf.org; Thu, 30 Mar 2006 01:50:09 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOqpj-0001lY-AZ for hipsec@ietf.org; Thu, 30 Mar 2006 01:40:44 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 65C4A4F0001; Thu, 30 Mar 2006 08:40:38 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 08:40:37 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 08:40:37 +0200 Received: from [131.160.126.99] (rvi2-126-99.lmf.ericsson.se [131.160.126.99]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 707632441; Thu, 30 Mar 2006 09:40:37 +0300 (EEST) Message-ID: <442B7D64.1090609@ericsson.com> Date: Thu, 30 Mar 2006 09:40:36 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2006 06:40:37.0638 (UTC) FILETIME=[DACFBA60:01C653C4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Hipsec] Draft minutes X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, here you have the draft minutes from our meeting in Dallas: http://hip.piuha.net/meetings/ietf65/notes/minutes-hip-ietf65.txt Comments are welcome. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec