From hipsec-bounces@lists.ietf.org Fri Sep 02 05:18:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB7gO-00073w-16; Fri, 02 Sep 2005 05:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB7gM-00073r-8g for hipsec@megatron.ietf.org; Fri, 02 Sep 2005 05:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25049 for ; Fri, 2 Sep 2005 05:17:55 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB7iS-0002VF-Hq for hipsec@ietf.org; Fri, 02 Sep 2005 05:20:09 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 876D1212C91; Fri, 2 Sep 2005 12:17:37 +0300 (EEST) Message-ID: <431818AF.808@nomadiclab.com> Date: Fri, 02 Sep 2005 12:17:35 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Base draft & ESP draft: snapshots References: <1124111403.10041.10.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 A new pre-version of the ESP draft is now out: draft-ietf-hip-esp-01-pre020905.* http://hip4inter.net/drafts.php Pekka Nikander wrote: >> draft-ietf-hip-esp-01-pre150805 > More substantial: > > I am a little bit worried about the BEET reference; it appears in a > pretty normative context even though it is listed as an informative > reference. Consequently, I think it would be best to partially rewrite > 3.2. First name it "Conceptual ESP packet processing", to make it > clearer that the text is more illustrative than normative. Then take > the last paragraph ("fully standards compatible IPsec") as the starting > point, and explain how packets are processed if that is the case, and > finally use BEET as a way to illustrate an alternative way to implement > it. Section 6 appears to be fine from this point of view. I rewrote section 3.2. Please see if it is better now. > This doesn't really matter, but I would find it slightly more appealing > if it was 4095... I changed it. Implementors, please change it before next interop to avoid extra confusion ;-) /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 02 05:45:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB86v-0001Dn-8Y; Fri, 02 Sep 2005 05:45:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB86r-0001CK-H8 for hipsec@megatron.ietf.org; Fri, 02 Sep 2005 05:45:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25919 for ; Fri, 2 Sep 2005 05:45:19 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB88z-0003Pg-PE for hipsec@ietf.org; Fri, 02 Sep 2005 05:47:34 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 52699212C91; Fri, 2 Sep 2005 12:45:12 +0300 (EEST) In-Reply-To: <431818AF.808@nomadiclab.com> References: <1124111403.10041.10.camel@localhost.localdomain> <431818AF.808@nomadiclab.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 Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Fri, 2 Sep 2005 11:45:11 +0200 To: Petri Jokela X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > I rewrote section 3.2. Please see if it is better now. Looks very good, thanks! I'd remove the last sentence "This mode of operation ... ESP tunnel mode." as irrelevant and potentially confusing. Minor comments: hip-arch is now at -03. [6] (hip-mm) should be informative to avoid normative dependency. The context of the reference is informative. [7] is not referenced at all; could be removed? is [10] (Schneier) really normative? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 02 06:05:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB8QQ-0002pH-3h; Fri, 02 Sep 2005 06:05:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB8QO-0002oj-GA for hipsec@megatron.ietf.org; Fri, 02 Sep 2005 06:05:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26609 for ; Fri, 2 Sep 2005 06:05:30 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB8SV-00044d-L5 for hipsec@ietf.org; Fri, 02 Sep 2005 06:07:45 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EB8QL-0007nH-Iz for hipsec@ietf.org; Fri, 02 Sep 2005 06:05:29 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3171E212C91; Fri, 2 Sep 2005 12:59:56 +0300 (EEST) Message-ID: <4318229A.7030804@nomadiclab.com> Date: Fri, 02 Sep 2005 12:59:54 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Base draft & ESP draft: snapshots References: <1124111403.10041.10.camel@localhost.localdomain> <431818AF.808@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Pekka Nikander wrote: >> I rewrote section 3.2. Please see if it is better now. > > > Looks very good, thanks! > > I'd remove the last sentence "This mode of operation ... ESP tunnel > mode." as irrelevant and potentially confusing. Ok. > Minor comments: > > hip-arch is now at -03. I still have old xml reference files locally. I'll update them. > [6] (hip-mm) should be informative to avoid normative dependency. The > context of the reference is informative. Yes, true. > [7] is not referenced at all; could be removed? Yes, the algorithms are now in a separate draft. > is [10] (Schneier) really normative? The suite-IDs, defined in 5.1.2, are from [8] and [10]. If I remember correctly, BLOWFISH was from Schneiner and rest of the suites were from [8]. This is the reason why I put it as a normative reference. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 02 22:51:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBO8E-0008KK-CI; Fri, 02 Sep 2005 22:51:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBO8C-0008KF-EX for hipsec@megatron.ietf.org; Fri, 02 Sep 2005 22:51:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25486 for ; Fri, 2 Sep 2005 22:51:45 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBOAQ-00079J-SU for hipsec@ietf.org; Fri, 02 Sep 2005 22:54:09 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1D734212CA9 for ; Sat, 3 Sep 2005 05:51:26 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <803A0BB5-4211-47EC-AC44-1D4F3EE2F5F7@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: hipsec@ietf.org From: Pekka Nikander Date: Sat, 3 Sep 2005 04:51:23 +0200 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] A new draft on the proposed unified HIT format 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 FYI. This draft should be discussed in the ipv6 ML. Any HIP- specific issues, like the incompatibility (CID) introduced w.r.t. the current base spec should be discussed here. --Pekka From: Internet-Drafts@ietf.org Date: September 3, 2005 0:50:01 GMT+02:00 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-laganier-ipv6-khi-00.txt Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Non-Routable IPv6 Prefix for Keyed Hash Identifiers (KHI) Author(s) : P. Nikander, et al. Filename : draft-laganier-ipv6-khi-00.txt Pages : 9 Date : 2005-9-2 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-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-laganier-ipv6-khi-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-laganier-ipv6-khi-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. Content-Type: text/plain Content-ID: <2005-9-2163557.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Sep 03 04:27:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBTNK-0003Bn-35; Sat, 03 Sep 2005 04:27:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8l45-0005b1-OV for hipsec@megatron.ietf.org; Fri, 26 Aug 2005 16:44:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21677 for ; Fri, 26 Aug 2005 16:44:39 -0400 (EDT) Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8l4r-0006qs-W7 for hipsec@ietf.org; Fri, 26 Aug 2005 16:45:31 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 08F4CC295 for ; Fri, 26 Aug 2005 16:44:25 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j7QKiNGT010178 for ; Fri, 26 Aug 2005 16:44:24 -0400 (EDT) Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j7QKiLL6024020 for ; Fri, 26 Aug 2005 16:44:23 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j7QKhPKe023150 for ; Fri, 26 Aug 2005 16:43:25 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id A8DCC4FDA3; Fri, 26 Aug 2005 16:40:51 -0400 (EDT) Date: Fri, 26 Aug 2005 16:40:51 -0400 From: Wesley Eddy To: hipsec@ietf.org Message-ID: <20050826204051.GA10639@grc.nasa.gov> Mime-Version: 1.0 User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Sat, 03 Sep 2005 04:27:44 -0400 Cc: Subject: [Hipsec] dns extensions X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov 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="===============1488982448==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============1488982448== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Are any implementations (bind patches, etc) available supporting the HIP DNS extensions for HIPHI and HIPRVS RRs and QTYPEs? -Wes --=20 Wesley M. Eddy Verizon FNS / NASA GRC http://roland.grc.nasa.gov/~weddy --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDD35TzBuYqbnj3IwRAv+SAJ9rgL6q/5xU+KkOU5OOihORLfYNiwCfTMld YSgEG4K1saO2jilz/I6f+c0= =0izU -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- --===============1488982448== 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 --===============1488982448==-- From hipsec-bounces@lists.ietf.org Tue Sep 06 10:05:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECe4c-0005Y9-88; Tue, 06 Sep 2005 10:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECe4b-0005Y0-En for hipsec@megatron.ietf.org; Tue, 06 Sep 2005 10:05:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28749 for ; Tue, 6 Sep 2005 10:05:15 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECe7V-00068D-Az for hipsec@ietf.org; Tue, 06 Sep 2005 10:08:22 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA12038; Tue, 6 Sep 2005 07:04:55 -0700 (PDT) Received: from XCH-NWBH-10.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 j86E4tS09501; Tue, 6 Sep 2005 09:04:55 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Sep 2005 07:04:48 -0700 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] dns extensions Date: Tue, 6 Sep 2005 07:04:48 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D512C10@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] dns extensions Thread-Index: AcWwYaw++4FwpImLQsiPx6WZn2hJ3QCifNmw From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 06 Sep 2005 14:04:49.0046 (UTC) FILETIME=[F19B1B60:01C5B2EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 I do not know of any-- I think the public implementations mainly use /etc/hosts files. =20 Tom > -----Original Message----- > From: Wesley Eddy [mailto:weddy@grc.nasa.gov]=20 > Sent: Friday, August 26, 2005 1:41 PM > To: hipsec@ietf.org > Subject: [Hipsec] dns extensions >=20 > Are any implementations (bind patches, etc) available=20 > supporting the HIP DNS extensions for HIPHI and HIPRVS RRs and QTYPEs? >=20 > -Wes >=20 > -- > Wesley M. Eddy > Verizon FNS / NASA GRC > http://roland.grc.nasa.gov/~weddy >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 06 10:45:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECehQ-0004gV-BM; Tue, 06 Sep 2005 10:45:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECehO-0004gQ-03 for hipsec@megatron.ietf.org; Tue, 06 Sep 2005 10:45:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01736 for ; Tue, 6 Sep 2005 10:45:19 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECekG-0007E2-HL for hipsec@ietf.org; Tue, 06 Sep 2005 10:48:27 -0400 Received: from [192.168.1.105] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 431C638C00094DDE; Tue, 6 Sep 2005 16:44:46 +0200 From: Julien Laganier To: weddy@grc.nasa.gov Subject: Re: [Hipsec] dns extensions Date: Tue, 6 Sep 2005 16:45:57 +0200 User-Agent: KMail/1.8 References: <77F357662F8BFA4CA7074B0410171B6D512C10@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512C10@XCH-NW-5V1.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: <200509061645.58000.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 On Tuesday 06 September 2005 16:04, Henderson, Thomas R wrote: > I do not know of any-- I think the public implementations mainly > use /etc/hosts files. With djbdns , an alternative DNS server, you can easily defines new RRs; the syntax to use to feed the tinydns-data program is: :fqdn:n:rdata:ttl:timestamp:lo where r is the RR type and rdata the RR itself, which can include octal \nnn codes. A simple program should do the trick of converting the /etc/hosts Tom mentionned into the above representation thant can be fed to tinydns-data. As for the resolver part, I think someone needs to hack it ;) --julien > > -----Original Message----- > > From: Wesley Eddy [mailto:weddy@grc.nasa.gov] > > Sent: Friday, August 26, 2005 1:41 PM > > To: hipsec@ietf.org > > Subject: [Hipsec] dns extensions > > > > Are any implementations (bind patches, etc) available > > supporting the HIP DNS extensions for HIPHI and HIPRVS RRs and > > QTYPEs? > > > > -Wes > > > > -- > > Wesley M. Eddy > > Verizon FNS / NASA GRC > > http://roland.grc.nasa.gov/~weddy > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec -- julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 06 13:35:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChLa-0006ez-JS; Tue, 06 Sep 2005 13:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChLZ-0006ei-12 for hipsec@megatron.ietf.org; Tue, 06 Sep 2005 13:35:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09259 for ; Tue, 6 Sep 2005 13:35:00 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EChOY-0003FD-Jo for hipsec@ietf.org; Tue, 06 Sep 2005 13:38:07 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id D86D0243 for ; Tue, 6 Sep 2005 13:34:41 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2F6E641B6 for ; Tue, 6 Sep 2005 13:34:41 -0400 (EDT) Date: Tue, 06 Sep 2005 13:34:41 -0400 From: Rob Austein To: hipsec@ietf.org Subject: Re: [Hipsec] dns extensions In-Reply-To: <20050826204051.GA10639@grc.nasa.gov> References: <20050826204051.GA10639@grc.nasa.gov> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050906173441.2F6E641B6@thrintun.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 At Fri, 26 Aug 2005 16:40:51 -0400, weddy wrote: > > Are any implementations (bind patches, etc) available supporting the HIP > DNS extensions for HIPHI and HIPRVS RRs and QTYPEs? Any name server which supports RFC 3597 (eg, any recent version of BIND) can serve the HIP RR types. You'd have to encode them in the format described in RFC 3597, but that's a trivial perl hack. You won't get additional section processing that way, but I don't think the HIP RR formats need additional section processing anyway (very few RR types actually need additional section processing, mostly just the DNS infrastructure types). Similarly, one can query via any generic low-level resolver interface (res_nquery() or whatever). I haven't seen any patches for the HIP RR presentation formats or for a higher level resolution API. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 08 04:54:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDIAv-0000e2-Cr; Thu, 08 Sep 2005 04:54:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDIAu-0000dx-M1 for hipsec@megatron.ietf.org; Thu, 08 Sep 2005 04:54:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07969 for ; Thu, 8 Sep 2005 04:54:25 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDIED-0005Lk-Mf for hipsec@ietf.org; Thu, 08 Sep 2005 04:57:56 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 304FC212CE7 for ; Thu, 8 Sep 2005 11:54:06 +0300 (EEST) Message-ID: <431FFC2C.1000709@nomadiclab.com> Date: Thu, 08 Sep 2005 11:54:04 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Base draft and BSD 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 Hi, I uploaded a new version of the base draft to http://hip4inter.net/drafts.php (draft-ietf-hip-base-04-pre080905.xxx) Changes: The protocol number is now 253, according to RFC3692. The HIT definition refers now to the new KHI draft (draft-laganier-ipv6-khi-00). Jan uploaded also new versions of the HIP implementation for FreeBSD 5.4 and 6.0 (BETA). See download pages for these releases. Petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 08 09:13:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMDC-0007O1-Nu; Thu, 08 Sep 2005 09:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMD8-0007Nm-Cw for hipsec@megatron.ietf.org; Thu, 08 Sep 2005 09:13:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18690 for ; Thu, 8 Sep 2005 09:13:00 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDMGQ-0003Tg-HX for hipsec@ietf.org; Thu, 08 Sep 2005 09:16:32 -0400 Received: from [192.168.10.148] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 431C605C002D599D; Thu, 8 Sep 2005 15:12:35 +0200 From: Julien Laganier To: Petri Jokela , hipsec@ietf.org Subject: Re: [Hipsec] Base draft and BSD implementation Date: Thu, 8 Sep 2005 15:14:13 +0200 User-Agent: KMail/1.8 References: <431FFC2C.1000709@nomadiclab.com> In-Reply-To: <431FFC2C.1000709@nomadiclab.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_lkDIDNmO7p81T2A" Message-Id: <200509081514.13553.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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 --Boundary-00=_lkDIDNmO7p81T2A Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit On Thursday 08 September 2005 10:54, Petri Jokela wrote: > Hi, > > I uploaded a new version of the base draft to > > http://hip4inter.net/drafts.php > (draft-ietf-hip-base-04-pre080905.xxx) > > Changes: The protocol number is now 253, according to RFC3692. The > HIT definition refers now to the new KHI draft > (draft-laganier-ipv6-khi-00). Petri and others, I tentatively tried to adapt the base draft to reflect further the use of the KHI format for HIT. Attached is a proposal text (well, xml :) updating the sections: 3. Host Identifier (HI) and its Representations 3.1 Host Identity Tag (HIT) 3.2 Generating a HIT from a HI 9. IANA Considerations Appendix B. Generating a HIT from a HI Comments? Thanks. --julien --Boundary-00=_lkDIDNmO7p81T2A Content-Type: text/xml; charset="iso-8859-1"; name="khi-hit.xml" Content-Disposition: attachment; filename="khi-hit.xml" Content-Transfer-Encoding: 7bit
In this section, the properties of the Host Identifier and Host Identifier Tag are discussed, and the exact format for them is defined. In HIP, public key of an asymmetric key pair is used as the Host Identifier (HI). Correspondingly, the host itself is defined as the entity that holds the private key from the key pair. See the HIP architecture specification for more details about the difference between an identity and the corresponding identifier. HIP implementations MUST support the Rivest Shamir Adelman (RSA) public key algorithm, and SHOULD support the Digital Signature Algorithm (DSA) algorithm; other algorithms MAY be supported. A hashed encoding of the HI, the Host Identity Tag (HIT), is used in protocols to represent the Host Identity. The HIT is 128 bits long and has the following three key properties: i) it is the same length as an IPv6 address and can be used in address-sized fields in APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it is computationally hard to find a Host Identity key that matches the HIT), and iii) the probability of HIT collision between two hosts is very low. Carrying HIs and HITs in the header of user data packets would increase the overhead of packets. Thus, it is not expected that they are carried in every packet, but other methods are used to map the data packets to the corresponding HIs. In some cases, this makes it possible to use HIP without any additional headers in the user data packets. For example, if ESP is used to protect data traffic, the Security Parameter Index (SPI) carried in the ESP header, can be used to map the encrypted data packet to the correct HIP association.
The Host Identity Tag is a 128 bits long value -- a hashed encoding of the Host Identifier. There are two advantages of using a hashed encoding over the actual Host Identity public key in protocols. Firstly, its fixed length makes for easier protocol coding and also better manages the packet size cost of this technology. Secondly, it presents a consistent format to the protocol whatever underlying identity technology is used. "A Non-Routable IPv6 Prefix for Keyed Hash Identifiers" has been specified to store 128-bit hash based identifier called Keyed Hash Identifier (KHI) under an 8-bit prefix, proposed to be allocated from the IPv6 address block 1000::/4. The Host Identity Tag is a KHI valid for the Context ID value for HIP, 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (The tag value has been generated randomly by the editor of this specification.) The following figure shows, for informal purposes only, the format of a HIT specified by , and used in this document:
1 0 2 0 1 2 3 4 5 6 7 8 ... 7 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | Encoding | +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix (8 bits) - Fixed prefix, TBD (0x11, TO BE DISCUSSED), as defined per . Encoding (120 bits) - Encoding of the public key and KHI context identifier as defined per . Additional values for the prefix (including different hash algorithms, or other information) may be defined in the future. A host may receive a HIT for which it does not understand the prefix. In such a case, it will not be able to check the mapping between HI and HIT.
The HIT MUST be generated according to the KHI generation method described in using a context ID value of 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, and an input encoding the Host Identity field present in a HIP payload packet. For Identities that are either RSA or DSA public keys, this input consists of the public key encoding as specified in the corresponding DNSSEC document, taking the algorithm specific portion of the RDATA part of the KEY RR. There is currently only two defined public key algorithms: RSA and DSA. Hence, either of the following applies: The RSA public key is encoded as defined in RFC3110 Section 2, taking the exponent length (e_len), exponent (e) and modulus (n) fields concatenated. The length (n_len) of the modulus (n) can be determined from the total HI length (hi_len) and the preceding HI fields including the exponent (e). Thus, the data to be hashed has the same length as the HI (hi_len). The fields MUST be encoded in network byte order, as defined in RFC3110. The DSA public key is encoded as defined in RFC2536 Section 2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, where T is the size parameter as defined in RFC2536. The size parameter T, affecting the field lengths, MUST be selected as the minimum value that is long enough to accommodate P, G, and Y. The fields MUST be encoded in network byte order, as defined in RFC2536. In the public key encoding generation process is illustrated using pseudo-code.
The following pseudo-codes illustrate the process to generate a public key encoding from a HI for both RSA and DSA. The symbol := denotes assignment; the symbol += denotes appending. The pseudo-function encode_in_network_byte_order takes two parameters, an integer (bignum) and a length in bytes, and returns the integer encoded into a byte string of the given length.
switch ( HI.algorithm ) { case RSA: buffer := encode_in_network_byte_order ( HI.RSA.e_len, ( HI.RSA.e_len > 255 ) ? 3 : 1 ) buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) break; case DSA: buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 8 * HI.DSA.T ) buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 8 * HI.DSA.T ) buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 8 * HI.DSA.T ) break; }
This document defines a new 128-bit value under the CGA Message Type namespace , 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA.
--Boundary-00=_lkDIDNmO7p81T2A 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=_lkDIDNmO7p81T2A-- From hipsec-bounces@lists.ietf.org Fri Sep 09 02:02:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDby7-00017J-Gw; Fri, 09 Sep 2005 02:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDby5-000174-13 for hipsec@megatron.ietf.org; Fri, 09 Sep 2005 02:02:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00407 for ; Fri, 9 Sep 2005 02:02:30 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDc1Z-0006dK-5V for hipsec@ietf.org; Fri, 09 Sep 2005 02:06:10 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3E417212CE7; Fri, 9 Sep 2005 09:02:10 +0300 (EEST) Message-ID: <43212561.70008@nomadiclab.com> Date: Fri, 09 Sep 2005 09:02:09 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier Subject: Re: [Hipsec] Base draft and BSD implementation References: <431FFC2C.1000709@nomadiclab.com> <200509081514.13553.julien.IETF@laposte.net> In-Reply-To: <200509081514.13553.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Julien Laganier wrote: > On Thursday 08 September 2005 10:54, Petri Jokela wrote: > Petri and others, > > I tentatively tried to adapt the base draft to reflect further the use > of the KHI format for HIT. Attached is a proposal text (well, xml :) Thanks Julien! To make it easier to read, I made changes to the draft and put a new pre-version out. (Sorry for daily pre-releases, I hope it's not confusing :-) http://hip4inter.net/drafts.php The new version is: draft-ietf-hip-base-04-pre090905.xxx /Petri > updating the sections: > > 3. Host Identifier (HI) and its Representations > 3.1 Host Identity Tag (HIT) > 3.2 Generating a HIT from a HI > > 9. IANA Considerations > > Appendix B. Generating a HIT from a HI _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 09 03:39:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDdTy-0001Ai-9l; Fri, 09 Sep 2005 03:39:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDdTw-0001Aa-RJ for hipsec@megatron.ietf.org; Fri, 09 Sep 2005 03:39:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15200 for ; Fri, 9 Sep 2005 03:39:30 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDdXS-0000Sg-Rk for hipsec@ietf.org; Fri, 09 Sep 2005 03:43:12 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D779F212CE7; Fri, 9 Sep 2005 10:39:12 +0300 (EEST) In-Reply-To: <43212561.70008@nomadiclab.com> References: <431FFC2C.1000709@nomadiclab.com> <200509081514.13553.julien.IETF@laposte.net> <43212561.70008@nomadiclab.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 Subject: Re: [Hipsec] Base draft and BSD implementation Date: Fri, 9 Sep 2005 09:39:10 +0200 To: Petri Jokela X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 (I think daily updates are good :-) > The new version is: draft-ietf-hip-base-04-pre090905.xxx Looks good in general. Some minor suggestions: To Section 3.2, add a forward reference to Section 5.2.8 (HOST_ID). For RSA, either define what hi_len is or use the same terminology as in 5.2.8, i.e., HI Length. TODO later: Sections C.1 and C.3 should be updated to use the new HIT prefix once it has been settled. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 09 07:41:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDhGX-0006QN-8u; Fri, 09 Sep 2005 07:41:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDhGV-0006QB-Iu for hipsec@megatron.ietf.org; Fri, 09 Sep 2005 07:41:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25982 for ; Fri, 9 Sep 2005 07:41:54 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDhK5-00078s-C5 for hipsec@ietf.org; Fri, 09 Sep 2005 07:45:37 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6D383212CE7 for ; Fri, 9 Sep 2005 14:41:46 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v734) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2DADB08E-A3C5-4975-83CD-2B1FFD2726E0@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 9 Sep 2005 13:41:45 +0200 To: hipsec@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Fwd: draft-ietf-hip-arch-03.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Begin forwarded message: > From: Margaret Wasserman > Date: September 9, 2005 13:20:47 GMT+02:00 > To: iesg-secretary@ietf.org > Cc: iesg@ietf.org, rgm@icsalabs.com, pekka.nikander@nomadiclab.com > Subject: draft-ietf-hip-arch-03,txt > > The last discuss has been cleared, and draft-ietf-hip-arch-03.txt > is approved for publication as an Informational RFC. I've placed > the document in "Approved -- Announcement to be Sent". Please send > the announcement and forward the document to the RFC Editor for > publication. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 13 15:31:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGUs-0003lv-5C; Tue, 13 Sep 2005 15:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF5Vm-0002JY-Nl for hipsec@megatron.ietf.org; Tue, 13 Sep 2005 03:47:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08396 for ; Tue, 13 Sep 2005 03:47:10 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF5Zr-0003C2-SO for hipsec@ietf.org; Tue, 13 Sep 2005 03:51:42 -0400 Received: from [192.168.1.105] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 431C605C00672FE2; Tue, 13 Sep 2005 09:46:50 +0200 From: Julien Laganier To: hipsec@ietf.org User-Agent: KMail/1.8 References: <200508311208.51403.julien.IETF@laposte.net> <43158215.2010201@ericsson.com> In-Reply-To: <43158215.2010201@ericsson.com> MIME-Version: 1.0 Date: Tue, 13 Sep 2005 09:48:03 +0200 Content-Type: Multipart/Mixed; boundary="Boundary-00=_zQoJDOi74MRoZa6" Message-Id: <200509130948.03698.julien.IETF@laposte.net> X-Spam-Score: 0.2 (/) X-Scan-Signature: 1779b17ec4605d4a8c574b54662a43f9 Cc: Lars Eggert Subject: [Hipsec] Re: HIP Registration I-D 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=_zQoJDOi74MRoZa6 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi folks, Attached is the updated HIP registration I-D (and wdiff to the previous version) that I want to submit shortly as a WG draft, as agreed during the last meeting. Changes are IANA considerations, Pekka's suggestion on handling lifetime in REQUEST and RESPONSE, and registration failure types as per Miriam's request. Please tell me if you think something is missing or wrong in the draft. Tnx. --julien --Boundary-00=_zQoJDOi74MRoZa6 Content-Type: text/plain; charset="iso-8859-1"; name="draft-ietf-hip-registration-00.txt" Content-Disposition: attachment; filename="draft-ietf-hip-registration-00.txt" Content-Transfer-Encoding: 7bit Network Working Group J. Laganier Internet-Draft DoCoMo Euro-Labs Expires: March 6, 2006 T. Koponen HIIT L. Eggert NEC September 2, 2005 Host Identity Protocol (HIP) Registration Extension draft-koponen-hip-registration-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. Laganier, et al. Expires March 6, 2006 [Page 1] Internet-Draft HIP Registration Extension September 2005 1. Introduction This document specifies an extension to the Host Identity Protocol (HIP) [I-D.ietf-hip-arch]. The extension provides a generic means for a host to register with a service. The service may, for example, be a HIP rendezvous server [I-D.ietf-hip-rvs] or a middlebox [RFC3234]. This document makes no further assumptions about the exact type of service. Likewise, this document does not specify any mechanisms to discover the presence of specific services or means to interact with them after registration. Future documents may describe those operations. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology This section defines terminology that is used throughout the remainder of this document. Please note that terminology shared with other documents is defined elsewhere [I-D.ietf-hip-arch]. Requester: a HIP node registering with a HIP registrar to request registration for a service. Registrar: a HIP node offering registration for one or more services. Service: a facility that provides requesters with new capabilities or functionalities operating at the HIP layer. Examples include firewalls that support HIP traversal or HIP rendezvous servers. Registration: shared state stored by a requester and a registrar, allowing the requester to benefit from one or more HIP services offered by the registrar. Each registration has an associated finite lifetime. Requesters can extend established registrations through re- registration (i.e., perform a refresh). Registration Type: an identifier for a given service in the registration protocol. For example, the rendezvous service is identified by a specific registration type. Laganier, et al. Expires March 6, 2006 [Page 2] Internet-Draft HIP Registration Extension September 2005 3. HIP Registration Extension Overview This document does not specify the means by which a requester discovers the availability of a service, or how a requester locates a registrar. After a requester has discovered a registrar, it either initiates HIP base exchange or uses an existing HIP association with the registrar. In both cases, registrars use additional parameters that the remainder of this document defines to announce their quality and grant or refuse registration. Requesters use corresponding parameters to register with the service. The following sections describe the differences between this registration handshake and the standard HIP base exchange [I-D.ietf-hip-base] . 3.1 Registrar Announcing its Ability A host that is capable and willing to act as a registrar SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges. If it is currently unable to provide services due to transient conditions, it SHOULD include an empty REG_INFO, i.e., one with no services listed. If services can be provided later, it SHOULD send UPDATE packets indicating the current set of services available in a new REG_INFO parameter to all hosts it is associated with. 3.2 Requester Requesting Registration To request registration with a service, a requester constructs and includes a corresponding REG_REQUEST parameter in an I2 or UPDATE packet it sends to the registrar. If the requester has no HIP association established with the registrar, it SHOULD already send the REG_REQUEST in the I2 packet. This minimizes the number of packets that need to be exchanged with the registrar. A registrar MAY end a HIP association that does not carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED in the R2. In this case, no HIP association is created between the hosts. The REG_REQUIRED notification error type is TBD. 3.3 Registrar Granting or Refusing Service(s) Registration Once registration has been requested, the registrar is able to authenticate the requester based on the host identity included in I2. It then verifies the host identity is authorized to register with the requested service(s), based on local policies. The details of this authorization procedure depend on the type of requested service(s) and on the local policies of the registrar, and are therefore not further specified in this document. Laganier, et al. Expires March 6, 2006 [Page 3] Internet-Draft HIP Registration Extension September 2005 After authorization, the registrar includes in its response (i.e., an R2 or an UPDATE, respectively, depending on whether the registration was requested during the base exchange, or using an existing association) a REG_RESPONSE parameter containing the service(s) type(s) for which it has authorized registration, and zero or more REG_FAILED parameter containing the service(s) type(s) for which it has not authorized registration or registration has failed for other reasons. In particular, REG_FAILED with a failure type of zero indicates the service(s) type(s) that require further credentials for registration. If the registrar requires further authorization and the requester has additional credentials available, the requester SHOULD try to again register with the service after the HIP association has been established. Successful processing of a REG_RESPONSE parameter creates registration state at the requester. In a similar manner, successful processing of a REG_REQUEST parameter creates registration state at the registrar and possibly at the service. Both the requester and registrar can cancel a registration before it expires, if the services afforded by a registration are no longer needed by the requester, or cannot be provided any longer by the registrar (for instance, because its configuration has changed). +-----+ I1 +-----+-----+ | |--------------------->| | S1 | | |<---------------------| | | | | R1(REG_INFO:S1,S2) | +-----+ | RQ | | R | S2 | | | I2(REG_REQ:S1) | | | | |--------------------->| +-----+ | |<---------------------| | S3 | | | R2(REG_RESP:S1) | | | +-----+ +-----+-----+ +-----+ +-----+-----+ | | UPDATE(REG_INFO:S) | | | | |<---------------------| | | | RQ |--------------------->| R | S | | | UPDATE(REG_REQ:S) | | | | | UPDATE(REG_RESP:S) | | | | |<---------------------| | | +-----+ +-----+-----+ Laganier, et al. Expires March 6, 2006 [Page 4] Internet-Draft HIP Registration Extension September 2005 4. Parameter Formats and Processing This section describes the format and processing of the new parameters introduced by the HIP registration extension. 4.1 Encoding Registration Lifetimes with Exponents The HIP registration uses an exponential encoding of registration lifetimes. This allows compact encoding of 255 different lifetime values ranging from 4 ms to 178 days into an 8-bit integer field. The lifetime exponent field used throughout this document MUST be interpreted as representing the lifetime value 2^((lifetime - 64)/8) seconds. 4.2 REG_INFO 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reg Type #3 | | +-+-+-+-+-+-+-+-+ Padding + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (930) ] Length Length in octets, excluding Type, Length, and Padding. Min Lifetime Minimum registration lifetime. Max Lifetime Maximum registration lifetime. Reg Type The registration types offered by the registrar. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Registrars include the parameter in R1 packets in order to announce their registration capabilities. The registrar SHOULD include the parameter in UPDATE packets when its service offering has changed. HIP_SIGNATURE_2 protects the parameter within the R1 packets. Laganier, et al. Expires March 6, 2006 [Page 5] Internet-Draft HIP Registration Extension September 2005 4.3 REG_REQUEST 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reg Type #1 | Reg Type #2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (932) ] Length Length in octets, excluding Type, Length, and Padding. Lifetime Requested registration lifetime. Reg Type The preferred registration types in order of preference. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use A requester includes the REG_REQUEST parameter in I2 or UPDATE packets to register with a registrar's service(s). If the REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT modify the registrations of registration types which are not listed in the parameter. 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. The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. When the registrar is requested a registration which lifetime is either smaller or greater than the minimum or maximum lifetime, respectively, then it SHOULD grant the registration for the minimum or maximum lifetime, respectively. HIP_SIGNATURE protects the parameter within the I2 and UPDATE packets. Laganier, et al. Expires March 6, 2006 [Page 6] Internet-Draft HIP Registration Extension September 2005 4.4 REG_RESPONSE 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reg Type #1 | Reg Type #2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (934) ] Length Length in octets, excluding Type, Length, and Padding. Lifetime Granted registration lifetime. Reg Type The granted registration types in order of preference. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or UPDATE packet only if a registration has successfully completed. The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets, while the requester MUST be able to process one or more REG_RESPONSE parameters in received R2 or UPDATE packets. The requester MUST be prepared to receive any registration lifetime, included ones beyond the minimum and maximum lifetime indicated in the REG_INFO parameter. It MUST NOT expect that the returned lifetime will be the requested one, even in the case that the requested lifetime falls within the announced minimum and maximum. HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets. Laganier, et al. Expires March 6, 2006 [Page 7] Internet-Draft HIP Registration Extension September 2005 4.5 REG_FAILED 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failure Type | Reg Type #1 | Reg Type #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (936) ] Length Length in octets, excluding Type, Length, and Padding. Failure Type Reason for failure. Reg Type The registration types that failed with the specified reason. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Reserved by IANA 201-255 Reserved by IANA for private use A failure type of zero means a registrar requires additional credentials to authorize a requester to register with the registration types listed in the parameter. Other failure types than zero have not been defined. The registrar SHOULD include the REG_FAILED parameter in its R2 or UPDATE packet, if registration with the registration types listed has not completed successfully and a requester is asked to try again with additional credentials. HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets. 5. Establishing and Maintaining Registrations Establishing and/or maintaining a registration may require additional information not available in the transmitted REG_REQUEST or REG_RESPONSE parameters. Therefore, registration type definitions Laganier, et al. Expires March 6, 2006 [Page 8] Internet-Draft HIP Registration Extension September 2005 MAY define dependencies for HIP parameters that are not defined in this document. Their semantics are subject to the specific registration type specifications. The minimum lifetime both registrars and requesters MUST support is 10 seconds, while they SHOULD support a maximum lifetime of 120 seconds, at least. A zero lifetime is reserved for canceling purposes. Requesting a zero lifetime for a registration type equals to canceling the registration of that type. A requester MAY cancel a registration before it expires by sending a REG_REQ to the registrar with a zero lifetime. A registrar SHOULD respond and grant a registration with a zero lifetime. A registrar (and an attached service) MAY cancel a registration before it expires, at its own discretion. However, if it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all registered requesters. 6. Security Considerations This section discusses the threats on the HIP registration protocol, and their implications on the overall security of HIP. In particular, it argues that the extensions described in this document do not introduce additional threats to HIP. The extensions described in this document rely on the HIP base exchange and do not modify its security characteristics, e.g., digital signatures or HMAC. Hence, the only threat introduced by these extensions are related to the creation of soft registration state at the registrar. Registrars act on a voluntary basis and are willing to accept to be a responder and to then create HIP associations with a number of previously unknown hosts. Because they have to store HIP association state anyway, adding a certain amount of time-limited HIP registration state should not introduce and serious additional threats, especially because HIP registrars may cancel registrations at any time at their own discretion, e.g., because of resource constraints during an attack. 7. IANA Considerations This section is to be interpreted according to [RFC2434]. This document updates the IANA Registry for HIP Parameters Types by assigning new HIP Parameter Types values for the new HIP Parameters defined in this document: Laganier, et al. Expires March 6, 2006 [Page 9] Internet-Draft HIP Registration Extension September 2005 o REG_INFO (defined in Section 4.2) o REG_REQUEST (defined in Section 4.3) o REG_RESPONSE (defined in Section 4.4) o REG_FAILED (defined in Section 4.5) IANA needs to open a new registry for registration types. This document does not define registration types but makes the following reservations: Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Adding a new type requires new IETF specifications. IANA needs to open a new registry for registration failure types. This document makes the following failure types definitions and reservations: Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Reserved by IANA 201-255 Reserved by IANA for private use Adding a new type requires new IETF specifications. 8. Acknowledgments The following people (in alphabetical order) have provided thoughtful and helpful discussions and/or suggestions that have helped improved this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, Pekka Nikander and Hannes Tschofenig. Julien Laganier and Lars Eggert are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. 9. References Laganier, et al. Expires March 6, 2006 [Page 10] Internet-Draft HIP Registration Extension September 2005 9.1 Normative References [I-D.ietf-hip-arch] Moskowitz, R., "Host Identity Protocol Architecture", draft-ietf-hip-arch-02 (work in progress), January 2005. [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 (work in progress), June 2005. [I-D.ietf-hip-rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-03 (work in progress), July 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 9.2 Informative References [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. Authors' Addresses Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany Phone: +49 89 56824 231 Email: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/ Laganier, et al. Expires March 6, 2006 [Page 11] Internet-Draft HIP Registration Extension September 2005 Teemu Koponen Helsinki Institute for Information Technology Advanced Research Unit (ARU) P.O. Box 9800 Helsinki FIN-02015-HUT Finland Phone: +358 9 45 1 Email: teemu.koponen@hiit.fi URI: http://www.hiit.fi/ Lars Eggert NEC Network Laboratories Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 Email: lars.eggert@netlab.nec.de URI: http://www.netlab.nec.de/ Laganier, et al. Expires March 6, 2006 [Page 12] Internet-Draft HIP Registration Extension September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Laganier, et al. Expires March 6, 2006 [Page 13] --Boundary-00=_zQoJDOi74MRoZa6 Content-Type: text/html; charset="iso-8859-1"; name="wdiff.html" Content-Disposition: attachment; filename="wdiff.html" Content-Transfer-Encoding: 7bit wdiff MORGUE/draft-koponen-hip-registration-01.txt draft-ietf-hip-registration-00.txt 



Network Working Group                                        J. Laganier
Internet-Draft                                          DoCoMo Euro-Labs
Expires: January 12, March 6, 2006                                        T. Koponen
                                                                    HIIT
                                                               L. Eggert
                                                                     NEC
                                                           July 11,
                                                       September 2, 2005


          Host Identity Protocol (HIP) Registration Extension
                   draft-koponen-hip-registration-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
   This document may not be modified, and derivative works of it may not
   be created, except to publish it as an RFC and to translate it into
   languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, March 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document specifies a registration mechanism for the Host
   Identity Protocol (HIP) that allows hosts to register with services,
   such as HIP rendezvous servers or middleboxes.





Laganier, et al.          Expires January 12, March 6, 2006                 [Page 1]

Internet-Draft         HIP Registration Extension              July         September 2005


   such as HIP rendezvous servers or middleboxes.


1.  Introduction

   This document specifies an extension to the Host Identity Protocol
   (HIP) [I-D.ietf-hip-arch].  The extension provides a generic means
   for a host to register with a service.  The service may, for example,
   be a HIP rendezvous server [I-D.ietf-hip-rvs] or a middlebox
   [RFC3234].

   This document makes no further assumptions about the exact type of
   service.  Likewise, this document does not specify any mechanisms to
   discover the presence of specific services or means to interact with
   them after registration.  Future documents may describe those
   operations.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Terminology

   This section defines terminology that is used throughout the
   remainder of this document.  Please note that terminology shared with
   other documents is defined elsewhere [I-D.ietf-hip-arch].

   Requester:
      a HIP node registering with a HIP registrar to request
      registration for a service.

   Registrar:
      a HIP node offering registration for one or more services.

   Service:
      a facility that provides requesters with new capabilities or
      functionalities operating at the HIP layer.  Examples include
      firewalls that support HIP traversal or HIP rendezvous servers.

   Registration:
      shared state stored by a requester and a registrar, allowing the
      requester to benefit from one or more HIP services offered by the
      registrar.  Each registration has an associated finite lifetime.
      Requesters can extend established registrations through re-
      registration (i.e., perform a refresh).







Laganier, et al.        Expires January 12, 2006                [Page 2]

Internet-Draft         HIP Registration Extension              July 2005

   Registration Type:
      an identifier for a given service in the registration protocol.
      For example, the rendezvous service is identified by a specific
      registration type.




Laganier, et al.          Expires March 6, 2006                 [Page 2]

Internet-Draft         HIP Registration Extension         September 2005


3.  HIP Registration Extension Overview

   This document does not specify the means by which a requester
   discovers the availability of a service, or how a requester locates a
   registrar.  After a requester has discovered a registrar, it either
   initiates HIP base exchange or uses an existing HIP association with
   the registrar.  In both cases, registrars use additional parameters
   that the remainder of this document defines to announce their quality
   and grant or refuse registration.  Requesters use corresponding
   parameters to register with the service.  The following sections
   describe the differences between this registration handshake and the
   standard HIP base exchange [I-D.ietf-hip-base] .

3.1  Registrar Announcing its Ability

   A host that is capable and willing to act as a registrar SHOULD
   include a REG_INFO parameter in the R1 packets it sends during all
   base exchanges.  If it is currently unable to provide services due to
   transient conditions, it SHOULD include an empty REG_INFO, i.e., one
   with no services listed.  If services can be provided later, it
   SHOULD send UPDATE packets indicating the current set of services
   available in a new REG_INFO parameter to all hosts it is associated
   with.

3.2  Requester Requesting Registration

   To request registration with a service, a requester constructs and
   includes a corresponding REG_REQUEST parameter in an I2 or UPDATE
   packet it sends to the registrar.

   If the requester has no HIP association established with the
   registrar, it SHOULD already send the REG_REQUEST in the I2 packet.
   This minimizes the number of packets that need to be exchanged with
   the registrar.  A registrar MAY end a HIP association that does not
   carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED
   in the R2.  In this case, no HIP association is created between the
   hosts.  The REG_REQUIRED notification error type is TBD.

3.3  Registrar Granting or Refusing Service(s) Registration

   Once registration has been requested, the registrar is able to
   authenticate the requester based on the host identity included in I2.



Laganier, et al.        Expires January 12, 2006                [Page 3]

Internet-Draft         HIP Registration Extension              July 2005
   It then verifies the host identity is authorized to register with the
   requested service(s), based on local policies.  The details of this
   authorization procedure depend on the type of requested service(s)
   and on the local policies of the registrar, and are therefore not
   further specified in this document.




Laganier, et al.          Expires March 6, 2006                 [Page 3]

Internet-Draft         HIP Registration Extension         September 2005


   After authorization, the registrar includes in its response (i.e., an
   R2 or an UPDATE, respectively, depending on whether the registration
   was requested during the base exchange, or using an existing
   association) a REG_RESPONSE parameter containing the service(s)
   type(s) for which it has authorized registration, and zero or more
   REG_FAILED parameter containing the service(s) type(s) for which it
   has not authorized registration or registration has failed for other
   reasons.  In particular, REG_FAILED with a failure type of zero
   indicates the service(s) type(s) that require further credentials for
   registration.

   If the registrar requires further authorization and the requester has
   additional credentials available, the requester SHOULD try to again
   register with the service after the HIP association has been
   established.

   Successful processing of a REG_RESPONSE parameter creates
   registration state at the requester.  In a similar manner, successful
   processing of a REG_REQUEST parameter creates registration state at
   the registrar and possibly at the service.  Both the requester and
   registrar can cancel a registration before it expires, if the
   services afforded by a registration are no longer needed by the
   requester, or cannot be provided any longer by the registrar (for
   instance, because its configuration has changed).

                 +-----+          I1          +-----+-----+
                 |     |--------------------->|     |  S1 |
                 |     |<---------------------|     |     |
                 |     |  R1(REG_INFO:S1,S2)  |     +-----+
                 | RQ  |                      |  R  |  S2 |
                 |     |    I2(REG_REQ:S1)    |     |     |
                 |     |--------------------->|     +-----+
                 |     |<---------------------|     |  S3 |
                 |     |    R2(REG_RESP:S1)   |     |     |
                 +-----+                      +-----+-----+










Laganier, et al.        Expires January 12, 2006                [Page 4]

Internet-Draft         HIP Registration Extension              July 2005



                 +-----+                      +-----+-----+
                 |     |  UPDATE(REG_INFO:S)  |     |     |
                 |     |<---------------------|     |     |
                 | RQ  |--------------------->|  R  |  S  |
                 |     |  UPDATE(REG_REQ:S)   |     |     |
                 |     |  UPDATE(REG_RESP:S)  |     |     |
                 |     |<---------------------|     |     |
                 +-----+                      +-----+-----+





Laganier, et al.          Expires March 6, 2006                 [Page 4]

Internet-Draft         HIP Registration Extension         September 2005


4.  Parameter Formats and Processing

   This section describes the format and processing of the new
   parameters introduced by the HIP registration extension.

4.1  Encoding Registration Lifetimes with Exponents

   The HIP registration uses an exponential encoding of registration
   lifetimes.  This allows compact encoding of 255 different lifetime
   values ranging from 4 ms to 178 days into an 8-bit integer field.
   The lifetime exponent field used throughout this document MUST be
   interpreted as representing the lifetime value 2^((lifetime - 64)/8)
   seconds.

4.2  REG_INFO

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Min Lifetime  | Max Lifetime  |  Reg Type #1  |  Reg Type #2  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reg Type #3  |                                               |
   +-+-+-+-+-+-+-+-+                 Padding                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type           [ TBD by IANA (930) ]
   Length         Length in octets, excluding Type, Length, and Padding.
   Min Lifetime   Minimum registration lifetime.
   Max Lifetime   Maximum registration lifetime.
   Reg Type       The registration types offered by the registrar.

   Other documents will define specific values for registration types.

   Reg Type        Service
   --------        -------
   0-200           Reserved by IANA
   201-255         Reserved by IANA for private use



Laganier, et al.        Expires January 12, 2006                [Page 5]

Internet-Draft         HIP Registration Extension              July 2005

   Registrars include the parameter in R1 packets in order to announce
   their registration capabilities.  The registrar SHOULD include the
   parameter in UPDATE packets when its service offering has changed.
   HIP_SIGNATURE_2 protects the parameter within the R1 packets.






Laganier, et al.          Expires March 6, 2006                 [Page 5]

Internet-Draft         HIP Registration Extension         September 2005


4.3  REG_REQUEST

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Lifetime    |  Reg Type #1  |  Reg Type #2  |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type        [ TBD by IANA (932) ]
   Length      Length in octets, excluding Type, Length, and Padding.
   Lifetime    Requested registration lifetime.
   Reg Type    The preferred registration types in order of preference.

   Other documents will define specific values for registration types.

   Reg Type        Service
   --------        -------
   0-200           Reserved by IANA
   201-255         Reserved by IANA for private use

   A requester includes the REG_REQUEST parameter in I2 or UPDATE
   packets to register with a registrar's service(s).  If the
   REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT
   modify the registrations of registration types which are not listed
   in the parameter.  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.

   The requester MUST NOT include more than one REG_REQUEST parameter in
   its I2 or UPDATE packets, while the registrar MUST be able to process
   one or more REG_REQUEST parameters in received I2 or UPDATE packets.

   When the registrar is requested a registration which lifetime is
   either smaller or greater than the minimum or maximum lifetime,
   respectively, then it SHOULD grant the registration for the minimum
   or maximum lifetime, respectively.

   HIP_SIGNATURE protects the parameter within the I2 and UPDATE
   packets.









Laganier, et al.          Expires January 12, March 6, 2006                 [Page 6]

Internet-Draft         HIP Registration Extension              July         September 2005


4.4  REG_RESPONSE

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Lifetime    |  Reg Type #1  |  Reg Type #2  |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type        [ TBD by IANA (934) ]
   Length      Length in octets, excluding Type, Length, and Padding.
   Lifetime    Granted registration lifetime.
   Reg Type    The granted registration types in order of preference.

   Other documents will define specific values for registration types.

   Reg Type        Service
   --------        -------
   0-200           Reserved by IANA
   201-255         Reserved by IANA for private use

   The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or
   UPDATE packet only if a registration has successfully completed.

   The registrar MUST NOT include more than one REG_RESPONSE parameter
   in its R2 or UPDATE packets, while the requester MUST be able to
   process one or more REG_REQUEST REG_RESPONSE parameters in received R2 or UPDATE
   packets.

   The requester MUST be prepared to receive any registration lifetime,
   included ones beyond the minimum and maximum lifetime indicated in
   the REG_INFO parameter.  It MUST NOT expect that the returned
   lifetime will be the requested one, even in the case that the
   requested lifetime falls within the announced minimum and maximum.

   HIP_SIGNATURE protects the parameter within the R2 and UPDATE
   packets.













Laganier, et al.          Expires January 12, March 6, 2006                 [Page 7]

Internet-Draft         HIP Registration Extension              July         September 2005


4.5  REG_FAILED

     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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Failure Type  |  Reg Type #1  |  Reg Type #n  |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type          [ TBD by IANA (936) ]
    Length        Length in octets, excluding Type, Length, and Padding.
    Failure Type  Reason for failure.
    Reg Type      The registration types that failed with the specified
                  reason.

    Other documents will define specific values for registration types.

    Reg Type        Service
    --------        -------
    0-200           Reserved by IANA
    201-255         Reserved by IANA for private use

    Failure Type    Reason
    ------------    --------------------------------------------
    0               Registration requires additional credentials
    1               Registration type unavailable
    2-200           Reserved by IANA
    201-255         Reserved by IANA for private use

   A failure type of zero means a registrar requires additional
   credentials to authorize a requester to register with the
   registration types listed in the parameter.  Other failure types than
   zero have not been defined.

   The registrar SHOULD include the REG_FAILED parameter in its R2 or
   UPDATE packet, if registration with the registration types listed has
   not completed successfully and a requester is asked to try again with
   additional credentials.

   HIP_SIGNATURE protects the parameter within the R2 and UPDATE
   packets.

5.  Establishing and Maintaining Registrations

   Establishing and/or maintaining a registration may require additional
   information not available in the transmitted REG_REQUEST or
   REG_RESPONSE parameters.  Therefore, registration type definitions



Laganier, et al.          Expires March 6, 2006                 [Page 8]

Internet-Draft         HIP Registration Extension         September 2005


   MAY define dependencies for HIP parameters that are not defined in
   this document.  Their semantics are subject to the specific
   registration type specifications.

   The minimum lifetime both registrars and requesters MUST support is
   10 seconds, while they SHOULD support a maximum lifetime of 120
   seconds, at least.

   A zero lifetime is reserved for canceling purposes.  Requesting a



Laganier, et al.        Expires January 12, 2006                [Page 8]

Internet-Draft         HIP Registration Extension              July 2005
   zero lifetime for a registration type equals to canceling the
   registration of that type.  A requester MAY cancel a registration
   before it expires by sending a REG_REQ to the registrar with a zero
   lifetime.  A registrar SHOULD respond and grant a registration with a
   zero lifetime.  A registrar (and an attached service) MAY cancel a
   registration before it expires, at its own discretion.  However, if
   it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all
   registered requesters.

6.  Security Considerations

   This section discusses the threats on the HIP registration protocol,
   and their implications on the overall security of HIP.  In
   particular, it argues that the extensions described in this document
   do not introduce additional threats to HIP.

   The extensions described in this document rely on the HIP base
   exchange and do not modify its security characteristics, e.g.,
   digital signatures or HMAC.  Hence, the only threat introduced by
   these extensions are related to the creation of soft registration
   state at the registrar.

   Registrars act on a voluntary basis and are willing to accept to be a
   responder and to then create HIP associations with a number of
   previously unknown hosts.  Because they have to store HIP association
   state anyway, adding a certain amount of time-limited HIP
   registration state should not introduce and serious additional
   threats, especially because HIP registrars may cancel registrations
   at any time at their own discretion, e.g., because of resource
   constraints during an attack.

7.  IANA Considerations

   This section is to be interpreted according to [RFC2434].

   This document updates the IANA Registry for HIP Parameters Types by
   assigning new HIP Parameter Types values for the new HIP Parameters
   defined in this document:




Laganier, et al.          Expires March 6, 2006                 [Page 9]

Internet-Draft         HIP Registration Extension         September 2005


   o  REG_INFO (defined in Section 4.2)

   o  REG_REQUEST (defined in Section 4.3)

   o  REG_RESPONSE (defined in Section 4.4)

   o  REG_FAILED (defined in Section 4.5)

   IANA needs to open a new registry for registration types.  No  This
   document does not define registration types



Laganier, et al.        Expires January 12, 2006                [Page 9]

Internet-Draft         HIP but makes the following
   reservations:

   Reg Type        Service
   --------        -------
   0-200           Reserved by IANA
   201-255         Reserved by IANA for private use

   Adding a new type requires new IETF specifications.

   IANA needs to open a new registry for registration failure types.
   This document makes the following failure types definitions and
   reservations:

   Failure Type    Reason
   ------------    --------------------------------------------
   0               Registration Extension              July 2005


   are defined in this document. requires additional credentials
   1               Registration type unavailable
   2-200           Reserved by IANA
   201-255         Reserved by IANA for private use

   Adding a new type requires new IETF specifications.

8.  Acknowledgments

   The following people (in alphabetical order) have provided thoughtful
   and helpful discussions and/or suggestions that have helped improved
   this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, Pekka Nikander,
   Hannes Tschofenig
   Nikander and Mika Kousa. Hannes Tschofenig.

   Julien Laganier and Lars Eggert are partly funded by Ambient
   Networks, a research project supported by the European Commission
   under its Sixth Framework Program.  The views and conclusions
   contained herein are those of the authors and should not be
   interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the Ambient Networks
   project or the European Commission.

9.  References



Laganier, et al.          Expires March 6, 2006                [Page 10]

Internet-Draft         HIP Registration Extension         September 2005


9.1  Normative References

   [I-D.ietf-hip-arch]
              Moskowitz, R., "Host Identity Protocol Architecture",
              draft-ietf-hip-arch-02 (work in progress), January 2005.

   [I-D.ietf-hip-base]
              Moskowitz, R., "Host Identity Protocol",
              draft-ietf-hip-base-03 (work in progress), June 2005.

   [I-D.ietf-hip-rvs]
              Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", draft-ietf-hip-rvs-02 draft-ietf-hip-rvs-03 (work in
              progress), June July 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

9.2  Informative References

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.






Laganier, et al.        Expires January 12, 2006               [Page 10]

Internet-Draft         HIP Registration Extension              July 2005


Authors' Addresses

   Julien Laganier
   DoCoMo Communications Laboratories Europe GmbH
   Landsberger Strasse 312
   Munich  80687
   Germany

   Phone: +49 89 56824 231
   Email: julien.ietf@laposte.net
   URI:   http://www.docomolab-euro.com/












Laganier, et al.          Expires March 6, 2006                [Page 11]

Internet-Draft         HIP Registration Extension         September 2005


   Teemu Koponen
   Helsinki Institute for Information Technology
   Advanced Research Unit (ARU)
   P.O. Box 9800
   Helsinki  FIN-02015-HUT
   Finland

   Phone: +358 9 45 1
   Email: teemu.koponen@hiit.fi
   URI:   http://www.hiit.fi/


   Lars Eggert
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 90511 43
   Fax:   +49 6221 90511 55
   Email: lars.eggert@netlab.nec.de
   URI:   http://www.netlab.nec.de/

Appendix A.  Document Revision History

   +-----------+-------------------------------------------------------+
   | Revision  | Comments                                              |
   +-----------+-------------------------------------------------------+
   | 00        | Initial submission.                                   |
   | 01        | Editorial and boilerplate fixes. Modified             |
   |           | terminology. Added security considerations. Changed   |
   |           | requirement keyword on new parameters processing.     |
   +-----------+-------------------------------------------------------+





























Laganier, et al.          Expires January 12, March 6, 2006                [Page 11] 12]

Internet-Draft         HIP Registration Extension              July         September 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Laganier, et al.          Expires January 12, March 6, 2006                [Page 12] 13]
--Boundary-00=_zQoJDOi74MRoZa6 Content-Type: text/xml; charset="iso-8859-1"; name="draft-ietf-hip-registration-00.xml" Content-Disposition: attachment; filename="draft-ietf-hip-registration-00.xml" Content-Transfer-Encoding: 7bit Host Identity Protocol (HIP) Registration Extension DoCoMo Communications Laboratories Europe GmbH
Landsberger Strasse 312 Munich 80687 Germany +49 89 56824 231 julien.ietf@laposte.net http://www.docomolab-euro.com/
Helsinki Institute for Information Technology
Advanced Research Unit (ARU) P.O. Box 9800 FIN-02015-HUT Helsinki Finland +358 9 45 1 teemu.koponen@hiit.fi http://www.hiit.fi/
NEC Network Laboratories
Kurfuerstenanlage 36 69115 Heidelberg Germany +49 6221 90511 43 +49 6221 90511 55 lars.eggert@netlab.nec.de http://www.netlab.nec.de/
Internet HIP host identity protocol host identity payload registration This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes.
This document specifies an extension to the Host Identity Protocol (HIP) . The extension provides a generic means for a host to register with a service. The service may, for example, be a HIP rendezvous server or a middlebox . This document makes no further assumptions about the exact type of service. Likewise, this document does not specify any mechanisms to discover the presence of specific services or means to interact with them after registration. Future documents may describe those operations. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
This section defines terminology that is used throughout the remainder of this document. Please note that terminology shared with other documents is defined elsewhere . a HIP node registering with a HIP registrar to request registration for a service. a HIP node offering registration for one or more services. a facility that provides requesters with new capabilities or functionalities operating at the HIP layer. Examples include firewalls that support HIP traversal or HIP rendezvous servers. shared state stored by a requester and a registrar, allowing the requester to benefit from one or more HIP services offered by the registrar. Each registration has an associated finite lifetime. Requesters can extend established registrations through re-registration (i.e., perform a refresh). an identifier for a given service in the registration protocol. For example, the rendezvous service is identified by a specific registration type.
This document does not specify the means by which a requester discovers the availability of a service, or how a requester locates a registrar. After a requester has discovered a registrar, it either initiates HIP base exchange or uses an existing HIP association with the registrar. In both cases, registrars use additional parameters that the remainder of this document defines to announce their quality and grant or refuse registration. Requesters use corresponding parameters to register with the service. The following sections describe the differences between this registration handshake and the standard HIP base exchange .
A host that is capable and willing to act as a registrar SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges. If it is currently unable to provide services due to transient conditions, it SHOULD include an empty REG_INFO, i.e., one with no services listed. If services can be provided later, it SHOULD send UPDATE packets indicating the current set of services available in a new REG_INFO parameter to all hosts it is associated with.
To request registration with a service, a requester constructs and includes a corresponding REG_REQUEST parameter in an I2 or UPDATE packet it sends to the registrar. If the requester has no HIP association established with the registrar, it SHOULD already send the REG_REQUEST in the I2 packet. This minimizes the number of packets that need to be exchanged with the registrar. A registrar MAY end a HIP association that does not carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED in the R2. In this case, no HIP association is created between the hosts. The REG_REQUIRED notification error type is TBD.
Once registration has been requested, the registrar is able to authenticate the requester based on the host identity included in I2. It then verifies the host identity is authorized to register with the requested service(s), based on local policies. The details of this authorization procedure depend on the type of requested service(s) and on the local policies of the registrar, and are therefore not further specified in this document. After authorization, the registrar includes in its response (i.e., an R2 or an UPDATE, respectively, depending on whether the registration was requested during the base exchange, or using an existing association) a REG_RESPONSE parameter containing the service(s) type(s) for which it has authorized registration, and zero or more REG_FAILED parameter containing the service(s) type(s) for which it has not authorized registration or registration has failed for other reasons. In particular, REG_FAILED with a failure type of zero indicates the service(s) type(s) that require further credentials for registration. If the registrar requires further authorization and the requester has additional credentials available, the requester SHOULD try to again register with the service after the HIP association has been established. Successful processing of a REG_RESPONSE parameter creates registration state at the requester. In a similar manner, successful processing of a REG_REQUEST parameter creates registration state at the registrar and possibly at the service. Both the requester and registrar can cancel a registration before it expires, if the services afforded by a registration are no longer needed by the requester, or cannot be provided any longer by the registrar (for instance, because its configuration has changed).
+-----+ I1 +-----+-----+ | |--------------------->| | S1 | | |<---------------------| | | | | R1(REG_INFO:S1,S2) | +-----+ | RQ | | R | S2 | | | I2(REG_REQ:S1) | | | | |--------------------->| +-----+ | |<---------------------| | S3 | | | R2(REG_RESP:S1) | | | +-----+ +-----+-----+
+-----+ +-----+-----+ | | UPDATE(REG_INFO:S) | | | | |<---------------------| | | | RQ |--------------------->| R | S | | | UPDATE(REG_REQ:S) | | | | | UPDATE(REG_RESP:S) | | | | |<---------------------| | | +-----+ +-----+-----+
This section describes the format and processing of the new parameters introduced by the HIP registration extension.
The HIP registration uses an exponential encoding of registration lifetimes. This allows compact encoding of 255 different lifetime values ranging from 4 ms to 178 days into an 8-bit integer field. The lifetime exponent field used throughout this document MUST be interpreted as representing the lifetime value 2^((lifetime - 64)/8) seconds.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reg Type #3 | | +-+-+-+-+-+-+-+-+ Padding + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (930) ] Length Length in octets, excluding Type, Length, and Padding. Min Lifetime Minimum registration lifetime. Max Lifetime Maximum registration lifetime. Reg Type The registration types offered by the registrar. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use
Registrars include the parameter in R1 packets in order to announce their registration capabilities. The registrar SHOULD include the parameter in UPDATE packets when its service offering has changed. HIP_SIGNATURE_2 protects the parameter within the R1 packets.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reg Type #1 | Reg Type #2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (932) ] Length Length in octets, excluding Type, Length, and Padding. Lifetime Requested registration lifetime. Reg Type The preferred registration types in order of preference. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use
A requester includes the REG_REQUEST parameter in I2 or UPDATE packets to register with a registrar's service(s). If the REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT modify the registrations of registration types which are not listed in the parameter. 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. The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. When the registrar is requested a registration which lifetime is either smaller or greater than the minimum or maximum lifetime, respectively, then it SHOULD grant the registration for the minimum or maximum lifetime, respectively. HIP_SIGNATURE protects the parameter within the I2 and UPDATE packets.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reg Type #1 | Reg Type #2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (934) ] Length Length in octets, excluding Type, Length, and Padding. Lifetime Granted registration lifetime. Reg Type The granted registration types in order of preference. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use
The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or UPDATE packet only if a registration has successfully completed. The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets, while the requester MUST be able to process one or more REG_RESPONSE parameters in received R2 or UPDATE packets. The requester MUST be prepared to receive any registration lifetime, included ones beyond the minimum and maximum lifetime indicated in the REG_INFO parameter. It MUST NOT expect that the returned lifetime will be the requested one, even in the case that the requested lifetime falls within the announced minimum and maximum. HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failure Type | Reg Type #1 | Reg Type #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (936) ] Length Length in octets, excluding Type, Length, and Padding. Failure Type Reason for failure. Reg Type The registration types that failed with the specified reason. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Reserved by IANA 201-255 Reserved by IANA for private use
A failure type of zero means a registrar requires additional credentials to authorize a requester to register with the registration types listed in the parameter. Other failure types than zero have not been defined. The registrar SHOULD include the REG_FAILED parameter in its R2 or UPDATE packet, if registration with the registration types listed has not completed successfully and a requester is asked to try again with additional credentials. HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
Establishing and/or maintaining a registration may require additional information not available in the transmitted REG_REQUEST or REG_RESPONSE parameters. Therefore, registration type definitions MAY define dependencies for HIP parameters that are not defined in this document. Their semantics are subject to the specific registration type specifications. The minimum lifetime both registrars and requesters MUST support is 10 seconds, while they SHOULD support a maximum lifetime of 120 seconds, at least. A zero lifetime is reserved for canceling purposes. Requesting a zero lifetime for a registration type equals to canceling the registration of that type. A requester MAY cancel a registration before it expires by sending a REG_REQ to the registrar with a zero lifetime. A registrar SHOULD respond and grant a registration with a zero lifetime. A registrar (and an attached service) MAY cancel a registration before it expires, at its own discretion. However, if it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all registered requesters.
This section discusses the threats on the HIP registration protocol, and their implications on the overall security of HIP. In particular, it argues that the extensions described in this document do not introduce additional threats to HIP. The extensions described in this document rely on the HIP base exchange and do not modify its security characteristics, e.g., digital signatures or HMAC. Hence, the only threat introduced by these extensions are related to the creation of soft registration state at the registrar. Registrars act on a voluntary basis and are willing to accept to be a responder and to then create HIP associations with a number of previously unknown hosts. Because they have to store HIP association state anyway, adding a certain amount of time-limited HIP registration state should not introduce and serious additional threats, especially because HIP registrars may cancel registrations at any time at their own discretion, e.g., because of resource constraints during an attack.
This section is to be interpreted according to . This document updates the IANA Registry for HIP Parameters Types by assigning new HIP Parameter Types values for the new HIP Parameters defined in this document: REG_INFO (defined in ) REG_REQUEST (defined in ) REG_RESPONSE (defined in ) REG_FAILED (defined in ) IANA needs to open a new registry for registration types. This document does not define registration types but makes the following reservations:
Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications. IANA needs to open a new registry for registration failure types. This document makes the following failure types definitions and reservations:
Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Reserved by IANA 201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications.
The following people (in alphabetical order) have provided thoughtful and helpful discussions and/or suggestions that have helped improved this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, Pekka Nikander and Hannes Tschofenig. Julien Laganier and Lars Eggert are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission.
--Boundary-00=_zQoJDOi74MRoZa6 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=_zQoJDOi74MRoZa6-- From hipsec-bounces@lists.ietf.org Tue Sep 13 15:32:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWN-0004ha-Td; Tue, 13 Sep 2005 15:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFBgn-0005qc-3h for hipsec@megatron.ietf.org; Tue, 13 Sep 2005 10:23:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24456 for ; Tue, 13 Sep 2005 10:23:10 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFBl3-0003fm-GL for hipsec@ietf.org; Tue, 13 Sep 2005 10:27:46 -0400 Received: from [192.168.1.105] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42F89D1C0125A668 for hipsec@ietf.org; Tue, 13 Sep 2005 16:22:44 +0200 From: Julien Laganier To: hipsec@ietf.org User-Agent: KMail/1.8 References: <200508311208.51403.julien.IETF@laposte.net> <43158215.2010201@ericsson.com> In-Reply-To: <43158215.2010201@ericsson.com> MIME-Version: 1.0 Date: Tue, 13 Sep 2005 16:23:52 +0200 Content-Type: Multipart/Mixed; boundary="Boundary-00=_4DuJDdJZgKi3DsA" Message-Id: <200509131623.52815.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0725f43bdc9fea0192882289ab81b627 Cc: Subject: [Hipsec] Re: HIP Registration I-D 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=_4DuJDdJZgKi3DsA Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi folks, Attached is the updated HIP registration I-D (and wdiff to the previous version) that I want to submit shortly as a WG draft, as agreed during the last meeting. Changes are IANA considerations, Pekka's suggestion on handling lifetime in REQUEST and RESPONSE, and registration failure types as per Miriam's request. Please tell me if you think something is missing or wrong in the draft. Tnx. --julien --Boundary-00=_4DuJDdJZgKi3DsA Content-Type: text/plain; charset="iso-8859-1"; name="draft-ietf-hip-registration-00.txt" Content-Disposition: attachment; filename="draft-ietf-hip-registration-00.txt" Content-Transfer-Encoding: 7bit Network Working Group J. Laganier Internet-Draft DoCoMo Euro-Labs Expires: March 17, 2006 T. Koponen HIIT L. Eggert NEC September 13, 2005 Host Identity Protocol (HIP) Registration Extension draft-ietf-hip-registration-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. Laganier, et al. Expires March 17, 2006 [Page 1] Internet-Draft HIP Registration Extension September 2005 1. Introduction This document specifies an extension to the Host Identity Protocol (HIP) [I-D.ietf-hip-arch]. The extension provides a generic means for a host to register with a service. The service may, for example, be a HIP rendezvous server [I-D.ietf-hip-rvs] or a middlebox [RFC3234]. This document makes no further assumptions about the exact type of service. Likewise, this document does not specify any mechanisms to discover the presence of specific services or means to interact with them after registration. Future documents may describe those operations. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology This section defines terminology that is used throughout the remainder of this document. Please note that terminology shared with other documents is defined elsewhere [I-D.ietf-hip-arch]. Requester: a HIP node registering with a HIP registrar to request registration for a service. Registrar: a HIP node offering registration for one or more services. Service: a facility that provides requesters with new capabilities or functionalities operating at the HIP layer. Examples include firewalls that support HIP traversal or HIP rendezvous servers. Registration: shared state stored by a requester and a registrar, allowing the requester to benefit from one or more HIP services offered by the registrar. Each registration has an associated finite lifetime. Requesters can extend established registrations through re- registration (i.e., perform a refresh). Registration Type: an identifier for a given service in the registration protocol. For example, the rendezvous service is identified by a specific registration type. Laganier, et al. Expires March 17, 2006 [Page 2] Internet-Draft HIP Registration Extension September 2005 3. HIP Registration Extension Overview This document does not specify the means by which a requester discovers the availability of a service, or how a requester locates a registrar. After a requester has discovered a registrar, it either initiates HIP base exchange or uses an existing HIP association with the registrar. In both cases, registrars use additional parameters that the remainder of this document defines to announce their quality and grant or refuse registration. Requesters use corresponding parameters to register with the service. The following sections describe the differences between this registration handshake and the standard HIP base exchange [I-D.ietf-hip-base] . 3.1 Registrar Announcing its Ability A host that is capable and willing to act as a registrar SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges. If it is currently unable to provide services due to transient conditions, it SHOULD include an empty REG_INFO, i.e., one with no services listed. If services can be provided later, it SHOULD send UPDATE packets indicating the current set of services available in a new REG_INFO parameter to all hosts it is associated with. 3.2 Requester Requesting Registration To request registration with a service, a requester constructs and includes a corresponding REG_REQUEST parameter in an I2 or UPDATE packet it sends to the registrar. If the requester has no HIP association established with the registrar, it SHOULD already send the REG_REQUEST in the I2 packet. This minimizes the number of packets that need to be exchanged with the registrar. A registrar MAY end a HIP association that does not carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED in the R2. In this case, no HIP association is created between the hosts. The REG_REQUIRED notification error type is TBD. 3.3 Registrar Granting or Refusing Service(s) Registration Once registration has been requested, the registrar is able to authenticate the requester based on the host identity included in I2. It then verifies the host identity is authorized to register with the requested service(s), based on local policies. The details of this authorization procedure depend on the type of requested service(s) and on the local policies of the registrar, and are therefore not further specified in this document. Laganier, et al. Expires March 17, 2006 [Page 3] Internet-Draft HIP Registration Extension September 2005 After authorization, the registrar includes in its response (i.e., an R2 or an UPDATE, respectively, depending on whether the registration was requested during the base exchange, or using an existing association) a REG_RESPONSE parameter containing the service(s) type(s) for which it has authorized registration, and zero or more REG_FAILED parameter containing the service(s) type(s) for which it has not authorized registration or registration has failed for other reasons. In particular, REG_FAILED with a failure type of zero indicates the service(s) type(s) that require further credentials for registration. If the registrar requires further authorization and the requester has additional credentials available, the requester SHOULD try to again register with the service after the HIP association has been established. Successful processing of a REG_RESPONSE parameter creates registration state at the requester. In a similar manner, successful processing of a REG_REQUEST parameter creates registration state at the registrar and possibly at the service. Both the requester and registrar can cancel a registration before it expires, if the services afforded by a registration are no longer needed by the requester, or cannot be provided any longer by the registrar (for instance, because its configuration has changed). +-----+ I1 +-----+-----+ | |--------------------->| | S1 | | |<---------------------| | | | | R1(REG_INFO:S1,S2) | +-----+ | RQ | | R | S2 | | | I2(REG_REQ:S1) | | | | |--------------------->| +-----+ | |<---------------------| | S3 | | | R2(REG_RESP:S1) | | | +-----+ +-----+-----+ +-----+ +-----+-----+ | | UPDATE(REG_INFO:S) | | | | |<---------------------| | | | RQ |--------------------->| R | S | | | UPDATE(REG_REQ:S) | | | | | UPDATE(REG_RESP:S) | | | | |<---------------------| | | +-----+ +-----+-----+ Laganier, et al. Expires March 17, 2006 [Page 4] Internet-Draft HIP Registration Extension September 2005 4. Parameter Formats and Processing This section describes the format and processing of the new parameters introduced by the HIP registration extension. 4.1 Encoding Registration Lifetimes with Exponents The HIP registration uses an exponential encoding of registration lifetimes. This allows compact encoding of 255 different lifetime values ranging from 4 ms to 178 days into an 8-bit integer field. The lifetime exponent field used throughout this document MUST be interpreted as representing the lifetime value 2^((lifetime - 64)/8) seconds. 4.2 REG_INFO 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reg Type #3 | | +-+-+-+-+-+-+-+-+ Padding + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (930) ] Length Length in octets, excluding Type, Length, and Padding. Min Lifetime Minimum registration lifetime. Max Lifetime Maximum registration lifetime. Reg Type The registration types offered by the registrar. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Registrars include the parameter in R1 packets in order to announce their registration capabilities. The registrar SHOULD include the parameter in UPDATE packets when its service offering has changed. HIP_SIGNATURE_2 protects the parameter within the R1 packets. Laganier, et al. Expires March 17, 2006 [Page 5] Internet-Draft HIP Registration Extension September 2005 4.3 REG_REQUEST 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reg Type #1 | Reg Type #2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (932) ] Length Length in octets, excluding Type, Length, and Padding. Lifetime Requested registration lifetime. Reg Type The preferred registration types in order of preference. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use A requester includes the REG_REQUEST parameter in I2 or UPDATE packets to register with a registrar's service(s). If the REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT modify the registrations of registration types which are not listed in the parameter. 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. The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. When the registrar is requested a registration which lifetime is either smaller or greater than the minimum or maximum lifetime, respectively, then it SHOULD grant the registration for the minimum or maximum lifetime, respectively. HIP_SIGNATURE protects the parameter within the I2 and UPDATE packets. Laganier, et al. Expires March 17, 2006 [Page 6] Internet-Draft HIP Registration Extension September 2005 4.4 REG_RESPONSE 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reg Type #1 | Reg Type #2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (934) ] Length Length in octets, excluding Type, Length, and Padding. Lifetime Granted registration lifetime. Reg Type The granted registration types in order of preference. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or UPDATE packet only if a registration has successfully completed. The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets, while the requester MUST be able to process one or more REG_RESPONSE parameters in received R2 or UPDATE packets. The requester MUST be prepared to receive any registration lifetime, included ones beyond the minimum and maximum lifetime indicated in the REG_INFO parameter. It MUST NOT expect that the returned lifetime will be the requested one, even in the case that the requested lifetime falls within the announced minimum and maximum. HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets. Laganier, et al. Expires March 17, 2006 [Page 7] Internet-Draft HIP Registration Extension September 2005 4.5 REG_FAILED 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failure Type | Reg Type #1 | Reg Type #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (936) ] Length Length in octets, excluding Type, Length, and Padding. Failure Type Reason for failure. Reg Type The registration types that failed with the specified reason. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Reserved by IANA 201-255 Reserved by IANA for private use A failure type of zero means a registrar requires additional credentials to authorize a requester to register with the registration types listed in the parameter. Other failure types than zero have not been defined. The registrar SHOULD include the REG_FAILED parameter in its R2 or UPDATE packet, if registration with the registration types listed has not completed successfully and a requester is asked to try again with additional credentials. HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets. 5. Establishing and Maintaining Registrations Establishing and/or maintaining a registration may require additional information not available in the transmitted REG_REQUEST or REG_RESPONSE parameters. Therefore, registration type definitions Laganier, et al. Expires March 17, 2006 [Page 8] Internet-Draft HIP Registration Extension September 2005 MAY define dependencies for HIP parameters that are not defined in this document. Their semantics are subject to the specific registration type specifications. The minimum lifetime both registrars and requesters MUST support is 10 seconds, while they SHOULD support a maximum lifetime of 120 seconds, at least. A zero lifetime is reserved for canceling purposes. Requesting a zero lifetime for a registration type equals to canceling the registration of that type. A requester MAY cancel a registration before it expires by sending a REG_REQ to the registrar with a zero lifetime. A registrar SHOULD respond and grant a registration with a zero lifetime. A registrar (and an attached service) MAY cancel a registration before it expires, at its own discretion. However, if it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all registered requesters. 6. Security Considerations This section discusses the threats on the HIP registration protocol, and their implications on the overall security of HIP. In particular, it argues that the extensions described in this document do not introduce additional threats to HIP. The extensions described in this document rely on the HIP base exchange and do not modify its security characteristics, e.g., digital signatures or HMAC. Hence, the only threat introduced by these extensions are related to the creation of soft registration state at the registrar. Registrars act on a voluntary basis and are willing to accept to be a responder and to then create HIP associations with a number of previously unknown hosts. Because they have to store HIP association state anyway, adding a certain amount of time-limited HIP registration state should not introduce and serious additional threats, especially because HIP registrars may cancel registrations at any time at their own discretion, e.g., because of resource constraints during an attack. 7. IANA Considerations This section is to be interpreted according to [RFC2434]. This document updates the IANA Registry for HIP Parameters Types by assigning new HIP Parameter Types values for the new HIP Parameters defined in this document: Laganier, et al. Expires March 17, 2006 [Page 9] Internet-Draft HIP Registration Extension September 2005 o REG_INFO (defined in Section 4.2) o REG_REQUEST (defined in Section 4.3) o REG_RESPONSE (defined in Section 4.4) o REG_FAILED (defined in Section 4.5) IANA needs to open a new registry for registration types. This document does not define registration types but makes the following reservations: Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Adding a new type requires new IETF specifications. IANA needs to open a new registry for registration failure types. This document makes the following failure types definitions and reservations: Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Reserved by IANA 201-255 Reserved by IANA for private use Adding a new type requires new IETF specifications. 8. Acknowledgments The following people (in alphabetical order) have provided thoughtful and helpful discussions and/or suggestions that have helped to improve this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, Pekka Nikander and Hannes Tschofenig. Julien Laganier and Lars Eggert are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. 9. References Laganier, et al. Expires March 17, 2006 [Page 10] Internet-Draft HIP Registration Extension September 2005 9.1 Normative References [I-D.ietf-hip-arch] Moskowitz, R., "Host Identity Protocol Architecture", draft-ietf-hip-arch-02 (work in progress), January 2005. [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 (work in progress), June 2005. [I-D.ietf-hip-rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-03 (work in progress), July 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 9.2 Informative References [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. Authors' Addresses Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany Phone: +49 89 56824 231 Email: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/ Laganier, et al. Expires March 17, 2006 [Page 11] Internet-Draft HIP Registration Extension September 2005 Teemu Koponen Helsinki Institute for Information Technology Advanced Research Unit (ARU) P.O. Box 9800 Helsinki FIN-02015-HUT Finland Phone: +358 9 45 1 Email: teemu.koponen@hiit.fi URI: http://www.hiit.fi/ Lars Eggert NEC Network Laboratories Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 Email: lars.eggert@netlab.nec.de URI: http://www.netlab.nec.de/ Laganier, et al. Expires March 17, 2006 [Page 12] Internet-Draft HIP Registration Extension September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Laganier, et al. Expires March 17, 2006 [Page 13] --Boundary-00=_4DuJDdJZgKi3DsA Content-Type: text/html; charset="iso-8859-1"; name="wdiff.html" Content-Disposition: attachment; filename="wdiff.html" Content-Transfer-Encoding: 7bit wdiff MORGUE/draft-koponen-hip-registration-01.txt draft-ietf-hip-registration-00.txt 



Network Working Group                                        J. Laganier
Internet-Draft                                          DoCoMo Euro-Labs
Expires: January 12, March 17, 2006                                       T. Koponen
                                                                    HIIT
                                                               L. Eggert
                                                                     NEC
                                                           July 11,
                                                      September 13, 2005


          Host Identity Protocol (HIP) Registration Extension
                   draft-koponen-hip-registration-01
                     draft-ietf-hip-registration-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
   This document may not be modified, and derivative works of it may not
   be created, except to publish it as an RFC and to translate it into
   languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, March 17, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document specifies a registration mechanism for the Host
   Identity Protocol (HIP) that allows hosts to register with services,
   such as HIP rendezvous servers or middleboxes.





Laganier, et al.         Expires January 12, March 17, 2006                 [Page 1]

Internet-Draft         HIP Registration Extension              July         September 2005


   such as HIP rendezvous servers or middleboxes.


1.  Introduction

   This document specifies an extension to the Host Identity Protocol
   (HIP) [I-D.ietf-hip-arch].  The extension provides a generic means
   for a host to register with a service.  The service may, for example,
   be a HIP rendezvous server [I-D.ietf-hip-rvs] or a middlebox
   [RFC3234].

   This document makes no further assumptions about the exact type of
   service.  Likewise, this document does not specify any mechanisms to
   discover the presence of specific services or means to interact with
   them after registration.  Future documents may describe those
   operations.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Terminology

   This section defines terminology that is used throughout the
   remainder of this document.  Please note that terminology shared with
   other documents is defined elsewhere [I-D.ietf-hip-arch].

   Requester:
      a HIP node registering with a HIP registrar to request
      registration for a service.

   Registrar:
      a HIP node offering registration for one or more services.

   Service:
      a facility that provides requesters with new capabilities or
      functionalities operating at the HIP layer.  Examples include
      firewalls that support HIP traversal or HIP rendezvous servers.

   Registration:
      shared state stored by a requester and a registrar, allowing the
      requester to benefit from one or more HIP services offered by the
      registrar.  Each registration has an associated finite lifetime.
      Requesters can extend established registrations through re-
      registration (i.e., perform a refresh).







Laganier, et al.        Expires January 12, 2006                [Page 2]

Internet-Draft         HIP Registration Extension              July 2005

   Registration Type:
      an identifier for a given service in the registration protocol.
      For example, the rendezvous service is identified by a specific
      registration type.




Laganier, et al.         Expires March 17, 2006                 [Page 2]

Internet-Draft         HIP Registration Extension         September 2005


3.  HIP Registration Extension Overview

   This document does not specify the means by which a requester
   discovers the availability of a service, or how a requester locates a
   registrar.  After a requester has discovered a registrar, it either
   initiates HIP base exchange or uses an existing HIP association with
   the registrar.  In both cases, registrars use additional parameters
   that the remainder of this document defines to announce their quality
   and grant or refuse registration.  Requesters use corresponding
   parameters to register with the service.  The following sections
   describe the differences between this registration handshake and the
   standard HIP base exchange [I-D.ietf-hip-base] .

3.1  Registrar Announcing its Ability

   A host that is capable and willing to act as a registrar SHOULD
   include a REG_INFO parameter in the R1 packets it sends during all
   base exchanges.  If it is currently unable to provide services due to
   transient conditions, it SHOULD include an empty REG_INFO, i.e., one
   with no services listed.  If services can be provided later, it
   SHOULD send UPDATE packets indicating the current set of services
   available in a new REG_INFO parameter to all hosts it is associated
   with.

3.2  Requester Requesting Registration

   To request registration with a service, a requester constructs and
   includes a corresponding REG_REQUEST parameter in an I2 or UPDATE
   packet it sends to the registrar.

   If the requester has no HIP association established with the
   registrar, it SHOULD already send the REG_REQUEST in the I2 packet.
   This minimizes the number of packets that need to be exchanged with
   the registrar.  A registrar MAY end a HIP association that does not
   carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED
   in the R2.  In this case, no HIP association is created between the
   hosts.  The REG_REQUIRED notification error type is TBD.

3.3  Registrar Granting or Refusing Service(s) Registration

   Once registration has been requested, the registrar is able to
   authenticate the requester based on the host identity included in I2.



Laganier, et al.        Expires January 12, 2006                [Page 3]

Internet-Draft         HIP Registration Extension              July 2005
   It then verifies the host identity is authorized to register with the
   requested service(s), based on local policies.  The details of this
   authorization procedure depend on the type of requested service(s)
   and on the local policies of the registrar, and are therefore not
   further specified in this document.




Laganier, et al.         Expires March 17, 2006                 [Page 3]

Internet-Draft         HIP Registration Extension         September 2005


   After authorization, the registrar includes in its response (i.e., an
   R2 or an UPDATE, respectively, depending on whether the registration
   was requested during the base exchange, or using an existing
   association) a REG_RESPONSE parameter containing the service(s)
   type(s) for which it has authorized registration, and zero or more
   REG_FAILED parameter containing the service(s) type(s) for which it
   has not authorized registration or registration has failed for other
   reasons.  In particular, REG_FAILED with a failure type of zero
   indicates the service(s) type(s) that require further credentials for
   registration.

   If the registrar requires further authorization and the requester has
   additional credentials available, the requester SHOULD try to again
   register with the service after the HIP association has been
   established.

   Successful processing of a REG_RESPONSE parameter creates
   registration state at the requester.  In a similar manner, successful
   processing of a REG_REQUEST parameter creates registration state at
   the registrar and possibly at the service.  Both the requester and
   registrar can cancel a registration before it expires, if the
   services afforded by a registration are no longer needed by the
   requester, or cannot be provided any longer by the registrar (for
   instance, because its configuration has changed).

                 +-----+          I1          +-----+-----+
                 |     |--------------------->|     |  S1 |
                 |     |<---------------------|     |     |
                 |     |  R1(REG_INFO:S1,S2)  |     +-----+
                 | RQ  |                      |  R  |  S2 |
                 |     |    I2(REG_REQ:S1)    |     |     |
                 |     |--------------------->|     +-----+
                 |     |<---------------------|     |  S3 |
                 |     |    R2(REG_RESP:S1)   |     |     |
                 +-----+                      +-----+-----+










Laganier, et al.        Expires January 12, 2006                [Page 4]

Internet-Draft         HIP Registration Extension              July 2005



                 +-----+                      +-----+-----+
                 |     |  UPDATE(REG_INFO:S)  |     |     |
                 |     |<---------------------|     |     |
                 | RQ  |--------------------->|  R  |  S  |
                 |     |  UPDATE(REG_REQ:S)   |     |     |
                 |     |  UPDATE(REG_RESP:S)  |     |     |
                 |     |<---------------------|     |     |
                 +-----+                      +-----+-----+





Laganier, et al.         Expires March 17, 2006                 [Page 4]

Internet-Draft         HIP Registration Extension         September 2005


4.  Parameter Formats and Processing

   This section describes the format and processing of the new
   parameters introduced by the HIP registration extension.

4.1  Encoding Registration Lifetimes with Exponents

   The HIP registration uses an exponential encoding of registration
   lifetimes.  This allows compact encoding of 255 different lifetime
   values ranging from 4 ms to 178 days into an 8-bit integer field.
   The lifetime exponent field used throughout this document MUST be
   interpreted as representing the lifetime value 2^((lifetime - 64)/8)
   seconds.

4.2  REG_INFO

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Min Lifetime  | Max Lifetime  |  Reg Type #1  |  Reg Type #2  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reg Type #3  |                                               |
   +-+-+-+-+-+-+-+-+                 Padding                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type           [ TBD by IANA (930) ]
   Length         Length in octets, excluding Type, Length, and Padding.
   Min Lifetime   Minimum registration lifetime.
   Max Lifetime   Maximum registration lifetime.
   Reg Type       The registration types offered by the registrar.

   Other documents will define specific values for registration types.

   Reg Type        Service
   --------        -------
   0-200           Reserved by IANA
   201-255         Reserved by IANA for private use



Laganier, et al.        Expires January 12, 2006                [Page 5]

Internet-Draft         HIP Registration Extension              July 2005

   Registrars include the parameter in R1 packets in order to announce
   their registration capabilities.  The registrar SHOULD include the
   parameter in UPDATE packets when its service offering has changed.
   HIP_SIGNATURE_2 protects the parameter within the R1 packets.






Laganier, et al.         Expires March 17, 2006                 [Page 5]

Internet-Draft         HIP Registration Extension         September 2005


4.3  REG_REQUEST

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Lifetime    |  Reg Type #1  |  Reg Type #2  |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type        [ TBD by IANA (932) ]
   Length      Length in octets, excluding Type, Length, and Padding.
   Lifetime    Requested registration lifetime.
   Reg Type    The preferred registration types in order of preference.

   Other documents will define specific values for registration types.

   Reg Type        Service
   --------        -------
   0-200           Reserved by IANA
   201-255         Reserved by IANA for private use

   A requester includes the REG_REQUEST parameter in I2 or UPDATE
   packets to register with a registrar's service(s).  If the
   REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT
   modify the registrations of registration types which are not listed
   in the parameter.  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.

   The requester MUST NOT include more than one REG_REQUEST parameter in
   its I2 or UPDATE packets, while the registrar MUST be able to process
   one or more REG_REQUEST parameters in received I2 or UPDATE packets.

   When the registrar is requested a registration which lifetime is
   either smaller or greater than the minimum or maximum lifetime,
   respectively, then it SHOULD grant the registration for the minimum
   or maximum lifetime, respectively.

   HIP_SIGNATURE protects the parameter within the I2 and UPDATE
   packets.









Laganier, et al.         Expires January 12, March 17, 2006                 [Page 6]

Internet-Draft         HIP Registration Extension              July         September 2005


4.4  REG_RESPONSE

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Lifetime    |  Reg Type #1  |  Reg Type #2  |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type        [ TBD by IANA (934) ]
   Length      Length in octets, excluding Type, Length, and Padding.
   Lifetime    Granted registration lifetime.
   Reg Type    The granted registration types in order of preference.

   Other documents will define specific values for registration types.

   Reg Type        Service
   --------        -------
   0-200           Reserved by IANA
   201-255         Reserved by IANA for private use

   The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or
   UPDATE packet only if a registration has successfully completed.

   The registrar MUST NOT include more than one REG_RESPONSE parameter
   in its R2 or UPDATE packets, while the requester MUST be able to
   process one or more REG_REQUEST REG_RESPONSE parameters in received R2 or UPDATE
   packets.

   The requester MUST be prepared to receive any registration lifetime,
   included ones beyond the minimum and maximum lifetime indicated in
   the REG_INFO parameter.  It MUST NOT expect that the returned
   lifetime will be the requested one, even in the case that the
   requested lifetime falls within the announced minimum and maximum.

   HIP_SIGNATURE protects the parameter within the R2 and UPDATE
   packets.













Laganier, et al.         Expires January 12, March 17, 2006                 [Page 7]

Internet-Draft         HIP Registration Extension              July         September 2005


4.5  REG_FAILED

     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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Failure Type  |  Reg Type #1  |  Reg Type #n  |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type          [ TBD by IANA (936) ]
    Length        Length in octets, excluding Type, Length, and Padding.
    Failure Type  Reason for failure.
    Reg Type      The registration types that failed with the specified
                  reason.

    Other documents will define specific values for registration types.

    Reg Type        Service
    --------        -------
    0-200           Reserved by IANA
    201-255         Reserved by IANA for private use

    Failure Type    Reason
    ------------    --------------------------------------------
    0               Registration requires additional credentials
    1               Registration type unavailable
    2-200           Reserved by IANA
    201-255         Reserved by IANA for private use

   A failure type of zero means a registrar requires additional
   credentials to authorize a requester to register with the
   registration types listed in the parameter.  Other failure types than
   zero have not been defined.

   The registrar SHOULD include the REG_FAILED parameter in its R2 or
   UPDATE packet, if registration with the registration types listed has
   not completed successfully and a requester is asked to try again with
   additional credentials.

   HIP_SIGNATURE protects the parameter within the R2 and UPDATE
   packets.

5.  Establishing and Maintaining Registrations

   Establishing and/or maintaining a registration may require additional
   information not available in the transmitted REG_REQUEST or
   REG_RESPONSE parameters.  Therefore, registration type definitions



Laganier, et al.         Expires March 17, 2006                 [Page 8]

Internet-Draft         HIP Registration Extension         September 2005


   MAY define dependencies for HIP parameters that are not defined in
   this document.  Their semantics are subject to the specific
   registration type specifications.

   The minimum lifetime both registrars and requesters MUST support is
   10 seconds, while they SHOULD support a maximum lifetime of 120
   seconds, at least.

   A zero lifetime is reserved for canceling purposes.  Requesting a



Laganier, et al.        Expires January 12, 2006                [Page 8]

Internet-Draft         HIP Registration Extension              July 2005
   zero lifetime for a registration type equals to canceling the
   registration of that type.  A requester MAY cancel a registration
   before it expires by sending a REG_REQ to the registrar with a zero
   lifetime.  A registrar SHOULD respond and grant a registration with a
   zero lifetime.  A registrar (and an attached service) MAY cancel a
   registration before it expires, at its own discretion.  However, if
   it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all
   registered requesters.

6.  Security Considerations

   This section discusses the threats on the HIP registration protocol,
   and their implications on the overall security of HIP.  In
   particular, it argues that the extensions described in this document
   do not introduce additional threats to HIP.

   The extensions described in this document rely on the HIP base
   exchange and do not modify its security characteristics, e.g.,
   digital signatures or HMAC.  Hence, the only threat introduced by
   these extensions are related to the creation of soft registration
   state at the registrar.

   Registrars act on a voluntary basis and are willing to accept to be a
   responder and to then create HIP associations with a number of
   previously unknown hosts.  Because they have to store HIP association
   state anyway, adding a certain amount of time-limited HIP
   registration state should not introduce and serious additional
   threats, especially because HIP registrars may cancel registrations
   at any time at their own discretion, e.g., because of resource
   constraints during an attack.

7.  IANA Considerations

   This section is to be interpreted according to [RFC2434].

   This document updates the IANA Registry for HIP Parameters Types by
   assigning new HIP Parameter Types values for the new HIP Parameters
   defined in this document:




Laganier, et al.         Expires March 17, 2006                 [Page 9]

Internet-Draft         HIP Registration Extension         September 2005


   o  REG_INFO (defined in Section 4.2)

   o  REG_REQUEST (defined in Section 4.3)

   o  REG_RESPONSE (defined in Section 4.4)

   o  REG_FAILED (defined in Section 4.5)

   IANA needs to open a new registry for registration types.  No  This
   document does not define registration types



Laganier, et al.        Expires January 12, 2006                [Page 9]

Internet-Draft         HIP but makes the following
   reservations:

   Reg Type        Service
   --------        -------
   0-200           Reserved by IANA
   201-255         Reserved by IANA for private use

   Adding a new type requires new IETF specifications.

   IANA needs to open a new registry for registration failure types.
   This document makes the following failure types definitions and
   reservations:

   Failure Type    Reason
   ------------    --------------------------------------------
   0               Registration Extension              July 2005


   are defined in this document. requires additional credentials
   1               Registration type unavailable
   2-200           Reserved by IANA
   201-255         Reserved by IANA for private use

   Adding a new type requires new IETF specifications.

8.  Acknowledgments

   The following people (in alphabetical order) have provided thoughtful
   and helpful discussions and/or suggestions that have improved helped to
   improve this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa,
   Pekka Nikander,
   Hannes Tschofenig Nikander and Mika Kousa. Hannes Tschofenig.

   Julien Laganier and Lars Eggert are partly funded by Ambient
   Networks, a research project supported by the European Commission
   under its Sixth Framework Program.  The views and conclusions
   contained herein are those of the authors and should not be
   interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the Ambient Networks
   project or the European Commission.

9.  References



Laganier, et al.         Expires March 17, 2006                [Page 10]

Internet-Draft         HIP Registration Extension         September 2005


9.1  Normative References

   [I-D.ietf-hip-arch]
              Moskowitz, R., "Host Identity Protocol Architecture",
              draft-ietf-hip-arch-02 (work in progress), January 2005.

   [I-D.ietf-hip-base]
              Moskowitz, R., "Host Identity Protocol",
              draft-ietf-hip-base-03 (work in progress), June 2005.

   [I-D.ietf-hip-rvs]
              Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", draft-ietf-hip-rvs-02 draft-ietf-hip-rvs-03 (work in
              progress), June July 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

9.2  Informative References

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.






Laganier, et al.        Expires January 12, 2006               [Page 10]

Internet-Draft         HIP Registration Extension              July 2005


Authors' Addresses

   Julien Laganier
   DoCoMo Communications Laboratories Europe GmbH
   Landsberger Strasse 312
   Munich  80687
   Germany

   Phone: +49 89 56824 231
   Email: julien.ietf@laposte.net
   URI:   http://www.docomolab-euro.com/












Laganier, et al.         Expires March 17, 2006                [Page 11]

Internet-Draft         HIP Registration Extension         September 2005


   Teemu Koponen
   Helsinki Institute for Information Technology
   Advanced Research Unit (ARU)
   P.O. Box 9800
   Helsinki  FIN-02015-HUT
   Finland

   Phone: +358 9 45 1
   Email: teemu.koponen@hiit.fi
   URI:   http://www.hiit.fi/


   Lars Eggert
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 90511 43
   Fax:   +49 6221 90511 55
   Email: lars.eggert@netlab.nec.de
   URI:   http://www.netlab.nec.de/

Appendix A.  Document Revision History

   +-----------+-------------------------------------------------------+
   | Revision  | Comments                                              |
   +-----------+-------------------------------------------------------+
   | 00        | Initial submission.                                   |
   | 01        | Editorial and boilerplate fixes. Modified             |
   |           | terminology. Added security considerations. Changed   |
   |           | requirement keyword on new parameters processing.     |
   +-----------+-------------------------------------------------------+





























Laganier, et al.         Expires January 12, March 17, 2006                [Page 11] 12]

Internet-Draft         HIP Registration Extension              July         September 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Laganier, et al.         Expires January 12, March 17, 2006                [Page 12] 13]
--Boundary-00=_4DuJDdJZgKi3DsA 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=_4DuJDdJZgKi3DsA-- From hipsec-bounces@lists.ietf.org Wed Sep 14 13:04:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFagb-0006cl-I0; Wed, 14 Sep 2005 13:04:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlyp-0005Df-CJ; Fri, 09 Sep 2005 12:43:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13396; Fri, 9 Sep 2005 12:43:56 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDm2R-00076m-TW; Fri, 09 Sep 2005 12:47:44 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EDlyo-0005x6-GE; Fri, 09 Sep 2005 12:43:58 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 09 Sep 2005 12:43:58 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Wed, 14 Sep 2005 13:04:40 -0400 Cc: hip mailing list , Internet Architecture Board , hip chair , RFC Editor Subject: [Hipsec] Document Action: 'Host Identity Protocol Architecture' to Informational RFC 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 IESG has approved the following document: - 'Host Identity Protocol Architecture ' as an Informational RFC This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt Technical Summary This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding. Working Group Summary This document was reviewed in the HIP WG and is being used as the architectural basis for the Experimental documents being developed in that group. Protocol Quality This document has been reviewed for the IESG by Margaret Wasserman. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 15 08:53:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtFU-0003T9-TC; Thu, 15 Sep 2005 08:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtFS-0003Pv-HW for hipsec@megatron.ietf.org; Thu, 15 Sep 2005 08:53:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08465 for ; Thu, 15 Sep 2005 08:53:52 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFtKF-0008Ej-8w for hipsec@ietf.org; Thu, 15 Sep 2005 08:58:52 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 57B2A212C46 for ; Thu, 15 Sep 2005 15:53:34 +0300 (EEST) Message-ID: <43296ECB.8070305@nomadiclab.com> Date: Thu, 15 Sep 2005 15:53:31 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] HIP Base draft & ESP draft 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 uploaded current versions (dated 150905) of both HIP Base and ESP drafts to http://hip4inter.net/drafts.php Like Pekka suggested earlier on the list, we are now trying to get an external review of the drafts and get some comments. Petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Sep 18 03:16:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGtPo-0003Kj-AY; Sun, 18 Sep 2005 03:16:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGtPl-0003Ke-7Z for hipsec@megatron.ietf.org; Sun, 18 Sep 2005 03:16:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09300 for ; Sun, 18 Sep 2005 03:16:40 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGtV8-000314-1a for hipsec@ietf.org; Sun, 18 Sep 2005 03:22:14 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 88815212C46; Sun, 18 Sep 2005 10:16:31 +0300 (EEST) In-Reply-To: References: <20050804050502.GB6084@sbrim-wxp01> <42F89F9F.5070008@zurich.ibm.com> <4321D5E9.9010609@shockey.us> <151701c5b570$052a25a0$0500a8c0@china.huawei.com> <43249A80.3020303@piuha.net> <4324A849.4060509@cs.columbia.edu> <4A763861-D4E9-44DD-A193-8E73EC4E03A7@muada.com> <4A09791C-AF36-4C86-923A-D38343C2E037@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D75ADA9-973D-43CD-A135-EAB089B1748F@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Sun, 18 Sep 2005 09:16:29 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] HIP shortcomings (was something else) 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 [Discussion coming from IETF Discuss list] Iljitsch, > I think HIP is on the right track in some areas, but I don't like > the protocol as such because the overhead is too large, and I think > even though it's fairly radical in some ways, it doesn't go far > enough. With regard to overhead, as we have repeatedly discussed briefly, it would be technically possible to a) design a variant (extension) of HIP that uses light weight mitm- vulnerable authentication, and b) define how to use plain TCP and UDP while when HIP state is there However, there hasn't been enough of interest in the HIP community to specify exactly how. W.r.t. b), I guess some people are waiting for shim6 to converge, and then will define a simple extension for carrying plain TCP and UDP. What comes to a), there was the LHIP (Lightweight HIP) idea that, IMHO, was OK but it never flew since there wasn't enough of interest. > For instance, the first sentence of any new internet architecture > would have to be: one size does NOT fit all. HIP has been carefully designed to be a) extensible and b) optional in the sense that you can decide whether to use it or not in any particular situation. > The assumption that it does has allowed a lot of great work in the > past. For instance, for some time, TCP was able to accommodate the > slowest possible links and the fastest. But that's no longer true, > so now we have to choose between enabling RFC 1323 high performance > options to allow high speed downloads across the globe, or disable > them and allow for header compression to optimize for low speed > links. Unfortunately most operating systems enable the options, > killing header compression, while applications fail to use buffers > that are big enough so long distance high speed downloads aren't > possible either. > > That kind of stuff is very common in today's internet. I agree, and your warning is a fair one. Personally, I can't see where there we would have gone wrong so far, but I am *very* interested in hearing your detailed analysis. > We also need to address the need of intermediate systems to > influence the communication between two endpoints in various ways, > without killing the end-to-end principle wholesale. Exactly! That principle has affected many aspects of HIP design, for example, the ability to add fields *after* the end-to-end signature, to basic principle of carrying SPIs and other traffic selectors in clear in the control packets, etc. We have been trying *very* hard to fulfil that principle, but of course, I am sure we have also made some mistakes in the way. It would be great if you could review the latest protocol spec, now past WG LC and going to cross-area review. We should have -04 of draft-ietf-hip-base out any day now. > Routing, naming, addressing and layering is a big mess in the > current "architecture". (I'm using quotes because all of this > evolved over time without noticeable architectural oversight.) CIDR > was a step in the right direction, OK so far, but ... > but now it's time for the next step: make addresses variable > length. (One size doesn't fit all.) Why this? > Port numbers should be part of the address to allow for easier > filtering. I agree that port numbers are becoming obsolete, but perhaps for other reasons that what you imagine. > Having DNS names is great, but applications shouldn't have to deal > with name to address mappings: we need a new API that hides > addresses from applications that don't have any need to look at them. There I agree again, whole heartedly! But, OTOH, I also think *strongly* that we should work hard to diminish our dependency on DNS names and work actively to create new alternative naming infrastructures, such as CoDNSs (http://www.cs.cornell.edu/people/egs/ beehive/codons.php) or the Handle System (http://www.handle.net/). > HIP does get the locator/identifier idea right. Thanks! > In addition to that, we need to abandon the notion of one single > network with a fixed root. Again, I concur. [From a security point of view, you may be interested in the following paper of ours: Ilari Lehti and Pekka Nikander, "Certifying trust," in Proceedings of the Practice and Theory in Public Key Cryptography (PKC) '98, Yokohama, Japan, Springer-Verlag, February 1998. http:// www.tml.tkk.fi/~pnr/publications/PKC-98.pdf ] > By allowing each point in the network to be the root, and map all > other parts of the network to arbitrary parts of the hierarchy as > seen from a given root, we can impose the constraints required by > many organizations. Interdomain routing needs more link state like > mechanisms in order to get rid of BGP's version of the count to > infinity problem. It also needs to work when the view of the > network is incomplete, while at the same time taking advantage of > additional topological information when available. (This includes > taking advantage of geography in routing.) And interdomain routing > shouldn't be subvertable like it is today. While I think I agree with you, I have to admit that I understand too little about real life routing, and e.g. how to use MPLS for TE and policy routing, to really understand what you are saying. Are there anything more substantial written? Something I could read? > Coming back to IPsec: we need more of this. TLS is broken because > it doesn't protect the underlying TCP session. We need an API that > allows applications to do an IPsec version of "STARTTLS". (It would > be nice if we could do authentication first and then encryption, > unlike it's done today, to get rid of at least SOME of the huge > IPsec overhead: the auth data can then be the encryption IV.) I'd appreciate if you could provide this opinion to the BTNS WG, which is working on some related API issues, and perhaps participate actively there? > In other words: we now need to do everything that we didn't do > until now because it was too hard. I think we need to create a vision of that "everything" and then work out some kind of road map towards that vision, realising that the vision will necessarily change while we are inching towards it. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 21 13:02:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7z3-0000RL-Hf; Wed, 21 Sep 2005 13:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7z1-0000QU-An for hipsec@megatron.ietf.org; Wed, 21 Sep 2005 13:02:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04767 for ; Wed, 21 Sep 2005 13:02:08 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI852-00005U-Dv for hipsec@ietf.org; Wed, 21 Sep 2005 13:08:27 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DFF3E212D1F for ; Wed, 21 Sep 2005 20:01:47 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v734) References: <43317044.9010603@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1CFAEBD0-93DC-4A13-9ED4-0FE3039818D0@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 21 Sep 2005 19:01:45 +0200 To: hipsec@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Fwd: Packages are good [Re: Allocating RFC numbers at time of approval] 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 FYI, from WG chairs list, snipped to contain only the most relevant part. --Pekka Begin forwarded message: > From: Brian E Carpenter > Date: September 21, 2005 16:37:56 GMT+02:00 > To: wgchairs@ietf.org > Subject: Packages are good [Re: Allocating RFC numbers at time of > approval] > > > > When a WG is developing a set of linked drafts, > sending them for IESG review as a package is (when it's > possible) a Good Thing. It allows everybody who reviews > them to do so as a package, it allows issues to be resolved > as a package, and it minimizes reference dependencies > blocking the RFC Editor. And it may even allow them to have > consecutive RFC numbers. > > Brian _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 21 15:50:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAc8-0008Ci-5d; Wed, 21 Sep 2005 15:50:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAbW-00082R-6t; Wed, 21 Sep 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15315; Wed, 21 Sep 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIAhY-0004j8-G8; Wed, 21 Sep 2005 15:56:21 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EIAbR-00064H-R5; Wed, 21 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-registration-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Registration Extension Author(s) : J. Laganier, et al. Filename : draft-ietf-hip-registration-00.txt Pages : 13 Date : 2005-9-21 This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-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-ietf-hip-registration-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-ietf-hip-registration-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-21110658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-registration-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-registration-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-21110658.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Wed Sep 21 19:06:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIDfx-0005JB-Gh; Wed, 21 Sep 2005 19:06:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIDfv-0005HR-Oc for hipsec@megatron.ietf.org; Wed, 21 Sep 2005 19:06:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08721 for ; Wed, 21 Sep 2005 19:06:48 -0400 (EDT) Received: from mail-iinet.icp-qv1-irony3.iinet.net.au ([203.59.1.197] helo=mail-ihug.icp-qv1-irony3.iinet.net.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIDm0-0005nE-Hw for hipsec@ietf.org; Wed, 21 Sep 2005 19:13:11 -0400 Received: from 203-214-85-97.dyn.iinet.net.au (HELO T40) ([203.214.85.97]) by mail-ihug.icp-qv1-irony3.iinet.net.au with ESMTP; 22 Sep 2005 06:47:52 +0800 Message-Id: <4c3na2$ccejki@mail-iinet.icp-qv1-irony3.iinet.net.au> From: "Joseph So" To: Date: Thu, 22 Sep 2005 08:47:45 +1000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW+v0Ee8vUCRQs5QfCTms765wUhEw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: Subject: [Hipsec] Question about "Preferred locator" and Mobility in 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: , Content-Type: multipart/mixed; boundary="===============1854966157==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1854966157== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C5BF52.4E687820" This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C5BF52.4E687820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, I'm studying the mobility management scenario of HIP in different scenarios recently. When I read the ID of Mobility and Multi-homing, in section 3.3.3 Preferred locator, it said that multiple locators for failover only. If a host and its peer have 2 network-interface-cards, can the host create 2 connections from 2 different network cards to its peer (not for the load-balancing, just duplicate the packages, ie 2 connections sending out the same packages at the same time.) by current HIP? If yes, which package I should look in? I have also read the hip-base, but it didn't mention anything about it. Thanks a lot. Joseph ------=_NextPart_000_0047_01C5BF52.4E687820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

        =    I’m studying the mobility management scenario of HIP in different scenarios recently. When I read the ID of Mobility and Multi-homing, in = section 3.3.3 = Preferred locator, it said that multiple locators for failover only. If a host and = its peer have 2 network-interface-cards, can the host create 2 connections = from 2 different network cards to its peer (not for the load-balancing, just = duplicate the packages, ie 2 connections sending out the same packages at the same = time.) by current HIP? If yes, which package I should look in? I have also read = the hip-base, but it didn’t mention anything about = it.

        =    Thanks a lot.

Joseph

------=_NextPart_000_0047_01C5BF52.4E687820-- --===============1854966157== 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 --===============1854966157==-- From hipsec-bounces@lists.ietf.org Wed Sep 21 20:04:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIEaA-0003rn-AH; Wed, 21 Sep 2005 20:04:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIEa8-0003rI-HM for hipsec@megatron.ietf.org; Wed, 21 Sep 2005 20:04:56 -0400 Received: from mail-ihug.icp-qv1-irony1.iinet.net.au (mail-iinet.icp-qv1-irony1.iinet.net.au [203.59.1.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11304 for ; Wed, 21 Sep 2005 20:04:54 -0400 (EDT) Received: from 203-214-85-97.dyn.iinet.net.au (HELO T40) ([203.214.85.97]) by mail-ihug.icp-qv1-irony1.iinet.net.au with ESMTP; 22 Sep 2005 06:21:16 +0800 Message-Id: <4e0raf$3gfiak@iinet-mail.icp-qv1-irony1.iinet.net.au> From: "Joseph So" To: Date: Thu, 22 Sep 2005 08:21:12 +1000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW+v0Ee8vUCRQs5QfCTms765wUhEw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Cc: Subject: [Hipsec] Question about "Preferred locator" and Mobility in 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: , Content-Type: multipart/mixed; boundary="===============0948320595==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0948320595== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C5BF4E.98CDDDF0" This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C5BF4E.98CDDDF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, I'm studying the mobility management scenario of HIP in different scenarios recently. When I read the ID of Mobility and Multi-homing, in section 3.3.3 Preferred locator, it said that multiple locators for failover only. If a host and its peer have 2 network-interface-cards, can the host create 2 connections from 2 different network cards to its peer (not for the load-balancing, just duplicate the packages, ie 2 connections sending out the same packages at the same time.) by current HIP? If yes, which package I should look in? I have also read the hip-base, but it didn't mention anything about it. Thanks a lot. Joseph ------=_NextPart_000_003C_01C5BF4E.98CDDDF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

        =    I’m studying the mobility management scenario of HIP in different scenarios recently. When I read the ID of Mobility and Multi-homing, in = section 3.3.3 = Preferred locator, it said that multiple locators for failover only. If a host and = its peer have 2 network-interface-cards, can the host create 2 connections = from 2 different network cards to its peer (not for the load-balancing, just = duplicate the packages, ie 2 connections sending out the same packages at the same = time.) by current HIP? If yes, which package I should look in? I have also read = the hip-base, but it didn’t mention anything about = it.

        =    Thanks a lot.

Joseph

------=_NextPart_000_003C_01C5BF4E.98CDDDF0-- --===============0948320595== 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 --===============0948320595==-- From hipsec-bounces@lists.ietf.org Thu Sep 22 03:11:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EILFJ-0008Hx-P2; Thu, 22 Sep 2005 03:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EILFH-0008GH-JP for hipsec@megatron.ietf.org; Thu, 22 Sep 2005 03:11:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11539 for ; Thu, 22 Sep 2005 03:11:50 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EILLS-0007hb-59 for hipsec@ietf.org; Thu, 22 Sep 2005 03:18:15 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2F6E4212C46; Thu, 22 Sep 2005 10:11:31 +0300 (EEST) In-Reply-To: <4e0raf$3gfiak@iinet-mail.icp-qv1-irony1.iinet.net.au> References: <4e0raf$3gfiak@iinet-mail.icp-qv1-irony1.iinet.net.au> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [Hipsec] Question about "Preferred locator" and Mobility in HIP Date: Thu, 22 Sep 2005 09:11:29 +0200 To: Joseph So X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 > I=92m studying the mobility management scenario of HIP in different =20= > scenarios recently. When I read the ID of Mobility and Multi-=20 > homing, in section 3.3.3 Preferred locator, it said that multiple =20 > locators for failover only. IIRC, the draft also encourages you to experiment with using multiple =20= locators at the same time. The main issue is that TCP is likely to behave badly if you have lots =20= of packet reordering. > If a host and its peer have 2 network-interface-cards, can the host =20= > create 2 connections from 2 different network cards to its peer =20 > (not for the load-balancing, just duplicate the packages, ie 2 =20 > connections sending out the same packages at the same time.) by =20 > current HIP? If yes, which package I should look in? I have also =20 > read the hip-base, but it didn=92t mention anything about it. I don't know what you mean with packages. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 22 04:34:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIMWm-0005qx-Gm; Thu, 22 Sep 2005 04:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIMWk-0005qs-Ua for hipsec@megatron.ietf.org; Thu, 22 Sep 2005 04:33:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15276 for ; Thu, 22 Sep 2005 04:33:56 -0400 (EDT) Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIMct-0001mv-2f for hipsec@ietf.org; Thu, 22 Sep 2005 04:40:23 -0400 Received: (qmail 12294 invoked by uid 0); 22 Sep 2005 08:33:38 -0000 Received: from 131.170.90.4 by www84.gmx.net with HTTP; Thu, 22 Sep 2005 10:33:38 +0200 (MEST) Date: Thu, 22 Sep 2005 10:33:38 +0200 (MEST) From: "Joseph So" To: Pekka Nikander MIME-Version: 1.0 References: Subject: Re: [Hipsec] Question about "Preferred locator" and Mobility in HIP X-Priority: 3 (Normal) X-Authenticated: #11004853 Message-ID: <21081.1127378018@www84.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA15276 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 Dear Pekka, Thanks for your answer. Please see inline. > --- Urspr=FCngliche Nachricht --- > Von: Pekka Nikander > An: Joseph So > Kopie: > Betreff: Re: [Hipsec] Question about "Preferred locator" and Mobility i= n > HIP > Datum: Thu, 22 Sep 2005 09:11:29 +0200 >=20 > > I=92m studying the mobility management scenario of HIP in different =20 > > scenarios recently. When I read the ID of Mobility and Multi-=20 > > homing, in section 3.3.3 Preferred locator, it said that multiple =20 > > locators for failover only. >=20 > IIRC, the draft also encourages you to experiment with using multiple =20 > locators at the same time. >=20 > The main issue is that TCP is likely to behave badly if you have lots =20 > of packet reordering. >=20 > > If a host and its peer have 2 network-interface-cards, can the host =20 > > create 2 connections from 2 different network cards to its peer =20 > > (not for the load-balancing, just duplicate the packages, ie 2 =20 > > connections sending out the same packages at the same time.) by =20 > > current HIP? If yes, which package I should look in? I have also =20 > > read the hip-base, but it didn=92t mention anything about it. >=20 > I don't know what you mean with packages. For example, Host A got 2 NIC, NIC_A1 and NIC_A2, and Host B got 2 NIC, NIC_B1 and NIC_B2. Is it possible NIC_A1 <=3D> NIC_B1 and NIC_A2<=3D>NIC= _B2 at the same time (Not for the load balancing, these 2 connections are idenitical, sending the same packets.) by current HIP? Thanks a lot (Sorry for my poor English) Joseph >=20 > --Pekka >=20 --=20 Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen f=FCr GMX Partner: http://www.gmx.net/de/go/partner _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 22 04:54:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIMqD-0002QA-SL; Thu, 22 Sep 2005 04:54:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIMqA-0002Q2-TD for hipsec@megatron.ietf.org; Thu, 22 Sep 2005 04:54:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16029 for ; Thu, 22 Sep 2005 04:54:01 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIMwK-0002Eu-F6 for hipsec@ietf.org; Thu, 22 Sep 2005 05:00:27 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 61B57212C46; Thu, 22 Sep 2005 11:53:38 +0300 (EEST) In-Reply-To: <21081.1127378018@www84.gmx.net> References: <21081.1127378018@www84.gmx.net> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Question about "Preferred locator" and Mobility in HIP Date: Thu, 22 Sep 2005 10:53:36 +0200 To: "Joseph So" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 > For example, Host A got 2 NIC, NIC_A1 and NIC_A2, and Host B got > 2 NIC, > NIC_B1 and NIC_B2. Is it possible NIC_A1 <=> NIC_B1 and > NIC_A2<=>NIC_B2 at > the same time (Not for the load balancing, these 2 connections are > idenitical, sending the same packets.) by current HIP? Yes, you can create SAs for A1-B1, A1-B2, A2-B1, and A2-B2 communication. You just need to know the consequences. I don't understand why would you like to double your network traffic. Remember, every packet in the network costs *something* even though the marginal cost of a single packet is typically very close to zero. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec