From hipsec-bounces@lists.ietf.org Tue Nov 01 05:53:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWtlW-0000nh-ME; Tue, 01 Nov 2005 05:53:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWtho-00069l-Ec for hipsec@megatron.ietf.org; Tue, 01 Nov 2005 05:49:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01945 for ; Tue, 1 Nov 2005 05:49:07 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWtwB-0007sF-6K for hipsec@ietf.org; Tue, 01 Nov 2005 06:04:19 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C9750212C86; Tue, 1 Nov 2005 12:49:18 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 1 Nov 2005 11:49:16 +0100 To: "Papadoglou, Nick, VF-Group" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: hipsec-rg@honor.trusecure.com, hipsec@ietf.org Subject: [Hipsec] Re: [Hipsec-rg] I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This looks like an interesting approach to me; I'd encourage people to read. --Pekka On Oct 30, 2005, at 19:09, Papadoglou, Nick, VF-Group wrote: > Dear all, > > Please find below a new ID that we submitted and we intent to > present/discuss in the Vancouver meeting. Your comments/suggestions > and > constructive comments are more than welcome. > > Best regards, > > Nick > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, October 18, 2005 12:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Host Identity Tags (HIT) in Presence > Information Data Format (PIDF) > Author(s) : N. Papadoglou, H. Zisimopoulos > Filename : draft-papadoglou-hiprg-hit-presence-00.txt > Pages : 11 > Date : 2005-10-18 > > This document describes a new way of exchanging Host Identities (or > Host Identity Tags) by means of the Presence Information Data > Format > [6] using the Host Identity Protocol (HIP). A new presence > information element is proposed as an extension to the Presence > Information Data Format (PIDF), to include and convey the Host > Identity that corresponds to the different SIP URI's the node may > have registered. This automatically creates a list of associations > between the SIP URI and the Host identity for the different UA > instances on the same or different node. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-papadoglou-hiprg-hit- > presence- > 00.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-papadoglou-hiprg-hit-presence-00.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-papadoglou-hiprg-hit-presence-00.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 Tue Nov 01 05:53:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWtlb-0000qb-3g; Tue, 01 Nov 2005 05:53:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWtlD-0000ax-KP for hipsec@megatron.ietf.org; Tue, 01 Nov 2005 05:52:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02683 for ; Tue, 1 Nov 2005 05:52:38 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWtzY-00082i-QW for hipsec@ietf.org; Tue, 01 Nov 2005 06:07:50 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 186BF212C86; Tue, 1 Nov 2005 12:52:48 +0200 (EET) In-Reply-To: <43635752.8090204@ericsson.com> References: <43635752.8090204@ericsson.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 1 Nov 2005 11:52:45 +0100 To: HIP X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: David Ward Subject: [Hipsec] Rechartering items? 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Now that we have time for starting HIP WG re-chartering discussion at our agenda next week, I'd like to hear people's ideas of what should be the next items. As far as I can see, it may take a while before mobility and multi-homing stabilises, so that might need to continue. But other than that? Some things that I would consider important: - making HIP to work with legacy NATs (and firewalls when feasible) - invisible HIP, or using HIP with IP addresses as LSIs, similar to SHIM6 ULIDs What else would be both important and mature enough for WG side work? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Nov 01 06:57:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWule-0000Nq-HX; Tue, 01 Nov 2005 06:57:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWulc-0000NK-8V for hipsec@megatron.ietf.org; Tue, 01 Nov 2005 06:57:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14616 for ; Tue, 1 Nov 2005 06:57:07 -0500 (EST) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWuzz-0007GW-Hi for hipsec@ietf.org; Tue, 01 Nov 2005 07:12:20 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A7A032D96; Tue, 1 Nov 2005 13:57:15 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.0-niksula20040914 (2005-09-13) on twilight.cs.hut.fi 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 452042D90; Tue, 1 Nov 2005 13:57:15 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id jA1BvD304679; Tue, 1 Nov 2005 13:57:13 +0200 (EET) Date: Tue, 1 Nov 2005 13:57:13 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] Rechartering items? In-Reply-To: Message-ID: References: <43635752.8090204@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: HIP , David Ward 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Tue, 1 Nov 2005, Pekka Nikander wrote: > Some things that I would consider important: > > - making HIP to work with legacy NATs (and firewalls when feasible) > > - invisible HIP, or using HIP with IP addresses as LSIs, similar to > SHIM6 ULIDs > > What else would be both important and mature enough for WG side work? What do you feel about the native HIP API work? I think the opportunistic HIP draft would be nice to have on WG side, as the next version of the draft is going to be even simpler than the earlier. -- 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 Tue Nov 01 07:29:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWvGa-000061-7u; Tue, 01 Nov 2005 07:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWvGW-0008V9-ED for hipsec@megatron.ietf.org; Tue, 01 Nov 2005 07:29:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16480 for ; Tue, 1 Nov 2005 07:29:02 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWvUt-0000uH-4a for hipsec@ietf.org; Tue, 01 Nov 2005 07:44:16 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 152E2212C86; Tue, 1 Nov 2005 14:29:03 +0200 (EET) In-Reply-To: References: <43635752.8090204@ericsson.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <075C8233-246B-4A31-A8D9-F0854826CD25@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Rechartering items? Date: Tue, 1 Nov 2005 13:29:00 +0100 To: Miika Komu X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: HIP , David Ward 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> What else would be both important and mature enough for WG side work? > > What do you feel about the native HIP API work? Personally, I don't think that is mature enough, and I am not even sure if we want to run it through a working group at all. But at least we need a much more implementation and *use* experience. > I think the opportunistic HIP draft would be nice to have on WG > side, as > the next version of the draft is going to be even simpler than the > earlier. I think it may be mature enough once someone implements it; the question (at least for me) is whether people feel it is interesting enough. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Nov 01 08:22:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWvvJ-0001PT-QJ; Tue, 01 Nov 2005 08:11:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWvvG-0001Nx-Vb for hipsec@megatron.ietf.org; Tue, 01 Nov 2005 08:11:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18735 for ; Tue, 1 Nov 2005 08:11:11 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWw9d-0002ra-Tw for hipsec@ietf.org; Tue, 01 Nov 2005 08:26:23 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id jA1DB8Fv007753; Tue, 1 Nov 2005 14:11:08 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id jA1DB8vj006058; Tue, 1 Nov 2005 14:11:08 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Nov 2005 14:11:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Nov 2005 14:11:06 +0100 Message-ID: Thread-Topic: [Hipsec-rg] I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt Thread-Index: AcXe0g07/mgibXpBTpCgup8zsfDuywAABMyA From: "Tschofenig, Hannes" To: "Pekka Nikander" , "Papadoglou, Nick, VF-Group" X-OriginalArrivalTime: 01 Nov 2005 13:11:07.0870 (UTC) FILETIME=[B8C4A7E0:01C5DEE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: hipsec-rg@honor.trusecure.com, hipsec@ietf.org Subject: [Hipsec] AW: [Hipsec-rg] I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org hi pekka,=20 interesting that you mention this. we have an ietf draft about hip and sip interaction (see = draft-tschofenig-hiprg-host-identities-02.txt) hanging around for some = time. the approach outlined in = draft-papadoglou-hiprg-hit-presence-00.txt illustrates the first item of = our open issue list.=20 ciao hannes=20 -----Urspr=FCngliche Nachricht----- Von: hipsec-rg-admin@honor.trusecure.com = [mailto:hipsec-rg-admin@honor.trusecure.com] Im Auftrag von Pekka = Nikander Gesendet: Dienstag, 1. November 2005 11:49 An: Papadoglou, Nick, VF-Group Cc: hipsec-rg@honor.trusecure.com; hipsec@ietf.org Betreff: Re: [Hipsec-rg] I-D = ACTION:draft-papadoglou-hiprg-hit-presence-00.txt This looks like an interesting approach to me; I'd encourage people =20 to read. --Pekka On Oct 30, 2005, at 19:09, Papadoglou, Nick, VF-Group wrote: > Dear all, > > Please find below a new ID that we submitted and we intent to > present/discuss in the Vancouver meeting. Your comments/suggestions =20 > and > constructive comments are more than welcome. > > Best regards, > > Nick > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, October 18, 2005 12:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Host Identity Tags (HIT) in Presence > Information Data Format (PIDF) > Author(s) : N. Papadoglou, H. Zisimopoulos > Filename : draft-papadoglou-hiprg-hit-presence-00.txt > Pages : 11 > Date : 2005-10-18 > > This document describes a new way of exchanging Host Identities (or > Host Identity Tags) by means of the Presence Information Data =20 > Format > [6] using the Host Identity Protocol (HIP). A new presence > information element is proposed as an extension to the Presence > Information Data Format (PIDF), to include and convey the Host > Identity that corresponds to the different SIP URI's the node may > have registered. This automatically creates a list of associations > between the SIP URI and the Host identity for the different UA > instances on the same or different node. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-papadoglou-hiprg-hit-=20 > presence- > 00.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-papadoglou-hiprg-hit-presence-00.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-papadoglou-hiprg-hit-presence-00.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-rg mailing list Hipsec-rg@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec-rg _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Nov 01 12:52:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX0JO-0006NE-DF; Tue, 01 Nov 2005 12:52:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX0JJ-0006Fs-DN for hipsec@megatron.ietf.org; Tue, 01 Nov 2005 12:52:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04824 for ; Tue, 1 Nov 2005 12:52:16 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX0Xh-0002EZ-Ol for hipsec@ietf.org; Tue, 01 Nov 2005 13:07:32 -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 LAA03353; Tue, 1 Nov 2005 11:51:49 -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 jA1HpnY19483; Tue, 1 Nov 2005 11:51:49 -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); Tue, 1 Nov 2005 09:51:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Rechartering items? Date: Tue, 1 Nov 2005 09:51:44 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E5B7@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Rechartering items? Thread-Index: AcXe2LGyf5u5V57nTIGAeoOIr9PC5gAMOD4Q From: "Henderson, Thomas R" To: "Pekka Nikander" , "HIP" X-OriginalArrivalTime: 01 Nov 2005 17:51:45.0588 (UTC) FILETIME=[ECD48740:01C5DF0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: David Ward 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, November 01, 2005 2:53 AM > To: HIP > Cc: David Ward > Subject: [Hipsec] Rechartering items? >=20 > Now that we have time for starting HIP WG re-chartering=20 > discussion at our agenda next week, I'd like to hear people's=20 > ideas of what should be the next items. As far as I can see,=20 > it may take a while before mobility and multi-homing=20 > stabilises, so that might need to continue. But other than that? >=20 > Some things that I would consider important: >=20 > - making HIP to work with legacy NATs (and firewalls when feasible) This topic has seen significant interest from the RG side, and in fact there has been discussion in the RG that this topic might be a candidate to push into the WG if there were charter interest there. The RG decided to make the following draft into a RG document-- it is a problem statement discussing the problem of traversing legacy NATs and firewalls: http://www.ietf.org/internet-drafts/draft-irtf-hiprg-nat-00.txt An implementation draft was worked on about a year ago, but it has since expired. I do not know of any implementation, although I have heard that InfraHIP is working on it. https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D= 129 56 The RG is also considering solutions involving HIP-aware firewalls and NATs, but IMO that type of work (as well as native HIP API) is not ready for a WG. >=20 > - invisible HIP, or using HIP with IP addresses as LSIs, similar to > SHIM6 ULIDs >=20 A draft that discusses this topic is at: http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-01. txt It has not generated any mailing list or meeting discussion. I was thinking of submitting it to RFC Editor as an individual submission. This topic is not one that necessarily involves interoperability, so I would like to understand better what is left to do (as a possible WG item) beyond the present draft. > What else would be both important and mature enough for WG side work? >=20 The integration of SIP and HIP has received a lot of attention in the RG, but I don't know whether there are any implementations: i) http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-hip-srtp-01.t xt ii) http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-host-identiti es-02.txt iii) http://www.ietf.org/internet-drafts/draft-papadoglou-hiprg-hit-presence- 00.txt Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Nov 02 11:09:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLBC-0003KF-P5; Wed, 02 Nov 2005 11:09:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLBA-0003K0-S8 for hipsec@megatron.ietf.org; Wed, 02 Nov 2005 11:09:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15503 for ; Wed, 2 Nov 2005 11:09:15 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLPk-0000CI-3U for hipsec@ietf.org; Wed, 02 Nov 2005 11:24:43 -0500 Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jA2G9VdK023293; Wed, 2 Nov 2005 08:09:31 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jA2G8kbV253824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Nov 2005 08:09:17 -0800 (PST) Message-ID: <4368E482.9020907@sun.com> Date: Wed, 02 Nov 2005 08:08:34 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Rechartering items? References: <43635752.8090204@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: HIP , David Ward 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Pekka Nikander wrote: > - invisible HIP, or using HIP with IP addresses as LSIs, similar to > SHIM6 ULIDs Aren't LSIs and SHIM6 ULIDs quite different with different implications? The former is 32 bits, which makes it unlikely that it will be a globally unique number, and the latter are regular 128-bit IPv6 addresses. So while both might result in "invisible HIP" it might make sense to discuss them separately. Erik _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Nov 02 11:09:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLBN-0003LD-41; Wed, 02 Nov 2005 11:09:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLBL-0003L2-HY for hipsec@megatron.ietf.org; Wed, 02 Nov 2005 11:09:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15506 for ; Wed, 2 Nov 2005 11:09:26 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLPw-0000Be-TC for hipsec@ietf.org; Wed, 02 Nov 2005 11:24:54 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CAB51212C55; Wed, 2 Nov 2005 18:09:21 +0200 (EET) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E5B7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6DC9E5B7@XCH-NW-5V1.nw.nos.boeing.com> 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: [Hipsec] Rechartering items? Date: Wed, 2 Nov 2005 11:33:50 +0100 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.7 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: HIP , David Ward 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Tom, > The RG is also considering solutions involving HIP-aware firewalls > and NATs, but IMO that type of work (as well as native HIP API) is > not ready for a WG. I agree. >> - invisible HIP, or using HIP with IP addresses as LSIs, similar >> to SHIM6 ULIDs >> > A draft that discusses this topic is at: http://www.ietf.org/ > internet-drafts/draft-henderson-hip-applications-01.txt > > It has not generated any mailing list or meeting discussion. I was > thinking of submitting it to RFC Editor as an individual > submission. This topic is not one that necessarily involves > interoperability, so I would like to understand better what is left > to do (as a possible WG item) beyond the present draft. There are severe interoperability issues with upper layer protocols. Depending on what you use at the API as LSI, those upper layer protocols that send LSIs in their datagrams to third hosts will either fail or work. One could consider this also as an architectural issues, as it circles around the semantics of LSIs/ ULIDs, specifically whether they are routable or not. The existing draft is pretty good in outlining the issues, and fine as long as we want to use HIP only as experimental. However, if we would like to advance HIP to standards track, then we need to have *one* RECOMMENDED way for LSIs... The other way would remain experimental, between consenting hosts, IMHO. At the protocol level there may be desire to negotiate this. I.e. an extension that defines in I2 which LSI format is used by the peer.... That could be informational, as any two-hosts protocols can function even if the communicating hosts use different LSI formats. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Nov 02 11:28:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLTC-0000mo-2S; Wed, 02 Nov 2005 11:28:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLTA-0000mg-52 for hipsec@megatron.ietf.org; Wed, 02 Nov 2005 11:28:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17454 for ; Wed, 2 Nov 2005 11:27:50 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLhb-0001OK-Bj for hipsec@ietf.org; Wed, 02 Nov 2005 11:43:18 -0500 Received: from [192.168.1.105] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42DE178C03D4E288; Wed, 2 Nov 2005 17:27:19 +0100 From: Julien Laganier To: Erik Nordmark Subject: Re: [Hipsec] Rechartering items? Date: Wed, 2 Nov 2005 17:29:41 +0100 User-Agent: KMail/1.8 References: <43635752.8090204@ericsson.com> <4368E482.9020907@sun.com> In-Reply-To: <4368E482.9020907@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511021729.41871.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Wednesday 02 November 2005 17:08, Erik Nordmark wrote: > Pekka Nikander wrote: > > - invisible HIP, or using HIP with IP addresses as LSIs, similar > > to SHIM6 ULIDs > > Aren't LSIs and SHIM6 ULIDs quite different with different > implications? The former is 32 bits, which makes it unlikely that > it will be a globally unique number, and the latter are regular > 128-bit IPv6 addresses. My understanding of LSI is that they are identifier meant to be used as HIT representation in legacy IP APIs. IIRC we discussed 128 bits LSIs a while ago; they would be prefixed by some fixed string allocated to HIP (similar to the 1.x.x.x/8 used for IPv4 LSIs). This is now part of the KHI concept: Having cryptographic identifier usable in legacy IPv6 APIs. Then I understand 'IP address as LSIs' as 'Use routable IP address in legacy APIs', which is, for IPv6, the same as SHIM6 ULID. If I am not wrong that is the approach chosen by the HIP implementation from Boeing. > So while both might result in "invisible HIP" it might make sense > to discuss them separately. But yes, I agree that it might make sense to discuss them separately because their uniqueness property are very different. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Nov 02 12:23:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMHI-0005XB-Fb; Wed, 02 Nov 2005 12:20:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMHG-0005WD-L6 for hipsec@megatron.ietf.org; Wed, 02 Nov 2005 12:19:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22841 for ; Wed, 2 Nov 2005 12:19:37 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMVs-0004pK-G6 for hipsec@ietf.org; Wed, 02 Nov 2005 12:35:05 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 89494212C55; Wed, 2 Nov 2005 19:19:38 +0200 (EET) In-Reply-To: <4368E482.9020907@sun.com> References: <43635752.8090204@ericsson.com> <4368E482.9020907@sun.com> 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: [Hipsec] Rechartering items? Date: Wed, 2 Nov 2005 18:19:36 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: HIP , David Ward 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Erik, >> - invisible HIP, or using HIP with IP addresses as LSIs, similar >> to SHIM6 ULIDs > > Aren't LSIs and SHIM6 ULIDs quite different with different > implications? That is certainly something that I would like to understand better. For IPv6, I would be tended to see SHIM6 ULIDs as a subset of what kind of identifiers you can use in HIP as ULIDs. > The former is 32 bits, which makes it unlikely that it will be a > globally unique number, and the latter are regular 128-bit IPv6 > addresses. You are right that LSIs were originally meant to be only 32 bits, but we've been discussing also 128 bit LSIs. Should probably invent a new name for them, to avoid confusion. > So while both might result in "invisible HIP" it might make sense > to discuss them separately. Based on the above, I'm not that sure. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Nov 03 10:01:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXgau-0005MQ-G9; Thu, 03 Nov 2005 10:01:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXgas-0005MA-FC for hipsec@megatron.ietf.org; Thu, 03 Nov 2005 10:01:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05271 for ; Thu, 3 Nov 2005 10:01:10 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXgpa-0005R0-1o for hipsec@ietf.org; Thu, 03 Nov 2005 10:16:49 -0500 Received: from [192.168.10.148] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 4329511C02235F8B; Thu, 3 Nov 2005 15:59:40 +0100 From: Julien Laganier To: Erik Nordmark , pekka.nikander@tml.hut.fi Date: Thu, 3 Nov 2005 16:02:07 +0100 User-Agent: KMail/1.8 References: <43635752.8090204@ericsson.com> <4368E482.9020907@sun.com> In-Reply-To: <4368E482.9020907@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511031602.08186.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: HIP Subject: [Hipsec] IPs as LSIs, and ULIDs (Was: Rechartering items?) 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Erik and Pekka, I thought a bit more... On Wednesday 02 November 2005 17:08, Erik Nordmark wrote: > Pekka Nikander wrote: > > - invisible HIP, or using HIP with IP addresses as LSIs, similar > > to SHIM6 ULIDs > > Aren't LSIs and SHIM6 ULIDs quite different with different > implications? The former is 32 bits, which makes it unlikely that > it will be a globally unique number, and the latter are regular > 128-bit IPv6 addresses. Let's say we are using IP addresses as LSIs. IMHO it is implicit that these IPs/LSIs are routable, because if they are not, then they would be quite similar to "pure LSIs". Then if these IPs/LSIs are routable, they can be expected to be globally unique... I am wrong? So the situation seems to be the same whether we use IPv4 or IPv6 addresses as IP/LSIs, the latter being the same than using SHIM6 ULIDs. Off course if one considers RFC1918 addresses the situation is different. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Nov 03 12:19:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXikE-0004AE-9P; Thu, 03 Nov 2005 12:19:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXikD-00049I-4d for hipsec@megatron.ietf.org; Thu, 03 Nov 2005 12:19:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14477 for ; Thu, 3 Nov 2005 12:18:59 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXiz2-0004Gq-9Y for hipsec@ietf.org; Thu, 03 Nov 2005 12:34:40 -0500 Received: from ganymede.students (ganymede.students [10.1.2.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E7270DC57; Thu, 3 Nov 2005 18:19:00 +0100 (CET) Received: from miriam ([10.1.2.130]) by ganymede.students with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 18:19:01 +0100 From: Miriam Esteban To: Julien Laganier , hipsec@ietf.org Subject: Re: [Hipsec] How to maintain a registered service? Date: Thu, 3 Nov 2005 18:18:53 +0100 User-Agent: KMail/1.8 References: <200510281130.14106.miriam.esteban@netlab.nec.de> <200510281718.02666.julien.IETF@laposte.net> In-Reply-To: <200510281718.02666.julien.IETF@laposte.net> MIME-Version: 1.0 Message-Id: <200511031818.55096.miriam.esteban@netlab.nec.de> X-OriginalArrivalTime: 03 Nov 2005 17:19:01.0061 (UTC) FILETIME=[AEB4FF50:01C5E09A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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: , Content-Type: multipart/mixed; boundary="===============1848026656==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============1848026656== Content-Type: multipart/alternative; boundary="Boundary-00=_/ZkaDkGfghMd0r2" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_/ZkaDkGfghMd0r2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Friday 28 October 2005 17:18, you wrote: > Hi Miriam, > > Thanks for bringing this issue to our attention. More thoughts are > inlined below: > > On Friday 28 October 2005 11:30, Miriam Esteban wrote: > > Dear all, > > > > While rereading the drafts about rvs and registration I have > > seen that there is nothing defined yet about how to maintain this > > registration alive. > > I don't think that the specification does not allow a requester to > prolong a registration. > > > I have one proposal for this. > > This consists of the REQUESTER sending one UPDATE packet with a > > REG_REQUEST parameter to the REGISTRAR. This packet should be send > > before the lifetime of the registered service is finished. If not, > > the REGISTRAR should remove the services registered by the > > REQUESTER. > > +-----+ +-----+-----+ > > | | UPDATE(REG_REQ:S) | | | > | > | RQ |---------------------------->| R | S | > | > | | UPDATE(REG_RESP:S) | | | > | |<----------------------------| | | > > +-----+ +-----+-----+ > > > This proposal conflicts with what it is said in > > draft-ietf-hip-registration-00. > > > > "Moreover, the requester MUST NOT include the > > parameter unless the registrar's R1 packet or latest received > > UPDATE packet has contained a REG_INFO parameter with the requested > > registration types." > > --- Talking about REG_REQUEST parameter---- > > > > Then, this maintaining process as it's explained here should be > > like it's reported in the draft: > > +-----+ +-----+-----+ > > | | UPDATE(REG_INFO:S) | | | > | |<----------------------------| | | > | | UPDATE(REG_REQ:S) | | | > | > | RQ |---------------------------->| R | S | > | > | | UPDATE(REG_RESP:S) | | | > | |<----------------------------| | | > > +-----+ +-----+-----+ > > > I don't see why it's necessary that the REGISTRAR is the one to > > trigger this process in the service maintainance. Maybe because the > > lifetimes are supposed quite big and the information about the > > services might have changed? > > It does not conflict. If a registration types is available (i.e. > announced in R1 or UPDATE) the requester to re-register before the > registration expire (i.e. prolong it). What is forbidden is to > register with a service currently unavailable (i.e. not announced in > R1 or in the last UPDATE.) > > In other words, a prolongation via another REG_REQ, REG_REP exchange > does not require that an UPDATE is sent by the registrar before hand. > > If people think that is unclear maybe we need to clarify this point. > I misunderstood because the specification said "latest received UPDATE", and the latest UPDATE sent by the registrar usually containes a REG_RESPONSE or a REG_FAILED, not a REG_INFO. Thanks Miriam --Boundary-00=_/ZkaDkGfghMd0r2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

On Friday 28 October 2005 17:18, you wrote:

> Hi Miriam,

>

> Thanks for bringing this issue to our attention. More thoughts are

> inlined below:

>

> On Friday 28 October 2005 11:30, Miriam Esteban wrote:

> > Dear all,

> >

> > While rereading the drafts about rvs and registration I have

> > seen that there is nothing defined yet about how to maintain this

> > registration alive.

>

> I don't think that the specification does not allow a requester to

> prolong a registration.

>

> > I have one proposal for this.

> > This consists of the REQUESTER sending one UPDATE packet with a

> > REG_REQUEST parameter to the REGISTRAR. This packet should be send

> > before the lifetime of the registered service is finished. If not,

> > the REGISTRAR should remove the services registered by the

> > REQUESTER.

>

> +-----+ +-----+-----+

>

> | | UPDATE(REG_REQ:S) | | |

> |

> | RQ |---------------------------->| R | S |

> |

> | | UPDATE(REG_RESP:S) | | |

> | |<----------------------------| | |

>

> +-----+ +-----+-----+

>

> > This proposal conflicts with what it is said in

> > draft-ietf-hip-registration-00.

> >

> > "Moreover, the requester MUST NOT include the

> > parameter unless the registrar's R1 packet or latest received

> > UPDATE packet has contained a REG_INFO parameter with the requested

> > registration types."

> > --- Talking about REG_REQUEST parameter----

> >

> > Then, this maintaining process as it's explained here should be

> > like it's reported in the draft:

>

> +-----+ +-----+-----+

>

> | | UPDATE(REG_INFO:S) | | |

> | |<----------------------------| | |

> | | UPDATE(REG_REQ:S) | | |

> |

> | RQ |---------------------------->| R | S |

> |

> | | UPDATE(REG_RESP:S) | | |

> | |<----------------------------| | |

>

> +-----+ +-----+-----+

>

> > I don't see why it's necessary that the REGISTRAR is the one to

> > trigger this process in the service maintainance. Maybe because the

> > lifetimes are supposed quite big and the information about the

> > services might have changed?

>

> It does not conflict. If a registration types is available (i.e.

> announced in R1 or UPDATE) the requester to re-register before the

> registration expire (i.e. prolong it). What is forbidden is to

> register with a service currently unavailable (i.e. not announced in

> R1 or in the last UPDATE.)

>

> In other words, a prolongation via another REG_REQ, REG_REP exchange

> does not require that an UPDATE is sent by the registrar before hand.

>

> If people think that is unclear maybe we need to clarify this point.

>

I misunderstood because the specification said "latest received UPDATE", and the latest UPDATE sent by the registrar usually containes a REG_RESPONSE or a REG_FAILED, not a REG_INFO.

Thanks

Miriam

--Boundary-00=_/ZkaDkGfghMd0r2-- --===============1848026656== 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 --===============1848026656==-- From hipsec-bounces@lists.ietf.org Thu Nov 03 16:24:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXmZ1-0006ad-43; Thu, 03 Nov 2005 16:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXmZ0-0006aT-02 for hipsec@megatron.ietf.org; Thu, 03 Nov 2005 16:24:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27180 for ; Thu, 3 Nov 2005 16:23:38 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXmnl-0004hU-K9 for hipsec@ietf.org; Thu, 03 Nov 2005 16:39:24 -0500 Received: from jurassic.eng.sun.com ([129.146.224.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jA3LNp4u010506; Thu, 3 Nov 2005 13:23:51 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jA3LNih2147316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Nov 2005 13:23:48 -0800 (PST) Message-ID: <436A7FDC.4090600@sun.com> Date: Thu, 03 Nov 2005 13:23:40 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier References: <43635752.8090204@ericsson.com> <4368E482.9020907@sun.com> <200511031602.08186.julien.IETF@laposte.net> In-Reply-To: <200511031602.08186.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: HIP , pekka.nikander@tml.hut.fi Subject: [Hipsec] Re: IPs as LSIs, and ULIDs (Was: Rechartering items?) 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Julien Laganier wrote: > Let's say we are using IP addresses as LSIs. IMHO it is implicit that > these IPs/LSIs are routable, because if they are not, then they would > be quite similar to "pure LSIs". > > Then if these IPs/LSIs are routable, they can be expected to be > globally unique... I am wrong? With NATs that isn't actually required - the destination address might be routable, but the source address will be replaced when passing through the NAT. But in any case, I've associated the term "LSI" with a number that the two peers make up and exchange. For clarity, if one is using routable IPv* addresses, it would make sense to give that a different term. > So the situation seems to be the same whether we use IPv4 or IPv6 > addresses as IP/LSIs, the latter being the same than using SHIM6 > ULIDs. Which brings us to what problem we are trying to solve by using ULIDs in HIP, and what the resulting security properties will be. If the ULPs identify the peer using a ULID, then the strength is limited by the 62 bit of hash that can be placed in the ULID, even if you have a HIT with a larger hash. How would the security properties of HIP with ULIDs differ from shim6+opportunistic IPsec? I imagine there is a difference in that the key used for ESP would be bound to a hash that is in the ULID. Is that correct? Erik _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Nov 04 01:09:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXulG-0007Tt-Ix; Fri, 04 Nov 2005 01:09:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXul8-0007Ti-Kd for hipsec@megatron.ietf.org; Fri, 04 Nov 2005 01:09:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24979 for ; Fri, 4 Nov 2005 01:08:44 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXv02-0002GY-Ud for hipsec@ietf.org; Fri, 04 Nov 2005 01:24:33 -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 WAA14471; Thu, 3 Nov 2005 22:08:39 -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 jA468cY06950; Fri, 4 Nov 2005 00:08:38 -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, 3 Nov 2005 22:08:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Rechartering items? Date: Thu, 3 Nov 2005 22:08:36 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E5F9@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Rechartering items? Thread-Index: AcXfx8sttiwSzQAsRjOo/zmqA2V3ugAxY+xw From: "Henderson, Thomas R" To: "Pekka Nikander" X-OriginalArrivalTime: 04 Nov 2005 06:08:37.0390 (UTC) FILETIME=[31F1A2E0:01C5E106] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: HIP , David Ward 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Wednesday, November 02, 2005 2:34 AM > To: Henderson, Thomas R > Cc: HIP; David Ward > Subject: Re: [Hipsec] Rechartering items? >=20 > Tom, >=20 > > The RG is also considering solutions involving HIP-aware=20 > firewalls and=20 > > NATs, but IMO that type of work (as well as native HIP API) is not=20 > > ready for a WG. >=20 > I agree. >=20 > >> - invisible HIP, or using HIP with IP addresses as LSIs,=20 > similar to=20 > >> SHIM6 ULIDs > >> > > A draft that discusses this topic is at: http://www.ietf.org/=20 > > internet-drafts/draft-henderson-hip-applications-01.txt > > > > It has not generated any mailing list or meeting discussion. I was=20 > > thinking of submitting it to RFC Editor as an individual=20 > submission. =20 > > This topic is not one that necessarily involves=20 > interoperability, so I=20 > > would like to understand better what is left to do (as a=20 > possible WG=20 > > item) beyond the present draft. >=20 > There are severe interoperability issues with upper layer=20 > protocols. =20 > Depending on what you use at the API as LSI, those upper=20 > layer protocols that send LSIs in their datagrams to third=20 > hosts will either fail or work. One could consider this also=20 > as an architectural issues, as it circles around the=20 > semantics of LSIs/ ULIDs, specifically whether they are=20 > routable or not. >=20 I was referring to HIP interoperability, but you are correct that more general interoperability conditions are a problem. I agree that there are upper-layer interoperability issues with RFC 1958-non-compliant applications if an HIP implementation decides to implement LSIs that spoof IP addresses to those apps. > The existing draft is pretty good in outlining the issues,=20 > and fine as long as we want to use HIP only as experimental. =20 > However, if we would like to advance HIP to standards track,=20 > then we need to have > *one* RECOMMENDED way for LSIs... The other way would remain=20 > experimental, between consenting hosts, IMHO. >=20 I would like to reserve judgement on whether only one way is needed until we get some more experience. =20 > At the protocol level there may be desire to negotiate this. =20 > I.e. an extension that defines in I2 which LSI format is used=20 > by the peer.... That could be informational, as any=20 > two-hosts protocols can function even if the communicating=20 > hosts use different LSI formats. >=20 I don't see how this would work since it is too late to be deciding on LSI once I2 is happening. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Nov 04 01:31:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXv6r-0003kD-Kb; Fri, 04 Nov 2005 01:31:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXv6q-0003k8-Iy for hipsec@megatron.ietf.org; Fri, 04 Nov 2005 01:31:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25754 for ; Fri, 4 Nov 2005 01:31:10 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXvLn-0002jq-6X for hipsec@ietf.org; Fri, 04 Nov 2005 01:46:59 -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 WAA19309; Thu, 3 Nov 2005 22:29:34 -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 jA46TXY17510; Fri, 4 Nov 2005 00:29:33 -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, 3 Nov 2005 22:29:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: IPs as LSIs, and ULIDs (Was: Rechartering items?) Date: Thu, 3 Nov 2005 22:29:32 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E5FA@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Re: IPs as LSIs, and ULIDs (Was: Rechartering items?) Thread-Index: AcXgwiw3/hLSa+CtRA+UfUn0NiluIwAQsjQw From: "Henderson, Thomas R" To: "Erik Nordmark" , "Julien Laganier" X-OriginalArrivalTime: 04 Nov 2005 06:29:33.0331 (UTC) FILETIME=[1E8B0630:01C5E109] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: HIP , pekka.nikander@tml.hut.fi 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com]=20 > Sent: Thursday, November 03, 2005 1:24 PM > To: Julien Laganier > Cc: HIP; pekka.nikander@tml.hut.fi > Subject: [Hipsec] Re: IPs as LSIs, and ULIDs (Was:=20 > Rechartering items?) >=20 > Which brings us to what problem we are trying to solve by=20 > using ULIDs in > HIP, and what the resulting security properties will be. >=20 > If the ULPs identify the peer using a ULID, then the strength=20 > is limited by the 62 bit of hash that can be placed in the=20 > ULID, even if you have a HIT with a larger hash. > How would the security properties of HIP with ULIDs differ from=20 > shim6+opportunistic IPsec? I imagine there is a difference in that the > key used for ESP would be bound to a hash that is in the=20 > ULID. Is that correct? >=20 I agree-- if you trust the 62 bit hash length, then it seems like it is equivalent to security of pure HIP. I do not think that invisible HIP is so hard to do-- we have been doing a basic form of it for a few years, and interoperating successfully with others who have not. It should also work on the referral-type apps, although we have not tested that explictly. Regarding the security properties of doing it this way, I think that it relies on security of DNS. But in practice, won't it usually be the case that DNS or some resolution needs to be trusted? How many people are going to bother to type in HITs into their application's URL fields? Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Nov 04 04:22:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXxmk-00068W-Cp; Fri, 04 Nov 2005 04:22:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXxmh-00068N-UN for hipsec@megatron.ietf.org; Fri, 04 Nov 2005 04:22:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05288 for ; Fri, 4 Nov 2005 04:22:32 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXy1f-0007qb-1b for hipsec@ietf.org; Fri, 04 Nov 2005 04:38:24 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E857E212C55; Fri, 4 Nov 2005 11:22:27 +0200 (EET) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E5F9@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6DC9E5F9@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D819188-45D3-4F5B-94EE-E19AB7FBF7D6@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Rechartering items? Date: Fri, 4 Nov 2005 10:22:27 +0100 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >>>> - invisible HIP, or using HIP with IP addresses as LSIs, >>>> similar to SHIM6 ULIDs >>>> >>> A draft that discusses this topic is at: http://www.ietf.org/ >>> internet-drafts/draft-henderson-hip-applications-01.txt > >> At the protocol level there may be desire to negotiate this. I.e. >> an extension that defines in I2 which LSI format is used by the >> peer.... That could be informational, as any two-hosts protocols >> can function even if the communicating hosts use different LSI >> formats. >> > > I don't see how this would work since it is too late to be deciding on > LSI once I2 is happening. I was merely thinking about error diagnostics. It may be good to know what what kind of upper layer identifiers your peer is using in its legacy API, even if you can't adopt your own behaviour any more at that place. I realise I used the term "negotiate" improperly. To clarify: it may be a good idea for hosts to tell their peers what kind of upper layer identifiers they are using in their legacy API, in order to better diagnose potential conditions where using different kind of formats lead to upper-layer error conditions. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Nov 04 09:37:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY2hI-00008k-Bw; Fri, 04 Nov 2005 09:37:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY2hG-00008f-W3 for hipsec@megatron.ietf.org; Fri, 04 Nov 2005 09:37:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23269 for ; Fri, 4 Nov 2005 09:37:15 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY2wG-0000DZ-Dj for hipsec@ietf.org; Fri, 04 Nov 2005 09:53:09 -0500 Received: from [192.168.1.105] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 433BC54A022F72CB; Fri, 4 Nov 2005 15:36:06 +0100 From: Julien Laganier Subject: Re: [Hipsec] Rechartering items? Date: Fri, 4 Nov 2005 15:38:30 +0100 User-Agent: KMail/1.8 References: <43635752.8090204@ericsson.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline To: "Undisclosed.Recipients": ; Message-Id: <200511041538.30978.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: HIP , pekka.nikander@tml.hut.fi 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Tuesday 01 November 2005 11:52, Pekka Nikander wrote: > > What else would be both important and mature enough for WG side > work? What about support for inter-addressing-domain communication, i.e. IPv4-to-IPv{4|6} ? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Nov 05 13:02:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYSN8-0003Tt-N0; Sat, 05 Nov 2005 13:02:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYSN7-0003Sl-3q for hipsec@megatron.ietf.org; Sat, 05 Nov 2005 13:02:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12301 for ; Sat, 5 Nov 2005 13:02:07 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYScJ-0007r9-5H for hipsec@ietf.org; Sat, 05 Nov 2005 13:18:18 -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 MAA12795 for ; Sat, 5 Nov 2005 12:02:14 -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 jA5I2EY18534 for ; Sat, 5 Nov 2005 12:02:14 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Nov 2005 10:02:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] WGLC draft-ietf-hip-registration-00.txt Date: Sat, 5 Nov 2005 10:02:13 -0800 Message-ID: <0DF156EE7414494187B087A3C279BDB40163DC40@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] WGLC draft-ietf-hip-registration-00.txt Thread-Index: AcXT2Zedm0tBH6wgSnSG7QjpF6npQwOWTgsA From: "Ahrenholz, Jeffrey M" To: "HIP" X-OriginalArrivalTime: 05 Nov 2005 18:02:13.0818 (UTC) FILETIME=[0CEFD1A0:01C5E233] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I read this draft and don't have any specific comments -- I thought it was nice and simple and clearly written. -Jeff > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Tuesday, October 18, 2005 4:43 AM > To: HIP > Cc: Lars Eggert; teemu.koponen@hiit.fi; Julien Laganier > Subject: [Hipsec] WGLC draft-ietf-hip-registration-00.txt >=20 >=20 > Folks, >=20 > we would like to working group last call the following draft. This=20 > working group last call will end on November 6th. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-00.txt >=20 > Send your comments to this list. >=20 > Note that Jari's comments on this draft will be taken as WGLC=20 > 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 Sat Nov 05 13:17:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYSbm-0006NZ-Ap; Sat, 05 Nov 2005 13:17:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYSbj-0006Mp-4r for hipsec@megatron.ietf.org; Sat, 05 Nov 2005 13:17:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12753 for ; Sat, 5 Nov 2005 13:17:14 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYSqw-00088j-B9 for hipsec@ietf.org; Sat, 05 Nov 2005 13:33:24 -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 KAA01565; Sat, 5 Nov 2005 10:17:19 -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 jA5IHJH08221; Sat, 5 Nov 2005 10:17:19 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Nov 2005 10:17:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] WGLC draft-ietf-hip-dns-03.txt Date: Sat, 5 Nov 2005 10:17:18 -0800 Message-ID: <0DF156EE7414494187B087A3C279BDB40163DC41@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] WGLC draft-ietf-hip-dns-03.txt Thread-Index: AcXT2RqKav6r01W+TlWJw3MTZRS1GwOWfthQ From: "Ahrenholz, Jeffrey M" To: "HIP" X-OriginalArrivalTime: 05 Nov 2005 18:17:19.0664 (UTC) FILETIME=[28DCF300:01C5E235] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: Pekka Nikander , Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org After reading this draft, I have two questions: 1. Why store the HIT plus the entire Host Identity in DNS? For a base exchange, it would be sufficient to just retrieve the HIT, because you need to verify the HI received from your peer anyway. With large key sizes this seems like a waste of space in the DNS server. This draft says you MUST calculate the HIT from the received HI, this seems redundant with the calculation performed during the base exchange. The only reason I can think of is for middlebox verification of signatures. Maybe that requirement shouldn't imply that I need to do extra processing of the DNS HI if I really only want the HIT to perform a base exchange. 2. Why is there a separate HIT length in the RDATA format, but in the examples the HIT length field is implicitly known? (is HIT length needed?) -Jeff > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Tuesday, October 18, 2005 4:42 AM > To: HIP > Cc: Pekka Nikander; Julien Laganier > Subject: [Hipsec] WGLC draft-ietf-hip-dns-03.txt >=20 >=20 > Folks, >=20 > we would like to working group last call the following draft. This=20 > working group last call will end on November 6th. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-03.txt >=20 > Send your comments to this list. >=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 Sat Nov 05 17:52:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYWtz-000353-MY; Sat, 05 Nov 2005 17:52:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYWtw-00033Y-3W for hipsec@megatron.ietf.org; Sat, 05 Nov 2005 17:52:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24750 for ; Sat, 5 Nov 2005 17:52:19 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYX9C-0005v6-E5 for hipsec@ietf.org; Sat, 05 Nov 2005 18:08:31 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7D2CC89871; Sun, 6 Nov 2005 00:52:31 +0200 (EET) Message-ID: <436D372F.5010002@piuha.net> Date: Sun, 06 Nov 2005 00:50:23 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: hipsec-rg@honor.trusecure.com, hipsec@ietf.org Subject: [Hipsec] Comment on draft-tschofenig-hiprg-host-identities-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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hannes, The discussion on draft-papadoglou-hiprg-hit-presence-00.txt led me to go back to your draft and re-read it... and I have a question. Your note about this being related to the PBK idea led me to think about the semantics of the transported HITs. What specifically are the semantics? The security of PBK approaches depend very much on to what the keys are bound to, how, and for how long. Here's some potential answers and related considerations: 1. Receiver binds sip-level identity to the HIT forever. This could lead to a vulnerability where, if I can once spoof a signalling message in some environment, I can take over someone's identity or at least render it unusable. 2. Receiver binds sip-level identity to the HIT after SSH style user confirmation (similar to what the base SIP spec already does for S/MIME). This is more workable. Not sure people in all environments are willing to do the confirmations in reliable manner. 3. HITs apply for a session; The HITs may be updated at any time through the SIP signalling messages. This seems more reasonable. But if hosts may talk directly SIP to each other (as they can in SIP) then one of your assumptions about a different path for the signaling traffic is violated. Of course, if there's security for the direct SIP connection then this won't be a problem - but such security essentially implies some cert-based solution, which could obviously be used for media protection too, without HIP. 4. The HITs may be updated at any time during a session, but we only support configuration through infrastructure. Based on item 3 above, this seems quite sensible. Incidentally, this is similar to what the presence approach was. 5. Session-based semantics where initial message has to contain all the identities. Identity hijack is not an issue beyond one session. Security of direct host-to-host SIP communications does not matter, because the initial messages are typically through the infrastructure anyway. Approach 4 seems most reasonable, but I could be missing something. --Jari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Nov 06 17:31:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYt3O-0000Tx-1B; Sun, 06 Nov 2005 17:31:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYt3M-0000Ts-Ew for hipsec@megatron.ietf.org; Sun, 06 Nov 2005 17:31:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24288 for ; Sun, 6 Nov 2005 17:31:31 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYtIq-0006w3-Ap for hipsec@ietf.org; Sun, 06 Nov 2005 17:47:56 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA01566; Sun, 6 Nov 2005 14:31:34 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jA6MVYd15298; Sun, 6 Nov 2005 14:31:34 -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); Sun, 6 Nov 2005 14:31:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] WGLC draft-ietf-hip-dns-03.txt Date: Sun, 6 Nov 2005 14:31:33 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E616@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] WGLC draft-ietf-hip-dns-03.txt Thread-Index: AcXYl+i6Z2eJhKqyQgm9D/2fa9IyiwKa/LXg From: "Henderson, Thomas R" To: "Pekka Nikander" , "HIP" X-OriginalArrivalTime: 06 Nov 2005 22:31:34.0168 (UTC) FILETIME=[D7AB4980:01C5E321] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Monday, October 24, 2005 5:36 AM > To: HIP > Cc: Julien Laganier > Subject: Re: [Hipsec] WGLC draft-ietf-hip-dns-03.txt >=20 > While being an author of the draft and therefore considering=20 > the draft pretty good, I'd like to get the WG's opinion on a=20 > few issues on the draft: >=20 > 1. Is the introduction too long? Would it be desirable to=20 > cut some text from there, and if yes, what? I don't think that paragraphs 2-7 (until you reach the paragraph beginning "Currently, ...") are necessary >=20 > 2. Is the approach right? >=20 > Might it be better, for example, to define just a single new=20 > RR, which would contain the HIT, HI, and RVS domain name? =20 > Given the current design, the resolve needs to send DNS=20 > queries for A, AAAA, HIPHI and HIPRVS in order to get all=20 > data it needs. With the alternative design, it would first=20 > ask for HIPHI, and then based on whether there is an RVS=20 > name, A and/or AAAA of either the host itself or its RVS server. I would prefer fewer lookups and fewer round trip times. It seems possible that several lookups might be needed in cases involving RVS. The alternative you mention seems like it could be better performing, at the expense of a more complicated record. As it presently reads, a querying host receiving the HIPHI does not know whether the responder also has a HIPRVS that needs to be fetched; it seems like HIPRVS always needs to be fetched anyway, just to make sure. I was thinking that a flag in the HIPHI, denoting whether HIPRVS exists, could be useful, but it may be better just to combine HIPHI and HIPRVS records, such as something like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record type | PK algorithm| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIT | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / Public Key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preference | type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ rendezvous server | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where "record type" can denote whether a RVS is appended after the public key, and "PK algorithm" can be used to infer the HIT and public key lengths. >=20 > 3. Are the details fine? >=20 > 4. Is there something unnecessary (beyond the introduction),=20 > something that should be left out? >=20 > --Pekka >=20 The abbreviation ULP should be spelled out at the first occurrence. Strictly speaking, all ULPs are not agnostic to IP address changes (congestion control protocols, for example). (this is stated in Section 3). In section 6.1, s/HPIHI/HIPHI Jeff raised an interesting question, whether the thrust of this draft should be in providing DNS->HI or DNS->HIT lookup. I think that section 8.5 addresses this question-- it is probably OK for now to trust the HIT/HI binding, but perhaps not always in the future. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Nov 06 17:48:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYtJA-0003y3-Q8; Sun, 06 Nov 2005 17:48:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYtJ9-0003x0-JS for hipsec@megatron.ietf.org; Sun, 06 Nov 2005 17:48:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24937 for ; Sun, 6 Nov 2005 17:47:50 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYtYa-0007HO-HW for hipsec@ietf.org; Sun, 06 Nov 2005 18:04:16 -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 OAA27898; Sun, 6 Nov 2005 14:47:53 -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 jA6MlqH28206; Sun, 6 Nov 2005 14:47:52 -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); Sun, 6 Nov 2005 14:47:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] WGLC draft-ietf-hip-registration-00.txt Date: Sun, 6 Nov 2005 14:47:52 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E617@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] WGLC draft-ietf-hip-registration-00.txt Thread-Index: AcXT2ZfClf4tXj64TS6AxNpCqRsrJQPSFjXA From: "Henderson, Thomas R" To: "Gonzalo Camarillo" , "HIP" X-OriginalArrivalTime: 06 Nov 2005 22:47:52.0656 (UTC) FILETIME=[1EE4B500:01C5E324] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: Lars Eggert , teemu.koponen@hiit.fi, Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Tuesday, October 18, 2005 4:43 AM > To: HIP > Cc: Lars Eggert; teemu.koponen@hiit.fi; Julien Laganier > Subject: [Hipsec] WGLC draft-ietf-hip-registration-00.txt >=20 > Folks, >=20 > we would like to working group last call the following draft.=20 > This working group last call will end on November 6th. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-00.txt >=20 > Send your comments to this list. >=20 > Note that Jari's comments on this draft will be taken as WGLC=20 > comments. >=20 The first citation in the introduction should probably refer to the base spec, not the architecture. In section 5, I don't know where 10 and 120 seconds (MUST minimum and SHOULD maximum registration lifetimes, respectively) come from, nor why such values need to be specified now. Otherwise, I don't have further comments and support going forward with it. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Nov 06 18:07:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYtc8-0008Nu-Lj; Sun, 06 Nov 2005 18:07:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYtc6-0008Np-AP for hipsec@megatron.ietf.org; Sun, 06 Nov 2005 18:07:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25779 for ; Sun, 6 Nov 2005 18:07:24 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYtrZ-0007i4-Hq for hipsec@ietf.org; Sun, 06 Nov 2005 18:23:51 -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 RAA22099; Sun, 6 Nov 2005 17:07:27 -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 jA6N7RH11290; Sun, 6 Nov 2005 15:07:27 -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); Sun, 6 Nov 2005 15:07:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] WGLC draft-ietf-hip-rvs-04.txt Date: Sun, 6 Nov 2005 15:07:26 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E618@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] WGLC draft-ietf-hip-rvs-04.txt Thread-Index: AcXT2YxaIfgEQfB4QHqtbaHkSW+D0gPSxxiQ From: "Henderson, Thomas R" To: "Gonzalo Camarillo" , "HIP" X-OriginalArrivalTime: 06 Nov 2005 23:07:27.0015 (UTC) FILETIME=[DADDAB70:01C5E326] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: Lars Eggert , Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Tuesday, October 18, 2005 4:42 AM > To: HIP > Cc: Lars Eggert; Julien Laganier > Subject: [Hipsec] WGLC draft-ietf-hip-rvs-04.txt >=20 > Folks, >=20 > we would like to working group last call the following draft.=20 > This working group last call will end on November 6th. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-04.txt >=20 > Send your comments to this list. >=20 In section 4.3.1 (use of opportunistic HIP mode) there may be some conflict with what is recommended in the DNS draft, section 7, that when multiple HITs are in DNS, opportunistic mode is recommended. Maybe the multiple HIT case needs further clarification here in section 4.3.1. Overall, I'm glad that this draft was simplified to handle only the I1 forwarding case without opportunistic mode, and think that it is much more straightforward now. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 07 13:36:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBr7-0002Ll-OI; Mon, 07 Nov 2005 13:36:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBr5-0002F3-JP for hipsec@megatron.ietf.org; Mon, 07 Nov 2005 13:36:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28099 for ; Mon, 7 Nov 2005 13:36:05 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZC6i-000462-Sa for hipsec@ietf.org; Mon, 07 Nov 2005 13:52:42 -0500 Received: from [209.52.106.172] (209.52.106.172) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42DE178C04097CDA; Mon, 7 Nov 2005 19:36:07 +0100 From: Julien Laganier To: "Ahrenholz, Jeffrey M" Subject: Re: [Hipsec] WGLC draft-ietf-hip-dns-03.txt Date: Mon, 7 Nov 2005 19:37:36 +0100 User-Agent: KMail/1.8 References: <0DF156EE7414494187B087A3C279BDB40163DC41@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB40163DC41@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071937.36551.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi Jeff, On Saturday 05 November 2005 19:17, Ahrenholz, Jeffrey M wrote: > After reading this draft, I have two questions: > > 1. Why store the HIT plus the entire Host Identity in DNS? > For a base exchange, it would be sufficient to just retrieve the > HIT, because you need to verify the HI received from your peer > anyway. With large key sizes this seems like a waste of space in > the DNS server. Well, the HI and HIT have different security properties. If you only store the HIT in the DNS then you have in effect a leveling of different key strengths (e.g. 4096 vs 2048 bits) to the strength provided by the 128 bits long HIT. So while it is true that knowledge of the HIT is sufficient to run the base exchange, in some situation you also want to retrieve the whole HI from a trusted third party (the DNS in that case), and not just a representation of it (the HIT). > This draft says you MUST calculate the HIT from the > received HI, this seems redundant with the calculation performed > during the base exchange. Actually the draft refers to the same calculation performed in the base exchange. Perhaps the corresponding text should be removed... > The only reason I can think of is for middlebox verification of > signatures. Maybe that requirement shouldn't imply that I need to > do extra processing of the DNS HI if I really only want the HIT to > perform a base exchange. > > 2. Why is there a separate HIT length in the RDATA format, but in > the examples the HIT length field is implicitly known? (is HIT > length needed?) The HIT length is needed to allow to store longer HITs in the RR. That might be required in the future for security reasons. And the length is not present in the examples because it is implicit in the presentation format (as opposed to what goes on the wire): you just need to count characters. Does the above answer your questions? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 07 14:02:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCGC-0008VC-9M; Mon, 07 Nov 2005 14:02:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCGB-0008V7-Ih for hipsec@megatron.ietf.org; Mon, 07 Nov 2005 14:02:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00269 for ; Mon, 7 Nov 2005 14:02:01 -0500 (EST) Received: from rat01038.dc-ratingen.de ([195.233.129.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCVk-00052j-FA for hipsec@ietf.org; Mon, 07 Nov 2005 14:18:38 -0500 Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26]) by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jA7J24Bd003614 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 7 Nov 2005 20:02:04 +0100 (MET) Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115]) by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jA7J22YC010946 for ; Mon, 7 Nov 2005 20:02:02 +0100 (MET) Received: from gpsmx10.gps.internal.vodafone.com ([145.230.1.20]) by gpsmxr04.gps.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 20:02:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Nov 2005 19:01:58 -0000 Message-ID: Thread-Topic: I-D ACTION:draft-dietz-hip-operator-issues-00.txt Thread-Index: AcXjzbpShixl6q4gTii4mPCXJthSCA== From: "Papadoglou, Nick, VF-Group" To: "HIP" X-OriginalArrivalTime: 07 Nov 2005 19:02:04.0079 (UTC) FILETIME=[BDB9ABF0:01C5E3CD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Hipsec] I-D ACTION:draft-dietz-hip-operator-issues-00.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: , Content-Type: multipart/mixed; boundary="===============0693325650==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0693325650== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E3CD.BCE2C5A6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E3CD.BCE2C5A6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 We have submitted the following ID which we would like to present/discuss tomorrow at our slot if there is enough time. Comments are more than welcome.=20 http://www.ietf.org/internet-drafts/draft-dietz-hip-operator-issues-00.t xt =20 Many thanks, =20 Nick =20 =20 ------_=_NextPart_001_01C5E3CD.BCE2C5A6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
We = have submitted=20 the following ID which we would like to present/discuss tomorrow at our = slot if=20 there is enough time. Comments are more than welcome. =
http://www.ietf.org/internet-drafts/draft-dietz-hip-operator-i= ssues-00.txt
 
Many=20 thanks,
 
Nick
 
 
------_=_NextPart_001_01C5E3CD.BCE2C5A6-- --===============0693325650== 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 --===============0693325650==-- From hipsec-bounces@lists.ietf.org Mon Nov 07 14:15:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCSs-0005Mf-1e; Mon, 07 Nov 2005 14:15:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCSq-0005Ky-8D for hipsec@megatron.ietf.org; Mon, 07 Nov 2005 14:15:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01443 for ; Mon, 7 Nov 2005 14:15:05 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCiT-0005WX-8j for hipsec@ietf.org; Mon, 07 Nov 2005 14:31:43 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EZCSi-0003hT-6v for hipsec@ietf.org; Mon, 07 Nov 2005 14:15:24 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A6AF2212C55; Mon, 7 Nov 2005 21:09:47 +0200 (EET) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E617@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6DC9E617@XCH-NW-5V1.nw.nos.boeing.com> 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: [Hipsec] WGLC draft-ietf-hip-registration-00.txt Date: Mon, 7 Nov 2005 11:09:42 -0800 To: Teemu Koponen , Thomas R Henderson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Lars Eggert , HIP , Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> we would like to working group last call the following draft. >> This working group last call will end on November 6th. >> >> http://www.ietf.org/internet-drafts/draft-ietf-hip- >> registration-00.txt >> >> Send your comments to this list. > > In section 5, I don't know where 10 and 120 seconds (MUST minimum and > SHOULD maximum registration lifetimes, respectively) come from, nor > why > such values need to be specified now. IMHO, there is value in defining them; they set a baseline for expectations. That as a goal, I tried to come up with sensible defaults, once that are not too long nor too short. We also tried to take care of NAT considerations, having defaults that would probably play nicely with existing timeouts in NATs. The ones chosen looked like reasonable values. The minimum seemed more important to me; if there is no guarantee of a minimum, you may have hard time in developing any systems based upon the registration system. Maybe add a sentence or two explaining the above? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 07 16:10:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEG1-0000SS-Rb; Mon, 07 Nov 2005 16:10:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEFz-0000SK-U2 for hipsec@megatron.ietf.org; Mon, 07 Nov 2005 16:10:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07973 for ; Mon, 7 Nov 2005 16:09:56 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZEVe-0000K4-Du for hipsec@ietf.org; Mon, 07 Nov 2005 16:26:36 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E6542212C55; Mon, 7 Nov 2005 23:09:51 +0200 (EET) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E616@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6DC9E616@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C5B9FD7-5705-4D21-A82C-E5E5AABCE655@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] WGLC draft-ietf-hip-dns-03.txt Date: Mon, 7 Nov 2005 13:09:45 -0800 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: HIP , Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> 1. Is the introduction too long? Would it be desirable to >> cut some text from there, and if yes, what? > > I don't think that paragraphs 2-7 (until you reach the paragraph > beginning "Currently, ...") are necessary Agreed. That was more or less what I was thinking myself, but I wanted to get a second independent opinion. >> 2. Is the approach right? >> >> Might it be better, for example, to define just a single new >> RR, which would contain the HIT, HI, and RVS domain name? > > I would prefer fewer lookups and fewer round trip times. It seems > possible that several lookups might be needed in cases involving RVS. > The alternative you mention seems like it could be better > performing, at > the expense of a more complicated record. I concur. > As it presently reads, a querying host receiving the HIPHI does not > know > whether the responder also has a HIPRVS that needs to be fetched; it > seems like HIPRVS always needs to be fetched anyway, just to make > sure. > I was thinking that a flag in the HIPHI, denoting whether HIPRVS > exists, > could be useful, but it may be better just to combine HIPHI and HIPRVS > records, Again, I agree. > such as something like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record type | PK algorithm| | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIT | > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | / > / Public Key / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | preference | type | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ rendezvous server | > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > where "record type" can denote whether a RVS is appended after the > public key, and "PK algorithm" can be used to infer the HIT and public > key lengths. I am not quite sure about this particular design; more thinking seems to be needed. For example, with this there is no easy way for having multiple RVS with different preferences. It may also become slightly harder to associate a DNS name with several HITs, depending on the exact semantics. It may also be better to be explicit about the HIT and PK length, leaving less ambiguity. If we embed RVS information to HIPHI, might it be better to include there always a domain name of the RVS server, and never IP addresses? One could then get the IP addresses from the DNS name, using A and AAAA as usually. If there is no RVS DNS name, the initial DNS name is used for getting A and AAAA too. The drawback of that is that it would drop the possibility of having preference order of RVS servers, making all RVS servers equal. Maybe something like the following? - DNS name of the RVS server, non-compressed FQDN in binary form - if NULL, use the present FQDN to fetch A and AAAA records - HIT length (bytes), HIT in binary - PK algorithm, PK length (multiple of 8), PK in binary Explicit PK length allows other data to be appended to the record later, if need arises, but I don't know if we need it. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 07 16:33:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEcZ-0005YY-2b; Mon, 07 Nov 2005 16:33:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEcX-0005WK-Gr for hipsec@megatron.ietf.org; Mon, 07 Nov 2005 16:33:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09191 for ; Mon, 7 Nov 2005 16:33:16 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZEsA-0000wi-K0 for hipsec@ietf.org; Mon, 07 Nov 2005 16:49:54 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA09773; Mon, 7 Nov 2005 13:33:21 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jA7LXKd15433; Mon, 7 Nov 2005 13:33:20 -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, 7 Nov 2005 13:33:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] I-D ACTION:draft-dietz-hip-operator-issues-00.txt Date: Mon, 7 Nov 2005 13:33:19 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E61F@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] I-D ACTION:draft-dietz-hip-operator-issues-00.txt Thread-Index: AcXjzbpShixl6q4gTii4mPCXJthSCAAFOV7Q From: "Henderson, Thomas R" To: "Papadoglou, Nick, VF-Group" X-OriginalArrivalTime: 07 Nov 2005 21:33:19.0882 (UTC) FILETIME=[DF534EA0:01C5E3E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Nick, This topic (deployment issues of HIP) is within scope of the HIP RG, so I invite you to present it on Friday also if you are able to. Please let me know. =20 Thanks, Tom ________________________________ From: Papadoglou, Nick, VF-Group [mailto:Nick.Papadoglou@vodafone.com]=20 Sent: Monday, November 07, 2005 11:02 AM To: HIP Subject: [Hipsec] I-D ACTION:draft-dietz-hip-operator-issues-00.txt =09 =09 Hi, =20 We have submitted the following ID which we would like to present/discuss tomorrow at our slot if there is enough time. Comments are more than welcome.=20 =09 http://www.ietf.org/internet-drafts/draft-dietz-hip-operator-issues-00.t xt =20 Many thanks, =20 Nick =20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 07 17:40:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFf9-00045m-Ef; Mon, 07 Nov 2005 17:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFf8-00045X-2O for hipsec@megatron.ietf.org; Mon, 07 Nov 2005 17:40:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13803 for ; Mon, 7 Nov 2005 17:40:00 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZFul-000331-ON for hipsec@ietf.org; Mon, 07 Nov 2005 17:56:39 -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 OAA29911; Mon, 7 Nov 2005 14:40:06 -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 jA7Me6H13714; Mon, 7 Nov 2005 14:40:06 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 14:40:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] WGLC draft-ietf-hip-dns-03.txt Date: Mon, 7 Nov 2005 14:40:02 -0800 Message-ID: <0DF156EE7414494187B087A3C279BDB40163DC44@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] WGLC draft-ietf-hip-dns-03.txt Thread-Index: AcXjyh/YecK7yD8nSIedgVKbX+MPjwAID6Hw From: "Ahrenholz, Jeffrey M" To: "Julien Laganier" X-OriginalArrivalTime: 07 Nov 2005 22:40:02.0820 (UTC) FILETIME=[31432C40:01C5E3EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > So while it is true that knowledge of the HIT is sufficient=20 > to run the base exchange, in some situation you also want to retrieve the whole=20 > HI from a trusted third party (the DNS in that case), and not just a=20 > representation of it (the HIT).=20 OK, that answers my first question. > The HIT length is needed to allow to store longer HITs in the=20 > RR. That might be required in the future for security reasons. And the length=20 > is not present in the examples because it is implicit in the=20 > presentation format (as opposed to what goes on the wire): you just=20 > need to count characters. >=20 > Does the above answer your questions? OK, can this HIT length be inferred by the HIT prefix? If a new HIT type is defined in the future, I thought that it would be defined using a new prefix. (see http://www1.ietf.org/mail-archive/web/hipsec/current/msg01519.html) So the HIT length field still seems unnecessary. -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 07 18:01:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFzA-0000wu-EA; Mon, 07 Nov 2005 18:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFz9-0000wp-MW for hipsec@megatron.ietf.org; Mon, 07 Nov 2005 18:01:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15340 for ; Mon, 7 Nov 2005 18:00:41 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZGEo-0003ir-N1 for hipsec@ietf.org; Mon, 07 Nov 2005 18:17:21 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9A935212C8B; Tue, 8 Nov 2005 01:00:21 +0200 (EET) In-Reply-To: <0DF156EE7414494187B087A3C279BDB40163DC44@XCH-NW-6V1.nw.nos.boeing.com> References: <0DF156EE7414494187B087A3C279BDB40163DC44@XCH-NW-6V1.nw.nos.boeing.com> 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: [Hipsec] WGLC draft-ietf-hip-dns-03.txt Date: Mon, 7 Nov 2005 15:00:09 -0800 To: "Ahrenholz, Jeffrey M" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> The HIT length is needed to allow to store longer HITs in the >> RR. That might be required in the future for security reasons. And >> the length >> is not present in the examples because it is implicit in the >> presentation format (as opposed to what goes on the wire): you just >> need to count characters. >> >> Does the above answer your questions? > > OK, can this HIT length be inferred by the HIT prefix? > If a new HIT type is defined in the future, I thought that it would be > defined using a new prefix. (see > http://www1.ietf.org/mail-archive/web/hipsec/current/msg01519.html) > So the HIT length field still seems unnecessary. While that may be true, it would break forward compatibility. That is, you couldn't store new types of HITs into DNS before all implementations were updated to support them. That would be bad. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 07 21:32:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJI1-0007P6-1C; Mon, 07 Nov 2005 21:32:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJHz-0007Ow-2T for hipsec@megatron.ietf.org; Mon, 07 Nov 2005 21:32:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03081 for ; Mon, 7 Nov 2005 21:32:20 -0500 (EST) Received: from rat01038.dc-ratingen.de ([195.233.129.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJXb-0002zr-TN for hipsec@ietf.org; Mon, 07 Nov 2005 21:49:02 -0500 Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26]) by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jA82WLH9017538 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Nov 2005 03:32:21 +0100 (MET) Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115]) by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jA82WKep002579; Tue, 8 Nov 2005 03:32:20 +0100 (MET) Received: from gpsmx10.gps.internal.vodafone.com ([145.230.1.20]) by gpsmxr04.gps.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 03:32:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 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] I-D ACTION:draft-dietz-hip-operator-issues-00.txt Date: Tue, 8 Nov 2005 02:32:18 -0000 Message-ID: Thread-Topic: [Hipsec] I-D ACTION:draft-dietz-hip-operator-issues-00.txt Thread-Index: AcXjzbpShixl6q4gTii4mPCXJthSCAAFOV7QAAow5SA= From: "Papadoglou, Nick, VF-Group" To: "Henderson, Thomas R" X-OriginalArrivalTime: 08 Nov 2005 02:32:23.0350 (UTC) FILETIME=[A6773D60:01C5E40C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Tom, I have requested a 10 to 15 minute slot from Gonzalo to present the work tomorrow in the WG session, although as you mention it might be more relevant to the RG. Hence, I will take up your offer and present it on Friday and maybe decide there if it should be part of the new HIP WG after the re-chartering or remain under the RG.=20 Regards, Nick >-----Original Message----- >From: Henderson, Thomas R [mailto:thomas.r.henderson@boeing.com]=20 >Sent: 07 November 2005 21:33 >To: Papadoglou, Nick, VF-Group >Cc: hipsec-rg@honor.trusecure.com; HIP >Subject: RE: [Hipsec] I-D ACTION:draft-dietz-hip-operator-issues-00.txt > >Nick, >This topic (deployment issues of HIP) is within scope of the=20 >HIP RG, so I invite you to present it on Friday also if you=20 >are able to. Please let me know. >=20 >Thanks, >Tom > > >________________________________ > > From: Papadoglou, Nick, VF-Group >[mailto:Nick.Papadoglou@vodafone.com]=20 > Sent: Monday, November 07, 2005 11:02 AM > To: HIP > Subject: [Hipsec] I-D >ACTION:draft-dietz-hip-operator-issues-00.txt >=09 >=09 > Hi, > =20 > We have submitted the following ID which we would like=20 >to present/discuss tomorrow at our slot if there is enough=20 >time. Comments are more than welcome.=20 >=09 >http://www.ietf.org/internet-drafts/draft-dietz-hip-operator-is sues-00.t >xt > =20 > Many thanks, > =20 > Nick > =20 > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Nov 08 18:20:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcl8-0006qs-RN; Tue, 08 Nov 2005 18:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcl8-0006ql-BW for hipsec@megatron.ietf.org; Tue, 08 Nov 2005 18:20:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12995 for ; Tue, 8 Nov 2005 18:19:44 -0500 (EST) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZd0z-0004K8-RM for hipsec@ietf.org; Tue, 08 Nov 2005 18:36:36 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CF27C2DA1; Wed, 9 Nov 2005 01:19:55 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.0-niksula20040914 (2005-09-13) on twilight.cs.hut.fi 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 7C1182D66 for ; Wed, 9 Nov 2005 01:19:55 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id jA8NJtT09331; Wed, 9 Nov 2005 01:19:55 +0200 (EET) Date: Wed, 9 Nov 2005 01:19:55 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [Hipsec] jabber scribe 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I'll be making a jabber scribe at the channel hip@private.jabber.org if you are interested. -- 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 Tue Nov 08 18:27:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcru-0008Hn-6z; Tue, 08 Nov 2005 18:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcrs-0008Hi-SB for hipsec@megatron.ietf.org; Tue, 08 Nov 2005 18:27:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13354 for ; Tue, 8 Nov 2005 18:26:42 -0500 (EST) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZd7m-0004UN-Rs for hipsec@ietf.org; Tue, 08 Nov 2005 18:43:35 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id AC6E92E87; Wed, 9 Nov 2005 01:26:59 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.0-niksula20040914 (2005-09-13) on twilight.cs.hut.fi 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 530662E7C for ; Wed, 9 Nov 2005 01:26:59 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id jA8NQx309583; Wed, 9 Nov 2005 01:26:59 +0200 (EET) Date: Wed, 9 Nov 2005 01:26:58 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Hipsec] Re: jabber scribe 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Wed, 9 Nov 2005, Miika Komu wrote: > I'll be making a jabber scribe at the channel hip@private.jabber.org if > you are interested. Sorry, hip@ietf.xmpp.org -- 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 Tue Nov 08 19:04:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdSO-00034P-0T; Tue, 08 Nov 2005 19:04:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdSM-00034J-SY for hipsec@megatron.ietf.org; Tue, 08 Nov 2005 19:04:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17208 for ; Tue, 8 Nov 2005 19:04:24 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZdiG-00064m-7v for hipsec@ietf.org; Tue, 08 Nov 2005 19:21:17 -0500 Received: from cgn.ietf64.ietf.org (pp108-188.bctel.ca [209.52.108.188]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E2ACE1BAC4D for ; Wed, 9 Nov 2005 01:04:39 +0100 (CET) Date: Wed, 09 Nov 2005 01:04:19 +0100 From: Martin Stiemerling To: hipsec@ietf.org Message-ID: <17188321ABE188C78903231A@753F3B888A9969457862729D> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] HIP and NATs: IRTF Draft on this 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, While we are talking about HIP NAT traversal it is worth to take a look in the HIPRG draft on this: Middlebox Traversal Issues of Host Identity Protocol (HIP) Communication Martin _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Nov 08 19:25:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdmi-00077b-PY; Tue, 08 Nov 2005 19:25:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdmi-00076w-2j for hipsec@megatron.ietf.org; Tue, 08 Nov 2005 19:25:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25842 for ; Tue, 8 Nov 2005 19:25:25 -0500 (EST) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZe2b-0000mX-HM for hipsec@ietf.org; Tue, 08 Nov 2005 19:42:18 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 744A42E7C; Wed, 9 Nov 2005 02:25:41 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.0-niksula20040914 (2005-09-13) on twilight.cs.hut.fi 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 1A8622C98 for ; Wed, 9 Nov 2005 02:25:41 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id jA90Pe011281; Wed, 9 Nov 2005 02:25:40 +0200 (EET) Date: Wed, 9 Nov 2005 02:25:40 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Hipsec] HIP NAT implementation 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org During the WG session, the HIP NAT support was mentioned. I failed to mention that there is already one guy (Abhinav Pathak) implementing and experimenting with that in the infrahip project. He has already suggested some improvements to the PATH draft offline. -- 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 Nov 09 04:28:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZmFn-0004oQ-75; Wed, 09 Nov 2005 04:28:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZmFl-0004oL-OJ for hipsec@megatron.ietf.org; Wed, 09 Nov 2005 04:28:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24889 for ; Wed, 9 Nov 2005 04:27:57 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZmVk-00067K-EM for hipsec@ietf.org; Wed, 09 Nov 2005 04:44:56 -0500 Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id 7905D212C2D for ; Wed, 9 Nov 2005 11:27:56 +0200 (EET) From: Jan Mikael Melen To: hipsec@ietf.org Date: Wed, 9 Nov 2005 11:24:08 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_6AccDk+aRmdukDp" Message-Id: <200511091124.10329.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [Hipsec] Fwd: I-D ACTION:draft-nikander-esp-beet-mode-04.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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --Boundary-00=_6AccDk+aRmdukDp Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =2D--------- Forwarded Message ---------- Subject: I-D ACTION:draft-nikander-esp-beet-mode-04.txt Date: Wednesday 09 November 2005 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-04.txt Pages : 31 Date : 2005-11-8 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-04.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-04.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-04.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=_6AccDk+aRmdukDp Content-Type: Message/External-body; name="draft-nikander-esp-beet-mode-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-11-8155455.I-D@ietf.org> --Boundary-00=_6AccDk+aRmdukDp 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=_6AccDk+aRmdukDp-- From hipsec-bounces@lists.ietf.org Wed Nov 09 12:33:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtoi-0003kh-P7; Wed, 09 Nov 2005 12:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtod-0003ig-02 for hipsec@megatron.ietf.org; Wed, 09 Nov 2005 12:32:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24275 for ; Wed, 9 Nov 2005 12:32:28 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZu4e-0003B2-Eo for hipsec@ietf.org; Wed, 09 Nov 2005 12:49:30 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 79BD4788; Wed, 9 Nov 2005 18:32:49 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 18:29:39 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 18:29:39 +0100 Received: from [131.160.126.38] (rvi2-126-38.lmf.ericsson.se [131.160.126.38]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9BEB02836; Wed, 9 Nov 2005 19:29:36 +0200 (EET) Message-ID: <43723201.1050107@ericsson.com> Date: Wed, 09 Nov 2005 19:29:37 +0200 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2005 17:29:39.0118 (UTC) FILETIME=[297F44E0:01C5E553] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: David Ward Subject: [Hipsec] Slides and raw notes from yesterday 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, FYI: you can fetch the slides, raw notes, and jabber log from yesterday's meeting from: http://hip.piuha.net/meetings/ietf64/ Cheers, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Nov 09 13:49:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv0r-0007mr-8A; Wed, 09 Nov 2005 13:49:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv0p-0007me-SN; Wed, 09 Nov 2005 13:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29607; Wed, 9 Nov 2005 13:49:08 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvGs-0005du-RO; Wed, 09 Nov 2005 14:06:12 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8799B212C2D; Wed, 9 Nov 2005 20:49:14 +0200 (EET) 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 Date: Wed, 9 Nov 2005 10:49:10 -0800 To: Internet Area X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: HIP , ipv6@ietf.org Subject: [Hipsec] KHIs and SHA-256 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Internet Area , Pekka Nikander List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org [Cross-posted to HIP WG and IPv6 WG; replies _only_ to INT area please.] I'd like to direct people's attention to draft-laganier-ipv6- khi-00.txt at http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-00.txt Here is the abstract: This document introduces Keyed Hash Identifiers (KHI) as a new, experimental class of IPv6-address-lookalike identifiers. They are constructed to be statistically globally unique. They are intended to be used as identifiers only, and not as locators. They should not appear in actual IPv6 headers. Consequently, they are considered as non-routable addresses from the IPv6 point of view. These identifiers are expected to be used at the existing IPv6 API and application protocols between consenting hosts. They may be defined and used in different contexts, suitable for different protocols. Examples of these include Host Identity Tags (HIT) in the Host Identity Protocol (HIP) and Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Keyed Hash Identifiers. The basic question is whether we should go forward with it, and if so, where? Could we last call it at the Internet Area, as the IPv6 chairs indicate that they consider it a larger issue and not just IPv6 specific? I would also get people's opinion whether SHA-1 is OK for the document, as currently the proposed experiment is to end by 2009. According to the discussion at security directorate yesterday, SHA-1 is expected to be at the end of life by 2010. Consequently, for most security protocols there will be two transitions in the foreseeable future, first to SHA-256, and then to something that NIST may be getting to within the next five years or so. Hence, are we happy with going with (patched) SHA-1 with the expectation that the experiment will end by 2009, and will also become unsecure around the same time, or should we adopt SHA-256 from the beginning? See also the previous discussion at the IPv6 WG, starting at http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html --Pekka Nikander _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Nov 10 17:19:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKlw-0007f3-2K; Thu, 10 Nov 2005 17:19:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKlu-0007bX-CW for hipsec@megatron.ietf.org; Thu, 10 Nov 2005 17:19:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20386 for ; Thu, 10 Nov 2005 17:19:25 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaL2C-0006O8-QQ for hipsec@ietf.org; Thu, 10 Nov 2005 17:36:45 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2B63B212C2D for ; Fri, 11 Nov 2005 00:19:19 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: HIP From: Pekka Nikander Date: Thu, 10 Nov 2005 14:18:35 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Bellovin-Rescorla analysis needed 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, I am sitting in SAAG and it looks like that we need to do the Bellovin-Rescorla hash function analysis on HIP, before we submit it to the IESG. Otherwise we will just get a Discuss from the security ADs. I think we are fine with the actual hash function use, as we get the hash function from HITs, which get them from KHI, where the prefix defined the hash function. However, we may have problems with HMAC, SIG and SIG2 parameters. In theory, we are safe at least in the sense that we can assign new parameter values with different hash functions, but it might be some better way forward. http://www.cs.columbia.edu/~smb/papers/new-hash.pdf http://www.cs.columbia.edu/~smb/talks/talk-newhash-nist.pdf Any volunteers? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Nov 10 17:28:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKts-0000uv-5F; Thu, 10 Nov 2005 17:28:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKto-0000tr-Mb; Thu, 10 Nov 2005 17:28:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20771; Thu, 10 Nov 2005 17:27:35 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaLA6-0006ZK-0u; Thu, 10 Nov 2005 17:44:55 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jAAMRhR17814; Thu, 10 Nov 2005 23:27:43 +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 jAAMRi6V015702; Thu, 10 Nov 2005 23:27:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman In-reply-to: Your message of Thu, 10 Nov 2005 16:05:55 EST. Date: Thu, 10 Nov 2005 23:27:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org, Internet Area , Bob Hinden , HIP Subject: [Hipsec] Re: [Int-area] Re: KHIs and SHA-256 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org In your previous mail you wrote: My understanding is that these are not routable addresses. That is, they won't appear in routing protocol exchanges or routing tables. If that is the case, then we are talking about the allocation of something different than IPv6 addresses. => you are right: not only they are not routable but they should be easy to be recognized as not routable. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 14 00:51:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbXFV-000191-Uw; Mon, 14 Nov 2005 00:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZmDY-000480-0w for hipsec@megatron.ietf.org; Wed, 09 Nov 2005 04:26:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24809 for ; Wed, 9 Nov 2005 04:25:40 -0500 (EST) Received: from creon.otaverkko.fi ([213.15.142.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZmTW-00064h-Tm for hipsec@ietf.org; Wed, 09 Nov 2005 04:42:39 -0500 Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 2225B21AF44; Wed, 9 Nov 2005 11:25:40 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07837-02; Wed, 9 Nov 2005 11:25:31 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [213.15.142.70]) by creon.otaverkko.fi (Postfix) with ESMTP id 821DA21AF42; Wed, 9 Nov 2005 11:25:31 +0200 (EET) Received: from localhost (hydra.otaverkko.fi [213.15.142.72]) by argo.otaverkko.fi (Postfix) with ESMTP id 7C55F25ED06; Wed, 9 Nov 2005 11:25:31 +0200 (EET) Received: from delhi-203.200.95-130.vsnl.net.in (delhi-203.200.95-130.vsnl.net.in [203.200.95.130]) by webmail.hiit.fi (IMP) with HTTP for ; Wed, 09 Nov 2005 11:25:31 +0200 Message-ID: <1131528331.4371c08b71a05@webmail.hiit.fi> Date: Wed, 09 Nov 2005 11:25:31 +0200 From: Abhinav Pathak To: hipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 203.200.95.130 X-Virus-Scanned: amavisd-new at otaverkko.fi Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 14 Nov 2005 00:51:24 -0500 Cc: miika@ifi.ki.cnri.reston.va.us Subject: [Hipsec] Feedback - draft-nikander-hip-path.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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hello Below are my feedback for the draft-nikander-hip-path.txt. This was a mai= l to the authors of draft (some time back). Some of the changes have been incorporated and am working on the rest. I will be submitting soon a revi= sion of the draft. --abi Hello The implementation of this draft was stalled in May as we did not have a = working version of HIPL over IPv4 (the one we had is incomplete and uses hooks to= work things out). So we first finished the BEET patch and now working on getti= ng IPv4 support for HIPL (using BEET) and then there would be NAT traversal for i= t -- infact HIPL over ipv4 plus NAT traversal(between HIP initiator and HIP responder) is my bachelors' thesis at IIT Kanpur http://home.iitk.ac.in/~abpathak/acads.html . I worked on the draft a bit in May to get the UDP-REA and S-UDP-REA param= eter to go along with base exchange, and thus NAT detection was done then. But as= there was no means of testing it out (ip6tables doesnt support NAT yet!!) we mo= ved on to BEET. Some Feedback about the draft: 1) One of the problems I faced about the draft, is that it tells to dynam= ically switch on/off UDP encapsulation for a particular conversation (depending = on NAT present or not). For this we need to make dynamic UDP encapsulation (prob= ably through the xfrm interface) in the kernel -- this is from linux kernel po= int of view. This would be of particular interest in mobility scenarios. If a HIP clie= nt moves from behind NAT to outside it. Then there would be no need for UDP encapsulation. Also for a host behind a NAT needs UDP encap to talk to a server outside = NAT, but can talk without UDP encapsulation to a server inside the same NAT. So, I guess the draft should specify that there is a need for UDP encapsu= lation to be defined per SA/SP basis (this is what we plan to do). 2) As per discussion with Julien Laganier in May, there was some confusio= n with Length field in (S)UDP-REA parameters. An excerpt from his mail (reply) s= ays that there is some problem with a figure > > > 1. In UDP-REA and SUDP-REA Parameter, what does the length > > > field represent. Length of the (S)UDP-REA Parameter (as a > > > whole) or length of the whole of the packet (which should not > > > be according to me as, if the packet is encapsulated in with > > > UDP Encapsulation, then that UDP header should have the length > > > of the packet as a whole). ( The draft states : Length (2 > > > bytes) represents length in Octets, excluding type and length > > > fields). > > > > My understanding is that the Length denotes the length of the > > whole parameter. So UDP-REA is 4 + hash_length + > > padding_to_64bits octets long and S-UDP-REA is 4 + 2 + 2 + 2 * > > addr_size + padding_to_64bits octets. > > Why do we need padding in the SUDP_REA Parameter? The draft says > that there is no padding in it. I get confused between the real length and what's in the length field, which doesn't include the padding. Let me quote the hip-base draft: ----- All the TLV parameters have a length (including Type and Length fields) which is a multiple of 8 bytes. When needed, padding MUST be added to the end of the parameter so that the total length becomes a multiple of 8 bytes. This rule ensures proper alignment of data. If padding is added, the Length field MUST NOT include the padding. Any added padding bytes MUST be set zero by the sender, but their content SHOULD NOT be checked on the receiving end. ----- So I think that while the complete length would be as I said before, the padding isn't included in the computation of the Length field, so the lenth is 4 + hash_length for UDP-REA and 4 + 2 + 2 + 2 * addr_size for S-UDP-REA. So IMHO that means there's an error in the S-UDP-REA figure. Should have been like below (because we need to be 64 bits aligned): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Lifetime |T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Source Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Destination Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tnx. --julien IMHO the length parameter should be defined some what more explicitly. 3) We need to define a port number on which to recieve the UDP (with HIP) packets on so that we can differentiate them from other UDP traffic and t= o make a listner on both client and server on that port. (we were using 4500 (us= ed for standard NAT traversal by kame/racoon) if i remember properly). 4) There are some statements which are I think need a bit more reasoning = like a. An integration with STUN and TURN would not add more security to the p= rotocol exchange. (page 3) b. It MUST be ensured that the total length (including padding) of the UD= P-REA parameter is 11 + Length - (Length + 3) % 8 (page 3) 5) Some grammatical corrections -- excerpt from my mail to the authors of= draft in May Besides these, there are some spelling errors, and some gramatical mistak= es which are mentioned below. a. Page 3 : 3rd line. should be Firewalls are present. Instead of Firewal= ls are presents. b. Page 6 : 4th para. 3rd line, the word particularly is repeated twice. c. Page 10 : 3rd point in further information for message handling. 3rd l= ine, the is repeated twice. d. Page 11 : 1st para, It is mentioned twice that the HIP Initiator is be= hind the NAT. e. Page 3: In introduction "The client obviously needs to support the cli= de part of the protocol as well" . CLIDE is something not clear to me. I will be implementing this draft from January onwards when we will have = hipl over ipv4 ready. Please mail me back for further clarifications/comments. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 14 00:51:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbXFW-00019Q-6e; Mon, 14 Nov 2005 00:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZmJO-0005NT-SH for hipsec@megatron.ietf.org; Wed, 09 Nov 2005 04:32:10 -0500 Received: from creon.otaverkko.fi (creon.otaverkko.fi [213.15.142.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25027 for ; Wed, 9 Nov 2005 04:31:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 8EC1921AF45 for ; Wed, 9 Nov 2005 11:31:38 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07559-09; Wed, 9 Nov 2005 11:31:33 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [213.15.142.70]) by creon.otaverkko.fi (Postfix) with ESMTP id F377421AF42 for ; Wed, 9 Nov 2005 11:31:32 +0200 (EET) Received: from localhost (hydra.otaverkko.fi [213.15.142.72]) by argo.otaverkko.fi (Postfix) with ESMTP id EE3EE25ED06 for ; Wed, 9 Nov 2005 11:31:32 +0200 (EET) Received: from delhi-203.200.95-130.vsnl.net.in (delhi-203.200.95-130.vsnl.net.in [203.200.95.130]) by webmail.hiit.fi (IMP) with HTTP for ; Wed, 09 Nov 2005 11:31:32 +0200 Message-ID: <1131528692.4371c1f4e6c89@webmail.hiit.fi> Date: Wed, 09 Nov 2005 11:31:32 +0200 From: Abhinav Pathak To: hipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 203.200.95.130 X-Virus-Scanned: amavisd-new at otaverkko.fi Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 14 Nov 2005 00:51:24 -0500 Cc: Subject: [Hipsec] Feedback - draft-nikander-hip-path.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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hello Below are my feedback for the draft-nikander-hip-path.txt. This was a mail to the authors of draft (some time back). Some of the changes have been incorporated and am working on the rest. I will be submitting soon a revision of the draft. --abi Hello The implementation of this draft was stalled in May as we did not have a working version of HIPL over IPv4 (the one we had is incomplete and uses hooks to work things out). So we first finished the BEET patch and now working on getting IPv4 support for HIPL (using BEET) and then there would be NAT traversal for it -- infact HIPL over ipv4 plus NAT traversal(between HIP initiator and HIP responder) is my bachelors' thesis at IIT Kanpur http://home.iitk.ac.in/~abpathak/acads.html . I worked on the draft a bit in May to get the UDP-REA and S-UDP-REA parameter to go along with base exchange, and thus NAT detection was done then. But as there was no means of testing it out (ip6tables doesnt support NAT yet!!) we moved on to BEET. Some Feedback about the draft: 1) One of the problems I faced about the draft, is that it tells to dynamically switch on/off UDP encapsulation for a particular conversation (depending on NAT present or not). For this we need to make dynamic UDP encapsulation (probably through the xfrm interface) in the kernel -- this is from linux kernel point of view. This would be of particular interest in mobility scenarios. If a HIP client moves from behind NAT to outside it. Then there would be no need for UDP encapsulation. Also for a host behind a NAT needs UDP encap to talk to a server outside NAT, but can talk without UDP encapsulation to a server inside the same NAT. So, I guess the draft should specify that there is a need for UDP encapsulation to be defined per SA/SP basis (this is what we plan to do). 2) As per discussion with Julien Laganier in May, there was some confusion with Length field in (S)UDP-REA parameters. An excerpt from his mail (reply) says that there is some problem with a figure > > > 1. In UDP-REA and SUDP-REA Parameter, what does the length > > > field represent. Length of the (S)UDP-REA Parameter (as a > > > whole) or length of the whole of the packet (which should not > > > be according to me as, if the packet is encapsulated in with > > > UDP Encapsulation, then that UDP header should have the length > > > of the packet as a whole). ( The draft states : Length (2 > > > bytes) represents length in Octets, excluding type and length > > > fields). > > > > My understanding is that the Length denotes the length of the > > whole parameter. So UDP-REA is 4 + hash_length + > > padding_to_64bits octets long and S-UDP-REA is 4 + 2 + 2 + 2 * > > addr_size + padding_to_64bits octets. > > Why do we need padding in the SUDP_REA Parameter? The draft says > that there is no padding in it. I get confused between the real length and what's in the length field, which doesn't include the padding. Let me quote the hip-base draft: ----- All the TLV parameters have a length (including Type and Length fields) which is a multiple of 8 bytes. When needed, padding MUST be added to the end of the parameter so that the total length becomes a multiple of 8 bytes. This rule ensures proper alignment of data. If padding is added, the Length field MUST NOT include the padding. Any added padding bytes MUST be set zero by the sender, but their content SHOULD NOT be checked on the receiving end. ----- So I think that while the complete length would be as I said before, the padding isn't included in the computation of the Length field, so the lenth is 4 + hash_length for UDP-REA and 4 + 2 + 2 + 2 * addr_size for S-UDP-REA. So IMHO that means there's an error in the S-UDP-REA figure. Should have been like below (because we need to be 64 bits aligned): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Lifetime |T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Source Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Destination Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tnx. --julien IMHO the length parameter should be defined some what more explicitly. 3) We need to define a port number on which to recieve the UDP (with HIP) packets on so that we can differentiate them from other UDP traffic and to make a listner on both client and server on that port. (we were using 4500 (used for standard NAT traversal by kame/racoon) if i remember properly). 4) There are some statements which are I think need a bit more reasoning like a. An integration with STUN and TURN would not add more security to the protocol exchange. (page 3) b. It MUST be ensured that the total length (including padding) of the UDP-REA parameter is 11 + Length - (Length + 3) % 8 (page 3) 5) Some grammatical corrections -- excerpt from my mail to the authors of draft in May Besides these, there are some spelling errors, and some gramatical mistakes which are mentioned below. a. Page 3 : 3rd line. should be Firewalls are present. Instead of Firewalls are presents. b. Page 6 : 4th para. 3rd line, the word particularly is repeated twice. c. Page 10 : 3rd point in further information for message handling. 3rd line, the is repeated twice. d. Page 11 : 1st para, It is mentioned twice that the HIP Initiator is behind the NAT. e. Page 3: In introduction "The client obviously needs to support the clide part of the protocol as well" . CLIDE is something not clear to me. I will be implementing this draft from January onwards when we will have hipl over ipv4 ready. Please mail me back for further clarifications/comments. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 14 00:51:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbXFW-00019p-GJ; Mon, 14 Nov 2005 00:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFVq-0008Ny-Th; Thu, 10 Nov 2005 11:42:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15500; Thu, 10 Nov 2005 11:42:30 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFm5-0007f6-Ak; Thu, 10 Nov 2005 11:59:46 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAAGeAtK016536; Thu, 10 Nov 2005 18:40:12 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Nov 2005 18:42:54 +0200 Received: from [209.52.107.220] ([10.241.58.93]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Nov 2005 18:42:54 +0200 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: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Thu, 10 Nov 2005 08:42:52 -0800 To: Internet Area , Pekka Nikander X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 10 Nov 2005 16:42:54.0272 (UTC) FILETIME=[CC177C00:01C5E615] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Nov 2005 00:51:24 -0500 Cc: HIP , ipv6@ietf.org Subject: [Hipsec] Re: KHIs and SHA-256 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Pekka, On Nov 9, 2005, at 10:49 AM, ext Pekka Nikander wrote: > > The basic question is whether we should go forward with it, and if > so, where? > Could we last call it at the Internet Area, as the IPv6 chairs > indicate that they consider it a larger issue and not just IPv6 > specific? While I do think there are larger issues here, since this proposes an allocation of IPv6 addresses I think it is important that the IPv6 working group review it. It would be good to talk to the Internet ADs to figure out the best way forward (e.g., where to last call it, etc.). Thanks, Bob > I would also get people's opinion whether SHA-1 is OK for the > document, as currently the proposed experiment is to end by 2009. > According to the discussion at security directorate yesterday, > SHA-1 is expected to be at the end of life by 2010. Consequently, > for most security protocols there will be two transitions in the > foreseeable future, first to SHA-256, and then to something that > NIST may be getting to within the next five years or so. Hence, > are we happy with going with (patched) SHA-1 with the expectation > that the experiment will end by 2009, and will also become unsecure > around the same time, or should we adopt SHA-256 from the beginning? > > See also the previous discussion at the IPv6 WG, starting at > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html > > --Pekka Nikander > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 14 00:51:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbXFW-0001AE-Qw; Mon, 14 Nov 2005 00:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJcv-00069d-9i; Thu, 10 Nov 2005 16:06:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08788; Thu, 10 Nov 2005 16:06:04 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaJtC-0001iA-1L; Thu, 10 Nov 2005 16:23:23 -0500 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.7558121; Thu, 10 Nov 2005 16:05:56 -0500 In-Reply-To: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> References: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Date: Thu, 10 Nov 2005 16:05:55 -0500 To: Bob Hinden X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-Mailman-Approved-At: Mon, 14 Nov 2005 00:51:24 -0500 Cc: ipv6@ietf.org, Internet Area , HIP Subject: [Hipsec] Re: KHIs and SHA-256 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: , Content-Type: multipart/mixed; boundary="===============0357626556==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============0357626556== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-878217170; protocol="application/pkcs7-signature" --Apple-Mail-7-878217170 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit My understanding is that these are not routable addresses. That is, they won't appear in routing protocol exchanges or routing tables. If that is the case, then we are talking about the allocation of something different than IPv6 addresses. Regards, Brian On Nov 10, 2005, at 11:42, Bob Hinden wrote: > Pekka, > > On Nov 9, 2005, at 10:49 AM, ext Pekka Nikander wrote: >> >> The basic question is whether we should go forward with it, and if >> so, where? >> Could we last call it at the Internet Area, as the IPv6 chairs >> indicate that they consider it a larger issue and not just IPv6 >> specific? > > While I do think there are larger issues here, since this proposes an > allocation of IPv6 addresses I think it is important that the IPv6 > working group review it. It would be good to talk to the Internet ADs > to figure out the best way forward (e.g., where to last call it, > etc.). > > Thanks, > Bob > > >> I would also get people's opinion whether SHA-1 is OK for the >> document, as currently the proposed experiment is to end by 2009. >> According to the discussion at security directorate yesterday, SHA-1 >> is expected to be at the end of life by 2010. Consequently, for most >> security protocols there will be two transitions in the foreseeable >> future, first to SHA-256, and then to something that NIST may be >> getting to within the next five years or so. Hence, are we happy >> with going with (patched) SHA-1 with the expectation that the >> experiment will end by 2009, and will also become unsecure around the >> same time, or should we adopt SHA-256 from the beginning? >> >> See also the previous discussion at the IPv6 WG, starting at >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html >> >> --Pekka Nikander >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-7-878217170 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTEwMjEwNTU2WjAjBgkqhkiG9w0B CQQxFgQU64E3f6sPtiKyzdr9SzOb0YNbPBUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAt7ac5zXNeEQQazfrYQzxzzm2HL9NwYSvK2bi0g3Sc+eZ3nYSY584tW5FGpXPF8+C1uR7 vqPxOc7+m2UrIiDI5wGHJxCR0JfgBghApMnIsBbJ7ymOpzjKxTXwASxAY306QE84RpDkuyPIfqWB JEi1Wyli3ydw/aBV0yXERmHhJSfnjKKuLX6RPTS1TL19ApcN14ojp+dE+mPd9HVAR4nBPn2Z74U1 XQ1yPUdRY5M2PFDmZJesUhNhenYFPAuGQh4PwoNRBUFY8UdgQFPZL/kCT92mCkmZZjg7y3ZGp6tU O/6EG/evYx3loLF86qt0wQIlQlLCunK3n11bGyiDS1B5agAAAAAAAA== --Apple-Mail-7-878217170-- --===============0357626556== 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 --===============0357626556==-- From hipsec-bounces@lists.ietf.org Mon Nov 14 00:51:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbXFX-0001Ad-6b; Mon, 14 Nov 2005 00:51:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8eM-00054X-OZ; Sat, 12 Nov 2005 22:35:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09122; Sat, 12 Nov 2005 22:34:57 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb8v5-00021m-Rx; Sat, 12 Nov 2005 22:52:45 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAD3YSXt003925; Sun, 13 Nov 2005 14:34:30 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051112224023.02d80718@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 12 Nov 2005 22:41:07 +1100 To: Francis Dupont , Brian Haberman From: Geoff Huston In-Reply-To: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.4 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Mon, 14 Nov 2005 00:51:24 -0500 Cc: Internet Area , ipv6@ietf.org, HIP Subject: [Hipsec] Re: [Int-area] Re: KHIs and SHA-256 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org At 09:27 AM 11/11/2005, Francis Dupont wrote: > In your previous mail you wrote: > > My understanding is that these are not routable addresses. That is, > they won't appear in routing protocol exchanges or routing tables. > If that is the case, then we are talking about the allocation of > something different than IPv6 addresses. > >=> you are right: not only they are not routable but they should >be easy to be recognized as not routable. +1 Geoff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Nov 18 07:44:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5br-0006j6-Oc; Fri, 18 Nov 2005 07:44:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5bq-0006ix-Mw for hipsec@megatron.ietf.org; Fri, 18 Nov 2005 07:44:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14815 for ; Fri, 18 Nov 2005 07:44:19 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed5tf-0006pQ-Ir for hipsec@ietf.org; Fri, 18 Nov 2005 08:03:20 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9696A212C44; Fri, 18 Nov 2005 14:44:33 +0200 (EET) Message-ID: <437DCCB0.6090703@nomadiclab.com> Date: Fri, 18 Nov 2005 14:44:32 +0200 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Bellovin-Rescorla analysis needed References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Pekka Nikander wrote: > Folks, > > I am sitting in SAAG and it looks like that we need to do the > Bellovin-Rescorla hash function analysis on HIP, before we submit it to > the IESG. Otherwise we will just get a Discuss from the security ADs. ... > Any volunteers? How shall we proceed with this issue? Are there any people who can make the analysis? /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Nov 18 09:24:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed7Af-0000Qm-AX; Fri, 18 Nov 2005 09:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed7Ac-0000Dq-DP for hipsec@megatron.ietf.org; Fri, 18 Nov 2005 09:24:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20486 for ; Fri, 18 Nov 2005 09:24:18 -0500 (EST) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed7SR-0001dB-RW for hipsec@ietf.org; Fri, 18 Nov 2005 09:43:21 -0500 Received: from [192.168.0.119] (cs181091098.pp.htv.fi [82.181.91.98]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 18 Nov 2005 16:24:45 +0200 id 000700D3.437DE42D.000008D9 Message-ID: <437DE40B.8030108@cs.helsinki.fi> Date: Fri, 18 Nov 2005 16:24:11 +0200 From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en Mime-Version: 1.0 To: Jan Mikael Melen Subject: Re: [Hipsec] Fwd: I-D ACTION:draft-nikander-esp-beet-mode-04.txt References: <200511091124.10329.Jan.Melen@nomadiclab.com> In-Reply-To: <200511091124.10329.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: hipsec@ietf.org 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: , Content-Type: multipart/mixed; boundary="===============0641337816==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0641337816== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="=_courier-2265-1132323885-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-2265-1132323885-0001-2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I read the draft. It's nice but here are some minor nits Search for -Figure Figure -concent -ows Currently it's a mix of UK and US spelling, such as signaling but behaviour. Check the use of articles, especially with "inner IP header" Period missing after to be increased strategical -> strategic For case below, integrity protection should cover whole dst options. AFTER APPLYING ESP, OUTER v6 ADDRESSES In acks "the author" should be authors McGrecor -> McGregor Andrei Jan Mikael Melen wrote: >---------- Forwarded Message ---------- > >Subject: I-D ACTION:draft-nikander-esp-beet-mode-04.txt >Date: Wednesday 09 November 2005 01: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 : A Bound End-to-End Tunnel (BEET) mode for ESP > Author(s) : J. Melen, P. Nikander > Filename : draft-nikander-esp-beet-mode-04.txt > Pages : 31 > Date : 2005-11-8 > >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-04.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-04.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-04.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 > > --=_courier-2265-1132323885-0001-2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTExODE0MjQxMVowIwYJ KoZIhvcNAQkEMRYEFCbp5sW6VoqV1K81Pk/ZDhNcKEaCMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMOjtkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMA0GCSqGSIb3DQEBAQUA BIIBAK9J1Fks15VmJl9LpDulfhJGbuMiKUQfDpoRB3hWk4fQ1gXdv1nulcsSmA0ywkRDeW9x LAwQdZvM4na5yvVvoHVVmuSYImineZQhh1RCQUGqo4GSpOhVW2dwoI8P3agbJIzw3cOfe95b kSYe5271d/fLVzJRokR7Wwg2ZbvxY/ZLekev5Lmvr0UygUIQXudkAULtiTx2U+R3TO2CtPbZ YijRlVUcg08RyjVVbYacU7oYQOm6FjHi8rtg6iCQ+r+j9/W97KrJQ6THShT4b5Ku/3wSR/Wo a/Kx6F1RI6Xqgpit9hVB4vuhWTceBBge/fcjHWNrQFyBlWWHvNfZTt8aEgwAAAAAAAA= --=_courier-2265-1132323885-0001-2-- --===============0641337816== 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 --===============0641337816==-- From hipsec-bounces@lists.ietf.org Sun Nov 27 07:44:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgLtN-0007Vf-Q2; Sun, 27 Nov 2005 07:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgLtM-0007Va-Rd for hipsec@megatron.ietf.org; Sun, 27 Nov 2005 07:44:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08933 for ; Sun, 27 Nov 2005 07:43:45 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgMCu-0002A1-2H for hipsec@ietf.org; Sun, 27 Nov 2005 08:04:45 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 44CAC12E7; Sun, 27 Nov 2005 13:44:07 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Nov 2005 13:44:07 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Nov 2005 13:44:06 +0100 Received: from [131.160.126.55] (rvi2-126-55.lmf.ericsson.se [131.160.126.55]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9DF2B2922; Sun, 27 Nov 2005 14:44:06 +0200 (EET) Message-ID: <4389AA15.4010706@ericsson.com> Date: Sun, 27 Nov 2005 14:44:05 +0200 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2005 12:44:06.0987 (UTC) FILETIME=[416309B0:01C5F350] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: David Ward Subject: [Hipsec] Draft minutes of IETF 64 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, here you have the draft minutes from our last face-to-face meeting in Canada. http://hip.piuha.net/meetings/ietf64/notes/minutes-hip-ietf64.txt Let us know if you have any comments. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec