From hipsec-bounces@lists.ietf.org Mon Aug 01 05:50:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWwH-0006wJ-3T; Mon, 01 Aug 2005 05:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWSp-00071X-2W for hipsec@megatron.ietf.org; Mon, 01 Aug 2005 05:20:07 -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 FAA07728 for ; Mon, 1 Aug 2005 05:20:00 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzWyz-0006Cs-Be for hipsec@ietf.org; Mon, 01 Aug 2005 05:53:22 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id CAA04179 for ; Mon, 1 Aug 2005 02:19:31 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j719Jev00257 for ; Mon, 1 Aug 2005 04:19:40 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 02:19:39 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] base-03 state machine, notify Date: Mon, 1 Aug 2005 02:19:39 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D607E@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: base-03 state machine, notify Thread-Index: AcWNjFaYvk7zFYrjR8ulm42WwZSnawI6ytBo From: "Ahrenholz, Jeffrey M" To: X-OriginalArrivalTime: 01 Aug 2005 09:19:39.0930 (UTC) FILETIME=[24E82FA0:01C5967A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > (4) Under the NOTIFY parameter with INVALID_SYNTAX 7, the draft says >"this status may only be returned for and in an encrypted packet if the >message ID and cryptographic checksum were valid". What is meant by >"message ID"? What about the "cryptographic checksum", is that the HIP >checksum? (nowhere is this referred to as a "cryptographic checksum") >Does this mean we need an ENCRYPTED TLV in the NOTIFY? There hasn't been much response about this unknown/cryptic text, so = instead, how about: INVALID_SYNTAX 7 Indicates that the HIP message received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons. To avoid a denial of service attack using forged messages, this status may only be returned for packets whose HMAC (if present) and SIGNATURE have been verified. This status MUST be sent in=20 response to any error not covered by one of the other=20 status types, and should not contain details to avoid leaking information to someone probing a node. To aid debugging, more detailed error information SHOULD be written to a console or log. -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Aug 01 09:53:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzaj2-0001Ba-JT; Mon, 01 Aug 2005 09:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzaj1-00019i-75 for hipsec@megatron.ietf.org; Mon, 01 Aug 2005 09:53: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 JAA09536 for ; Mon, 1 Aug 2005 09:53:01 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzbFJ-0001bR-27 for hipsec@ietf.org; Mon, 01 Aug 2005 10:26:25 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 29EFA212C72; Mon, 1 Aug 2005 16:52:43 +0300 (EEST) In-Reply-To: <200507310744.j6V7iWl6004438@givry.rennes.enst-bretagne.fr> References: <200507310744.j6V7iWl6004438@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] The HIT prefix once again Date: Mon, 1 Aug 2005 15:52:43 +0200 To: Francis Dupont X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: gabriel montenegro , hipsec@ietf.org, Bob Hinden 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 Bob, Do you want me to put up a slide or two on this at the end of the IPv6 WG tomorrow? Or would it be better to have a more compelling draft (than the one by Francis) first? Francis, I finally had time to read your draft, http://www.ietf.org/internet- drafts/draft-dupont-ipv6-cgpref-01.txt I think you need to have reference to a document that defines how GCIDs are supposed to be used; I didn't see any. Alone I don't see how you draft would make a compelling case. However, going more to the technical level, we may want to share the exactly same name space. AFAICT, the HITs and CBIDs are formed as follows: HIT = prefix | encode(hash(public key)) CBID = prefix | encode(hash(any string)) where, in both cases, there prefix defines the 'encode' and 'hash' functions used. In the HIT case the public key must be understood from the context, and AFAICT in the CBID case the "any string" must also be understood from the context. It also looks like that we can use the exactly same 'encode' and 'hash' functions, as the requirements for them are the same. Initially, we would apparently be just taking the low order bits of the hash as the encoding and use SHA1 as the hash function. Or do you have different requirements? Now, based on that we could share the exactly same name space, i.e., just have a single prefix. One potential complication is that it is much easier to generate arbitrary strings than even short public keys. However, based on my strawperson analysis, that doesn't matter since HIP, by default, expects the HIT to be a hash of a public key and does not accept anything else. Hence, the fact that arbitrary strings are easier to generate that public keys doesn't matter. The biggest difference seems to be on our needs w.r.t the time frame for the assignment. I really think that a temporary assignment with the default of the assignment going back by, say, 2009, would be better. In that way that space does not keep assigned if the experimentation fails and it is not used. On the other hand, if any efforts using the space succeed and the space is being used, the space is there and can be used. Hence, I think we can go for asking a single shared address space. My proposal is to go for a proposal that says: Assign a /5 provisionally for this use, with the next 3 bits reserved for the case that the existing hash algorithm fails, resulting in /8 which is the only part that gets assigned at this time. If the IPv6 WG feels that assigning a /5 or /8 is too much, then we just need to live with that and live with the lower security level. As I said during the f2f meeting, I am planning to write a short draft on this in the near future but would really appreciate help. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Aug 01 12:59:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzddH-0002PZ-JN; Mon, 01 Aug 2005 12:59:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzddG-0002O4-0X for hipsec@megatron.ietf.org; Mon, 01 Aug 2005 12:59:18 -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 MAA23903 for ; Mon, 1 Aug 2005 12:59:15 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dze9Y-0002O0-GY for hipsec@ietf.org; Mon, 01 Aug 2005 13:32:42 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j71GweJ04796; Mon, 1 Aug 2005 18:58:40 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j71Gwfo4009006; Mon, 1 Aug 2005 18:58:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508011658.j71Gwfo4009006@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander Subject: Re: [Hipsec] The HIT prefix once again In-reply-to: Your message of Mon, 01 Aug 2005 15:52:43 +0200. Date: Mon, 01 Aug 2005 18:58:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: gabriel montenegro , hipsec@ietf.org, Bob Hinden X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org In your previous mail you wrote: I finally had time to read your draft, http://www.ietf.org/internet- drafts/draft-dupont-ipv6-cgpref-01.txt I think you need to have reference to a document that defines how GCIDs are supposed to be used; => the I-D (submitted some weeks after the cgpref one by Gabriel, holidays and deadlines...) is draft-dupont-mip6-privacyext-02.txt I didn't see any. Alone I don't see how you draft would make a compelling case. => there should be a reference to a HIP I-D too. However, going more to the technical level, we may want to share the exactly same name space. => this was I've believed. AFAICT, the HITs and CBIDs are formed as follows: HIT = prefix | encode(hash(public key)) CBID = prefix | encode(hash(any string)) where, in both cases, there prefix defines the 'encode' and 'hash' functions used. In the HIT case the public key must be understood from the context, and AFAICT in the CBID case the "any string" must also be understood from the context. => the 'any string' is in fact PublicKey | imprint_128 It also looks like that we can use the exactly same 'encode' and 'hash' functions, as the requirements for them are the same. => hash() is SHA-1 and encore() is to take the first 112 (128 - prefixlen) first bits. But I agree, this doesn't matter. Initially, we would apparently be just taking the low order bits of the hash as the encoding and use SHA1 as the hash function. Or do you have different requirements? => I've hear it is better to take first bits, at least this is true for pseudo-random numbers... Now, based on that we could share the exactly same name space, i.e., just have a single prefix. One potential complication is that it is much easier to generate arbitrary strings than even short public keys. However, based on my strawperson analysis, that doesn't matter since HIP, by default, expects the HIT to be a hash of a public key and does not accept anything else. Hence, the fact that arbitrary strings are easier to generate that public keys doesn't matter. => we can share the same space if it is always to recognize the case from the context, something which seems to be true. The biggest difference seems to be on our needs w.r.t the time frame for the assignment. I really think that a temporary assignment with the default of the assignment going back by, say, 2009, would be better. In that way that space does not keep assigned if the experimentation fails and it is not used. On the other hand, if any efforts using the space succeed and the space is being used, the space is there and can be used. => this should be part of the negociation. If it makes easier to get a shorter prefix why not? Hence, I think we can go for asking a single shared address space. My proposal is to go for a proposal that says: Assign a /5 provisionally for this use, with the next 3 bits reserved for the case that the existing hash algorithm fails, resulting in /8 which is the only part that gets assigned at this time. If the IPv6 WG feels that assigning a /5 or /8 is too much, then we just need to live with that and live with the lower security level. As I said during the f2f meeting, I am planning to write a short draft on this in the near future but would really appreciate help. => the cgpref I-D is very open but we should not try to defend it as itself, just to defend the idea and to get an IPv6 WG item about it. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 02 03:14:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzqz5-0001WM-Sk; Tue, 02 Aug 2005 03:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzdWD-00007e-Ba for hipsec@megatron.ietf.org; Mon, 01 Aug 2005 12:52: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 MAA23583 for ; Mon, 1 Aug 2005 12:51:58 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dze2W-00027w-Lp for hipsec@ietf.org; Mon, 01 Aug 2005 13:25:25 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j71GpvQg020066; Mon, 1 Aug 2005 19:51:57 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Aug 2005 19:51:57 +0300 Received: from l5131412.nokia.com ([172.25.154.244]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Aug 2005 19:51:56 +0300 Message-Id: <6.2.1.2.2.20050801094928.02d0f9e8@daebe102.noe.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 01 Aug 2005 09:51:53 -0700 To: "Pekka Nikander" From: Bob Hinden Subject: Re: [Hipsec] The HIT prefix once again In-Reply-To: References: <200507310744.j6V7iWl6004438@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Aug 2005 16:51:56.0956 (UTC) FILETIME=[53D5BDC0:01C596B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-Mailman-Approved-At: Tue, 02 Aug 2005 03:14:42 -0400 Cc: gabriel montenegro , hipsec@ietf.org, Brian Haberman , Bob Hinden 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, At 06:52 AM 08/01/2005, Pekka Nikander wrote: >Bob, > >Do you want me to put up a slide or two on this at the end of the >IPv6 WG tomorrow? Or would it be better to have a more compelling >draft (than the one by Francis) first? I talked about it with Brian Haberman and we both think the agenda is already too tight and it might generate a long unfocused discussion. We think it would be better to write the draft and then ask for comments and discussion. Thanks, Bob >Francis, > >I finally had time to read your draft, http://www.ietf.org/internet- >drafts/draft-dupont-ipv6-cgpref-01.txt I think you need to have >reference to a document that defines how GCIDs are supposed to be >used; I didn't see any. Alone I don't see how you draft would make a >compelling case. > >However, going more to the technical level, we may want to share the >exactly same name space. > >AFAICT, the HITs and CBIDs are formed as follows: > > HIT = prefix | encode(hash(public key)) > > CBID = prefix | encode(hash(any string)) > >where, in both cases, there prefix defines the 'encode' and 'hash' >functions used. In the HIT case the public key must be understood >from the context, and AFAICT in the CBID case the "any string" must >also be understood from the context. It also looks like that we can >use the exactly same 'encode' and 'hash' functions, as the >requirements for them are the same. Initially, we would apparently >be just taking the low order bits of the hash as the encoding and use >SHA1 as the hash function. Or do you have different requirements? > >Now, based on that we could share the exactly same name space, i.e., >just have a single prefix. One potential complication is that it is >much easier to generate arbitrary strings than even short public >keys. However, based on my strawperson analysis, that doesn't matter >since HIP, by default, expects the HIT to be a hash of a public key >and does not accept anything else. Hence, the fact that arbitrary >strings are easier to generate that public keys doesn't matter. > >The biggest difference seems to be on our needs w.r.t the time frame >for the assignment. I really think that a temporary assignment with >the default of the assignment going back by, say, 2009, would be >better. In that way that space does not keep assigned if the >experimentation fails and it is not used. On the other hand, if any >efforts using the space succeed and the space is being used, the >space is there and can be used. > >Hence, I think we can go for asking a single shared address space. >My proposal is to go for a proposal that says: > > Assign a /5 provisionally for this use, with the next 3 bits reserved > for the case that the existing hash algorithm fails, resulting in > /8 which is the only part that gets assigned at this time. > > If the IPv6 WG feels that assigning a /5 or /8 is too much, then we > just need to live with that and live with the lower security level. > >As I said during the f2f meeting, I am planning to write a short >draft on this in the near future but would really appreciate help. > >--Pekka > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 02 04:57:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsaN-0007hN-Nu; Tue, 02 Aug 2005 04:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsaL-0007hI-Rd for hipsec@megatron.ietf.org; Tue, 02 Aug 2005 04:57: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 EAA00918 for ; Tue, 2 Aug 2005 04:57:15 -0400 (EDT) Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzt6m-0003QD-JV for hipsec@ietf.org; Tue, 02 Aug 2005 05:30:50 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id UAA19591 for ; Tue, 2 Aug 2005 20:57:02 +1200 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: hipsec@ietf.org From: Andrew McGregor Date: Tue, 2 Aug 2005 10:55:31 +0200 X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Reference relationships in hip documents 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 Bill Fenner prepared a set of graphs describing the status of references in working group documents. I think these may help in tidying up the references in those documents that just passed last call. The HIP group graphs are: http://rtg.ietf.org/~fenner/ietf/deps/viz/hip.pdf http://rtg.ietf.org/~fenner/ietf/deps/viz/hip-norm.pdf (where the second covers only apparently normative references) There are limitations in the completeness here, so don't take these as definitive. The index is at: http://rtg.ietf.org/~fenner/ietf/deps/viz/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 02 08:02:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvTG-0001nk-2N; Tue, 02 Aug 2005 08:02:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvTB-0001nB-Ti for hipsec@megatron.ietf.org; Tue, 02 Aug 2005 08:02:08 -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 IAA13530 for ; Tue, 2 Aug 2005 08:02:04 -0400 (EDT) Received: from pegasus.hiit.fi ([212.68.1.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzvze-00049q-7F for hipsec@ietf.org; Tue, 02 Aug 2005 08:35:39 -0400 Received: from [128.214.113.174] (odysse.hiit.fi [128.214.113.174]) by pegasus.hiit.fi (Postfix) with ESMTP id ECA23220057; Tue, 2 Aug 2005 15:01:39 +0300 (EEST) From: Diego Beltrami To: Herbert Xu Content-Type: multipart/mixed; boundary="=-cxEtPhsKh15+QDSHjSKR" Organization: HIIT Message-Id: <1122984099.1214.142.camel@odysse> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 02 Aug 2005 15:01:39 +0300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cc1c558da2accc0f39b338f00bd6728 Cc: netdev@oss.sgi.com, infrahip@HIIT.FI, hipl-users@freelists.org, hipsec@ietf.org Subject: [Hipsec] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: diego.beltrami@HIIT.FI 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 --=-cxEtPhsKh15+QDSHjSKR Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, after sending the first version of BEET patch and having received a valuable feedback and after the discussion based upon the BEET design, we now send the new BEET patch which allows for BEET to work without the inter-family transform (i.e. inner address family different than outer address family). The implementation of such a patch is based on the draft you can find at the following URL: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt The patch is attached to the email, but, in case it gives some problems in applying it, you may also find it at the following URL: http://infrahip.hiit.fi/beet/beet-patch-v2.0-2.6.12.2 As it was originally designed the BEET patch at the moment works for only ESP protocol. As Pekka Nikader mentioned in one reply [1]: "[...] defining BEET mode for AH might be pretty tricky. [...] it probably would require some careful thinking to define the exact semantics, like what addresses (inner or outer) are covered by the AH integrity protection, what does the integrity protection really assert, etc. ". As previously written, the inter-family transform has been left out at the moment since the xfrm architecture doesn't support it. As a result, as soon as the xfrm architecture will be enhanced, the inter-family case will be properly included as, for example, it can be useful for supporting HIP over IPv4 network. But, as already mentioned, this would require more work in properly designing the xfrm architecture (thing which we consider necessary in order to make xfrm as generic as possible). On the behalf of the BEET development team, Signed-off-by: Diego Beltrami Reference: [1] http://marc.theaimsgroup.com/?l=linux-netdev&m=112265207304302&w=2 --=-cxEtPhsKh15+QDSHjSKR Content-Disposition: attachment; filename=beet-patch-v2.0-2.6.12.2 Content-Type: text/plain; name=beet-patch-v2.0-2.6.12.2; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit --- linux-2.6.12.2-orig/Documentation/README.BEET +++ linux-2.6.12.2/Documentation/README.BEET @@ -0,0 +1,296 @@ +Linux BEET-mode ESP patch + +Authors: Miika Komu + Kristian Slavov + Jeff Ahrenholz + Abhinav Pathak + Diego Beltrami + +Changelog: May 25, 2005 this document created + + +Description +----------- +This patch extends the native Linux 2.6 kernel IPsec to support +Bound-End-to-End-Tunnel (BEET) mode for ESP: + +Abstract + + This document specifies a new mode, called Bound End-to-End Tunnel + (BEET) mode, for IPsec ESP. The new mode augments the existing ESP + tunnel and transport modes. For end-to-end tunnels, the new mode + provides limited tunnel mode semantics without the regular tunnel + mode overhead. The mode is intended to support new uses of ESP, + including mobility and multi-address multi-homing. + +http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt + +BEET mode architecture +---------------------- + +Below are some control flow diagrams to illustrate how BEET works. + +Sending (inner IPv4, outer IPv4)(4-4) +===================================== +inet_sendmsg + raw_sendmsg + ip_route_output_flow + __ip_route_output_key + xfrm_lookup + flow_cache_lookup + xfrm_policy_lookup // lookup IPsec policy + xfrm_find_bundle // lookup IPsec SA + __xfrm_selector_match + xfrm_tmpl_resolve // only if bundle was not found! + xfrm_state_find + xfrm_bundle_create // create output (dst) chain if bundle was not found + __xfrm4_bundle_create + ip_push_pending_frames + dst_output(skb) //this calls skb->dst->output(); + xfrm4_output //This finally returns 4 (NET_XMIT_BYPASS) to dst_output(); + xfrm4_encap + esp_output + xfrm_beet_output //change the ip header to outer. + dst_output(skb) + ip_output + ip_finish_output Or ip_fragment //depending on size of packet + // Returns 0 to dst_output(); which makes dst_output to come out of infinite loop. + dev_queue_xmit + + +Receiving (inner IPv4, outer IPv4)(4-4) +=========== + +net_rx_action() +e1000_clean() // dependent on network hardware +e1000_clean_rx_irq() +netif_receive_skb() + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ip_rcv() + nf_hook() + ip_rcv_finish() + ip_route_input() + dst_input()->ip_forward() or ip_input() + ip_input // remove the IPv4 header + ip_input_finish + ret = ipprot->handler(&skb, &nhoff); + xfrm4_rcv() + xfrm4_rcv_encap() + xfrm4_parse_spi() + xfrm_state_lookup() // lookup IPsec SA + xfrm_beet_input(skb, x) //To change to inner IP header. + nexthdr = x->type->input(x, xfrm.decap, skb) // == esp_input + esp_input() // process ESP based on inner address + returns 0 ; + /* beet handling in xfrm_rcv_spi */ + netif_rx() + // ip_input_finish returns 0 + // netif_receive_skb returns 0 +netif_receive_skb //Now we have an IPv4 packet. So the input flow is for v4 packet. + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ip_rcv() + nf_hook() //This calls ip_rcv_finish(skb) + ip_rcv_finish() //Here the skb->dst is NULL and so is filled for the input side. + ip6_route_input() + dst_input()->ip_forward() or ip_input() + ip_input // remove the IPv4 header + ip_input_finish + ... + ... + ... + +Sending (inner IPv6, outer IPv6)(6-6) +============= + +(When sending the first packet!) + +inet_sendmsg + rawv6_sendmsg + ip6_dst_lookup + ip6_route_output + xfrm_lookup + flow_cache_lookup + xfrm_policy_lookup // lookup IPsec policy + xfrm_find_bundle // lookup IPsec SA + __xfrm_selector_match + xfrm_tmpl_resolve // only if bundle was not found! + xfrm_state_find + xfrm_bundle_create // create output (dst) chain if bundle was not found + __xfrm6_bundle_create + rawv6_push_pending_frames + ip6_push_pending_frames + dst_output(skb) + xfrm6_output + xfrm6_encap + esp6_output + xfrm_beet_output + dst_output(skb) + ip6_output + ip6_output2 + ip6_output_finish + dev_queue_xmit + +when are these called? + ip6_xmt() + dst_output() + + +Receiving (inner IPv6, outer IPv6)(6-6) +=========== + +net_rx_action() +e1000_clean() // dependent on network hardware +e1000_clean_rx_irq() +netif_receive_skb() + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ipv6_rcv() // skb len = 140 + nf_hook_slow() + ip6_rcv_finish() + ip6_route_input() + dst_input()->ip6_forward() or ip6_input() + ip6_input // remove the IPv6 header + ip6_input_finish // calls recursively the ->handler = xfrm6_rcv + ret = ipprot->handler(&skb, &nhoff); // handler = xfrm6_rcv_spi + xfrm6_rcv() + xfrm6_rcv_spi() + xfrm_parse_spi() + xfrm_state_lookup() // lookup IPsec SA + xfrm_beet_input(skb, x) //To change to inner IP header. + nexthdr = x->type->input(x, xfrm.decap, skb) // == esp6_input + esp6_input() // process ESP + returns 58 (ICMPv6) //returns the nexthdr in the ipv6 packet. + /* beet handling in xfrm_rcv_spi */ + netif_rx() + // ip6_input_finish returns 0 + // netif_receive_skb returns 0 +netif_receive_skb + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ipv6_rcv() // skb len = 104 + nf_hook_slow() + ip6_rcv_finish() + ip6_route_input() + dst_input()->ip6_forward() or ip6_input() + ip6_input // remove the IPv6 header + ip6_input_finish + xfrm6_policy_check() + .. + __xfrm_policy_check + ret = ipprot->handler(&skb, &nhoff); // handler = xfrm6_rcv_spi +tcp_v6_rcv() // or icmpv6_rcv(), anyway, deliver to upper layer + + +output path +ip6_datagram_connect() + ip6_dst_lookup() // success + xfrm_lookup() // lookup policy using inner IP, matching selectors in SP and + flow information + xfrm_sk_policy_lookup() // success + flow_cache_lookup() // success + xfrm_find_bundle() // check for a bundle, if found use it, or create new + xfrm_tmpl_resolve() // when creating new, search for SA for each transform + // once valid SA found, use it to create bundle and link + // to SP. modify skbuff's dst-pointer pointing to next + // xfrmX_output(), after encaps/trans dst is consulted + // to route the packet + xfrm_state_find() // + xfrm_selector_match() // + km_query() // + + + + app app + | | + inner inner + \ / + - / + \ / + \--outer outer--/ + \ / + \======/ + + +Files changed +------------- +This is a list of changes made by the BEET patch. + +include/linux/ipsec.h + - IPSEC_MODE_BEET added + This is the new type of SA that may be created. + XXX note: are we overusing XFRM_MODE_BEET where IPSEC_MODE_BEET should be + used instead? + +include/linux/xfrm.h + - enum XFRM_MODE_{TRANSPORT|TUNNEL|BEET} added + Mode needed to distinguish from tunnel mode in xfrm code. + +include/net/xfrm.h + - u16 beet_family added to struct xfrm_state + For the outgoing SA, this is the family of the outer address. + For the incoming SA, this is the family of the inner address. + - unsigned short family added to struct xfrm_tmpl + family is required because the family may differ from the one in the selector + - possible change to xfrm_selector_match() (commented out) + +net/ipv4/xfrm4_input.c + - in xfrm4_rcv_encap() change the + ip header to inner before going for esp test. + - in xfrm4_rcv_encap() check x->props.mode for XFRM_MODE_TUNNEL, _BEET + checks address family (x->props.beet_family), and makes final adjustments + to packet before requeing it. + +net/ipv4/xfrm4_output.c + - xfrm4_encap(), note to fix the BEET case, like xfrm6_encap + - xfrm4_output() changes the ip header + +net/ipv4/esp4.c + - in esp_init_state(), check if x->props.mode == XFRM_MODE_TUNNEL, + then x->props.header_len += sizeof(struct ipv6hdr), not if (x->props.mode) + +net/ipv6/esp6.c + - in esp6_init_state(), check if x->props.mode == XFRM_MODE_TUNNEL, + then x->props.header_len += sizeof(struct ipv6hdr), not if (x->props.mode) + +net/ipv6/xfrm6_input.c + - xfrm6-rcv_spi(), changes the + inner ip header before sending to esp decapsulation. + - in xfrm6_rcv_spi(), handle x->props.mode = XFRM_MODE_BEET + checks address family (x->props.beet_family), makes final adjustments to + packet before requeing it. + +net/ipv6/xfrm6_output.c + - xfrm6_encap() add ipv4 header vars, check if (x->props.mode==XFRM_MODE_BEET) + makes space for appropriate esp header and sends to espX_output where X depends + on inner family of beet. + - xfrm6_output() change if(x->props.mode) to (x->props.mode==XFRM_MODE_TUNNEL) + After esp calculations the ip header is changed + to outer ip header. + +net/ipv6/xfrm6_policy.c + (on output...) + - in __xfrm6_bundle_create() added remotebeet, localbeet vars, + get the IPv6 headers from xfrm[i]->id.daddr (remote) and + xfrm[i]->props.saddr (local) + copy IPv4 or IPv6 addresses from remote/localbeet to fl_tunnel.fl4/6_dst/src + then do xfrm_dst_lookup() passing in xfrm[i]->props.beet_family + +net/key/af_key.c + - commented-out code in pfkey_msg2xfrm_state(): + check x->props.beet_family for x->props.family? + + - parse_ipsecrequest() check if (t->mode==IPSEC_MODE_TUNNEL-1) + handle if (t->mode==IPSEC_MODE_BEET-1) + populate t->saddr.a4 or t->saddr.a6, t->family, etc + This supports adding a new type of beet mode SA. + +net/xfrm/Kconfig + - added XFRM_BEET config variable option and text + This allows you to compile BEET mode into your kernel. + +net/xfrm/xfrm_policy.c + - note from Miika - fns added just for testing, removed for BEET + ipv6_addr_is_hit(), hip_xfrm_handler_notify(), hip_xfrm_handler_acquire(), + hip_xfrm_handler_policy_notify(), hip_register_xfrm_km_handler(), etc --- linux-2.6.12.2-orig/include/linux/ipsec.h +++ linux-2.6.12.2/include/linux/ipsec.h @@ -13,6 +13,9 @@ IPSEC_MODE_ANY = 0, /* We do not support this for SA */ IPSEC_MODE_TRANSPORT = 1, IPSEC_MODE_TUNNEL = 2 +#ifdef CONFIG_XFRM_BEET + ,IPSEC_MODE_BEET = 3 +#endif }; enum { --- linux-2.6.12.2-orig/include/linux/xfrm.h +++ linux-2.6.12.2/include/linux/xfrm.h @@ -102,6 +102,15 @@ XFRM_SHARE_UNIQUE /* Use once */ }; +enum +{ + XFRM_MODE_TRANSPORT = 0, + XFRM_MODE_TUNNEL +#ifdef CONFIG_XFRM_BEET + ,XFRM_MODE_BEET +#endif +}; + /* Netlink configuration messages. */ enum { XFRM_MSG_BASE = 0x10, --- linux-2.6.12.2-orig/include/net/xfrm.h +++ linux-2.6.12.2/include/net/xfrm.h @@ -113,6 +113,14 @@ xfrm_address_t saddr; int header_len; int trailer_len; +#ifdef CONFIG_XFRM_BEET + /* beet_family_out = family of outer addresses + * beet_family_in = family of inner addresses + */ + u16 beet_family_in; + u16 beet_family_out; + +#endif } props; struct xfrm_lifetime_cfg lft; @@ -241,6 +249,12 @@ /* Source address of tunnel. Ignored, if it is not a tunnel. */ xfrm_address_t saddr; +/* family of the addresses. In BEET-mode the family may differ from + the one in selector */ +#ifdef CONFIG_XFRM_BEET + unsigned short family; +#endif + __u32 reqid; /* Mode: transport/tunnel */ @@ -835,6 +849,12 @@ extern void xfrm6_tunnel_free_spi(xfrm_address_t *saddr); extern u32 xfrm6_tunnel_spi_lookup(xfrm_address_t *saddr); extern int xfrm6_output(struct sk_buff *skb); +#ifdef CONFIG_XFRM_BEET +extern struct xfrm_state * xfrm_lookup_bydst(u8 mode, xfrm_address_t *daddr, xfrm_address_t *saddr, unsigned short family); +extern int xfrm_beet_output(struct sk_buff *skb); +extern int xfrm_beet_input(struct sk_buff *skb, struct xfrm_state *x); + +#endif #ifdef CONFIG_XFRM extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type); --- linux-2.6.12.2-orig/net/ipv4/esp4.c +++ linux-2.6.12.2/net/ipv4/esp4.c @@ -1,3 +1,13 @@ +/* + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * + */ + #include #include #include @@ -23,7 +33,7 @@ struct iphdr *top_iph; struct ip_esp_hdr *esph; struct crypto_tfm *tfm; - struct esp_data *esp; + struct esp_data *esp = x->data; struct sk_buff *trailer; int blksize; int clen; @@ -31,7 +41,15 @@ int nfrags; /* Strip IP+ESP header. */ - __skb_pull(skb, skb->h.raw - skb->data); +#ifdef CONFIG_XFRM_BEET + int hdr_len = skb->h.raw - skb->data + sizeof(*esph) + esp->conf.ivlen; + if (x->props.mode == XFRM_MODE_BEET) + __skb_pull(skb, hdr_len); + else + __skb_pull(skb, skb->h.raw - skb->data); +#else + __skb_pull(skb, skb->h.raw - skb->data); +#endif /* Now skb is pure payload to encrypt */ err = -ENOMEM; @@ -39,7 +57,6 @@ /* Round to block size */ clen = skb->len; - esp = x->data; alen = esp->auth.icv_trunc_len; tfm = esp->conf.tfm; blksize = (crypto_tfm_alg_blocksize(tfm) + 3) & ~3; @@ -59,7 +76,14 @@ *(u8*)(trailer->tail + clen-skb->len - 2) = (clen - skb->len)-2; pskb_put(skb, trailer, clen - skb->len); +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) + __skb_push(skb, hdr_len); + else + __skb_push(skb, skb->data - skb->nh.raw); +#else __skb_push(skb, skb->data - skb->nh.raw); +#endif top_iph = skb->nh.iph; esph = (struct ip_esp_hdr *)(skb->nh.raw + top_iph->ihl*4); top_iph->tot_len = htons(skb->len + alen); @@ -428,7 +452,11 @@ if (crypto_cipher_setkey(esp->conf.tfm, esp->conf.key, esp->conf.key_len)) goto error; x->props.header_len = sizeof(struct ip_esp_hdr) + esp->conf.ivlen; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) +#else if (x->props.mode) +#endif x->props.header_len += sizeof(struct iphdr); if (x->encap) { struct xfrm_encap_tmpl *encap = x->encap; --- linux-2.6.12.2-orig/net/ipv4/xfrm4_input.c +++ linux-2.6.12.2/net/ipv4/xfrm4_input.c @@ -7,6 +7,13 @@ * Derek Atkins * Add Encapsulation support * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -78,6 +85,25 @@ goto drop_unlock; xfrm_vec[xfrm_nr].decap.decap_type = encap_type; + +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) { + /* Change the outer header with the inner data */ + if (x->props.beet_family_in == AF_INET && x->props.beet_family_out == AF_INET){ + /* Inner = 4, Outer = 4 */ + struct iphdr *iph = (struct iphdr *)skb->nh.iph; + iph->daddr = x->sel.daddr.a4; + iph->saddr = x->sel.saddr.a4; + iph->ttl--; + iph->tot_len = htons(skb->len); + iph->frag_off = htons(IP_DF); + iph->check = 0; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + + } else + BUG_ON(1); + } +#endif if (x->type->input(x, &(xfrm_vec[xfrm_nr].decap), skb)) goto drop_unlock; @@ -96,7 +122,11 @@ iph = skb->nh.iph; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) { +#else if (x->props.mode) { +#endif if (iph->protocol != IPPROTO_IPIP) goto drop; if (!pskb_may_pull(skb, sizeof(struct iphdr))) @@ -115,9 +145,35 @@ decaps = 1; break; } +#ifdef CONFIG_XFRM_BEET + else if (x->props.mode == XFRM_MODE_BEET) { + struct iphdr *iph = skb->nh.iph; + int size = sizeof(struct iphdr); + + if (skb_cloned(skb) && + pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) + goto drop; - if ((err = xfrm_parse_spi(skb, skb->nh.iph->protocol, &spi, &seq)) < 0) + skb_push(skb, size); + + memmove(skb->data, skb->nh.raw, size); + skb->mac.raw = memmove(skb->data - skb->mac_len, + skb->mac.raw, skb->mac_len); + skb->nh.raw = skb->data; + iph->tot_len = htons(skb->len); + iph->check = 0; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + skb->protocol = htons(ETH_P_IP); + dst_release(skb->dst); + skb->dst = NULL; + decaps = 1; + + break; + } +#endif + if ((err = xfrm_parse_spi(skb, skb->nh.iph->protocol, &spi, &seq)) < 0) goto drop; + } while (!err); /* Allocate new secpath or COW existing one. */ --- linux-2.6.12.2-orig/net/ipv4/xfrm4_output.c +++ linux-2.6.12.2/net/ipv4/xfrm4_output.c @@ -6,6 +6,14 @@ * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -26,7 +34,8 @@ * check * * On exit, skb->h will be set to the start of the payload to be processed - * by x->type->output and skb->nh will be set to the top IP header. + * by x->type->output and skb->nh, as well as skb->data, will point to + * the top IP header. */ static void xfrm4_encap(struct sk_buff *skb) { @@ -35,15 +44,36 @@ struct iphdr *iph, *top_iph; iph = skb->nh.iph; - skb->h.ipiph = iph; +#ifdef CONFIG_XFRM_BEET + /* + * This is because otherwise the BEET patch crashes in any case with Inner=4 + */ + if (x->props.mode != XFRM_MODE_BEET) + skb->h.ipiph = iph; +#else + skb->h.ipiph = iph; +#endif skb->nh.raw = skb_push(skb, x->props.header_len); top_iph = skb->nh.iph; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TRANSPORT) { +#else if (!x->props.mode) { +#endif + skb->h.raw += iph->ihl*4; memmove(top_iph, iph, iph->ihl*4); return; +#ifdef CONFIG_XFRM_BEET + } else if (x->props.mode == XFRM_MODE_BEET) { + + skb->h.raw = skb->data + sizeof(struct iphdr); + memmove(top_iph, iph, iph->ihl*4); + return; + +#endif /* CONFIG_XFRM_BEET */ } top_iph->ihl = 5; @@ -103,7 +133,11 @@ goto error_nolock; } +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) { +#else if (x->props.mode) { +#endif err = xfrm4_tunnel_check_size(skb); if (err) goto error_nolock; @@ -120,6 +154,21 @@ if (err) goto error; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) { + /* Change the outer header */ + if (x->props.beet_family_in == AF_INET && x->props.beet_family_out == AF_INET){ + struct iphdr *iph = (struct iphdr*)skb->data; + iph->saddr = x->props.saddr.a4; + iph->daddr = x->id.daddr.a4; + skb->local_df = 1; //I am a bit unsure on how to implement this -Abi + iph->check = 0; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + } else + BUG_ON(1); + } +#endif + x->curlft.bytes += skb->len; x->curlft.packets++; --- linux-2.6.12.2-orig/net/ipv4/xfrm4_policy.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-2.6.12.2/net/ipv4/xfrm4_policy.c 2005-08-01 15:05:26.000000000 +0300 @@ -6,6 +6,14 @@ * YOSHIFUJI Hideaki @USAGI * Split up af-specific portion * + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -66,6 +74,12 @@ } } }; +#ifdef CONFIG_XFRM_BEET + union { + struct in6_addr *in6; + struct in_addr *in; + } remotebeet, localbeet; +#endif int i; int err; int header_len = 0; @@ -78,6 +92,9 @@ struct dst_entry *dst1 = dst_alloc(&xfrm4_dst_ops); struct xfrm_dst *xdst; int tunnel = 0; +#ifdef CONFIG_XFRM_BEET + unsigned short beet_family = 0; +#endif if (unlikely(dst1 == NULL)) { err = -ENOBUFS; @@ -98,11 +115,26 @@ dst1->next = dst_prev; dst_prev = dst1; +#ifdef CONFIG_XFRM_BEET + if (xfrm[i]->props.mode == XFRM_MODE_TUNNEL) { +#else if (xfrm[i]->props.mode) { +#endif remote = xfrm[i]->id.daddr.a4; local = xfrm[i]->props.saddr.a4; tunnel = 1; } +#ifdef CONFIG_XFRM_BEET + else if (xfrm[i]->props.mode == XFRM_MODE_BEET) { + + if(xfrm[i]->props.beet_family_out == AF_INET){ + remotebeet.in = (struct in_addr*)&xfrm[i]->id.daddr; + localbeet.in = (struct in_addr*)&xfrm[i]->props.saddr; + beet_family = xfrm[i]->props.beet_family_out; + } else + BUG_ON(1); + } +#endif header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; @@ -113,6 +145,18 @@ &fl_tunnel, AF_INET); if (err) goto error; +#ifdef CONFIG_XFRM_BEET + } else if (beet_family) { + fl_tunnel.fl4_dst = remotebeet.in->s_addr; + fl_tunnel.fl4_src = localbeet.in->s_addr; + + err = xfrm_dst_lookup((struct xfrm_dst **) &rt, + &fl_tunnel, beet_family); + /* Without this, the BEET mode crashes + indeterministically -Abi */ + rt->peer = NULL; + rt_bind_peer(rt,1); +#endif } else dst_hold(&rt->u.dst); } --- linux-2.6.12.2-orig/net/ipv6/esp6.c +++ linux-2.6.12.2/net/ipv6/esp6.c @@ -22,6 +22,16 @@ * Kunihiro Ishiguro * * This file is derived from net/ipv4/esp.c + * + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * + * */ #include @@ -365,7 +375,11 @@ if (crypto_cipher_setkey(esp->conf.tfm, esp->conf.key, esp->conf.key_len)) goto error; x->props.header_len = sizeof(struct ipv6_esp_hdr) + esp->conf.ivlen; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) +#else if (x->props.mode) +#endif x->props.header_len += sizeof(struct ipv6hdr); x->data = esp; return 0; --- linux-2.6.12.2-orig/net/ipv6/xfrm6_input.c +++ linux-2.6.12.2/net/ipv6/xfrm6_input.c @@ -64,6 +64,18 @@ if (xfrm_state_check_expire(x)) goto drop_unlock; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) { + if (x->props.beet_family_in == AF_INET6 && x->props.beet_family_out == AF_INET6){ + struct ipv6hdr *ip6h = (struct ipv6hdr *)skb->nh.raw; + ipv6_addr_copy(&ip6h->daddr, + (struct in6_addr *) &x->sel.daddr.a6); + ipv6_addr_copy(&ip6h->saddr, + (struct in6_addr *) &x->sel.saddr.a6); + } else + BUG_ON(1); + } +#endif nexthdr = x->type->input(x, &(xfrm_vec[xfrm_nr].decap), skb); if (nexthdr <= 0) goto drop_unlock; @@ -80,7 +92,11 @@ xfrm_vec[xfrm_nr++].xvec = x; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) { +#else if (x->props.mode) { /* XXX */ +#endif if (nexthdr != IPPROTO_IPV6) goto drop; if (!pskb_may_pull(skb, sizeof(struct ipv6hdr))) @@ -97,6 +113,33 @@ skb->nh.raw = skb->data; decaps = 1; break; +#ifdef CONFIG_XFRM_BEET + } else if (x->props.mode == XFRM_MODE_BEET) { + struct ipv6hdr *ip6h = skb->nh.ipv6h; + int size = sizeof(struct ipv6hdr); + __u16 total = ntohs(ip6h->payload_len); + + /* is the buffer a clone? + * then create identical copy of header of skb */ + if (skb_cloned(skb) && + pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) + goto drop; + + /* add data to the start of the buffer */ + skb_push(skb, size); + /* move the raw header into new space */ + memmove(skb->data, skb->nh.raw, size); + /* move MAC header */ + skb->mac.raw = memmove(skb->data - skb->mac_len, + skb->mac.raw, skb->mac_len); + skb->nh.raw = skb->data; + + ip6h->payload_len = htons(total + size); + --ip6h->hop_limit; + decaps = 1; + + break; +#endif } if ((err = xfrm_parse_spi(skb, nexthdr, &spi, &seq)) < 0) --- linux-2.6.12.2-orig/net/ipv6/xfrm6_output.c +++ linux-2.6.12.2/net/ipv6/xfrm6_output.c @@ -7,6 +7,14 @@ * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -17,6 +25,10 @@ #include #include +#ifdef CONFIG_XFRM_BEET +#include +#endif + /* Add encapsulation header. * * In transport mode, the IP header and mutable extension headers will be moved @@ -42,7 +54,12 @@ skb_push(skb, x->props.header_len); iph = skb->nh.ipv6h; + +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TRANSPORT) { +#else if (!x->props.mode) { +#endif u8 *prevhdr; int hdr_len; @@ -51,6 +68,16 @@ skb->h.raw = skb->data + hdr_len; memmove(skb->data, iph, hdr_len); return; + +#ifdef CONFIG_XFRM_BEET + } else if (x->props.mode == XFRM_MODE_BEET) { + + memmove(skb->data, skb->nh.raw, sizeof(struct ipv6hdr)); + skb->nh.raw = &((struct ipv6hdr *)skb->data)->nexthdr; + skb->h.ipv6h = ((struct ipv6hdr *)skb->data) + 1; + return; + +#endif /* CONFIG_XFRM_BEET */ } skb->nh.raw = skb->data; @@ -104,7 +131,11 @@ goto error_nolock; } +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) { +#else if (x->props.mode) { +#endif err = xfrm6_tunnel_check_size(skb); if (err) goto error_nolock; @@ -121,6 +152,19 @@ if (err) goto error; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) { + /* Change the outer header */ + if (x->props.beet_family_in == AF_INET6 && x->props.beet_family_out == AF_INET6){ + /* Inner = 6, Outer = 6 */ + struct ipv6hdr *iph = (struct ipv6hdr*)skb->data; + ipv6_addr_copy(&iph->saddr, (struct in6_addr *)&x->props.saddr); + ipv6_addr_copy(&iph->daddr, (struct in6_addr *)&x->id.daddr); + } else + BUG_ON(1); + } +#endif + x->curlft.bytes += skb->len; x->curlft.packets++; --- linux-2.6.12.2-orig/net/ipv6/xfrm6_policy.c +++ linux-2.6.12.2/net/ipv6/xfrm6_policy.c @@ -8,7 +8,14 @@ * IPv6 support * YOSHIFUJI Hideaki * Split up af-specific portion - * + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -84,6 +91,12 @@ } } }; +#ifdef CONFIG_XFRM_BEET + union { + struct in6_addr *in6; + struct in_addr *in; + } remotebeet, localbeet; +#endif int i; int err = 0; int header_len = 0; @@ -96,6 +109,9 @@ struct dst_entry *dst1 = dst_alloc(&xfrm6_dst_ops); struct xfrm_dst *xdst; int tunnel = 0; +#ifdef CONFIG_XFRM_BEET + unsigned short beet_family = 0; +#endif if (unlikely(dst1 == NULL)) { err = -ENOBUFS; @@ -118,11 +134,25 @@ dst1->next = dst_prev; dst_prev = dst1; +#ifdef CONFIG_XFRM_BEET + if (xfrm[i]->props.mode == XFRM_MODE_TUNNEL) { +#else if (xfrm[i]->props.mode) { +#endif remote = (struct in6_addr*)&xfrm[i]->id.daddr; local = (struct in6_addr*)&xfrm[i]->props.saddr; tunnel = 1; } +#ifdef CONFIG_XFRM_BEET + else if (xfrm[i]->props.mode == XFRM_MODE_BEET) { + if (xfrm[i]->props.beet_family_out == AF_INET6) { + beet_family = xfrm[i]->props.beet_family_out; + remotebeet.in6 = (struct in6_addr*)&xfrm[i]->id.daddr; + localbeet.in6 = (struct in6_addr*)&xfrm[i]->props.saddr; + } else + BUG_ON(1); + } +#endif header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; @@ -133,6 +163,13 @@ &fl_tunnel, AF_INET6); if (err) goto error; +#ifdef CONFIG_XFRM_BEET + } else if (beet_family) { + ipv6_addr_copy(&fl_tunnel.fl6_dst, remotebeet.in6); + ipv6_addr_copy(&fl_tunnel.fl6_src, localbeet.in6); + err = xfrm_dst_lookup((struct xfrm_dst **) &rt, + &fl_tunnel, beet_family); +#endif } else dst_hold(&rt->u.dst); } --- linux-2.6.12.2-orig/net/key/af_key.c +++ linux-2.6.12.2/net/key/af_key.c @@ -12,6 +12,14 @@ * Kunihiro Ishiguro * Kazunori MIYAZAWA / USAGI Project * Derek Atkins + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -28,6 +36,10 @@ #include #include +#ifdef CONFIG_XFRM_BEET +#include +#endif + #include #define _X2KEY(x) ((x) == XFRM_INF ? 0 : (x)) @@ -1584,7 +1596,11 @@ } /* addresses present only in tunnel mode */ +#ifdef CONFIG_XFRM_BEET + if (t->mode == IPSEC_MODE_TUNNEL-1) { +#else if (t->mode) { +#endif switch (xp->family) { case AF_INET: sin = (void*)(rq+1); @@ -1612,6 +1628,40 @@ return -EINVAL; } } +#ifdef CONFIG_XFRM_BEET + else if (t->mode == IPSEC_MODE_BEET-1) { + struct sockaddr *sa; + + sa = (struct sockaddr *)(rq+1); + switch(sa->sa_family) { + case AF_INET: + sin = (struct sockaddr_in *)sa; + t->saddr.a4 = sin->sin_addr.s_addr; + sin++; + if (sin->sin_family != AF_INET) + return -EINVAL; + t->id.daddr.a4 = sin->sin_addr.s_addr; + t->family = AF_INET; + + break; +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + case AF_INET6: + sin6 = (struct sockaddr_in6 *)sa; + memcpy(t->saddr.a6, &sin6->sin6_addr, sizeof(struct in6_addr)); + sin6++; + if (sin6->sin6_family != AF_INET6) + return -EINVAL; + memcpy(t->id.daddr.a6, &sin6->sin6_addr, sizeof(struct in6_addr)); + t->family = AF_INET6; + + break; +#endif /* CONFIG_IPV6 */ + default: + return -EINVAL; + } + } +#endif /* CONFIG_XFRM_BEET */ + /* No way to set this via kame pfkey */ t->aalgos = t->ealgos = t->calgos = ~0; xp->xfrm_nr++; @@ -1935,6 +1985,48 @@ (err = parse_ipsecrequests(xp, pol)) < 0) goto out; +#ifdef CONFIG_XFRM_BEET + /* lookup the SA (xfrm_state) and copy the inner addresses from + * the policy (xfrm_policy) to the selector within the state + */ + if (xp->xfrm_vec[0].mode == IPSEC_MODE_BEET-1) { + struct xfrm_state *x; + if (xp->family == AF_INET6) { + if ((x = xfrm_lookup_bydst(XFRM_MODE_BEET, + &xp->xfrm_vec[0].id.daddr, + &xp->xfrm_vec[0].saddr, + AF_INET6))) { + /* Inner = 6, Outer = 6 */ + x->props.beet_family_out = AF_INET6; + x->props.beet_family_in = AF_INET6; + /* insert inner addresses into the selector */ + memcpy( &x->sel.daddr, &xp->selector.daddr, + sizeof(xfrm_address_t)); + memcpy( &x->sel.saddr, &xp->selector.saddr, + sizeof(xfrm_address_t)); + x->type = xfrm_get_type(x->id.proto, x->props.beet_family_in); + } + } else if (xp->family == AF_INET) { + if ((x = xfrm_lookup_bydst(XFRM_MODE_BEET, + &xp->xfrm_vec[0].id.daddr, + &xp->xfrm_vec[0].saddr, + AF_INET))) + { + /* Inner = 4, Outer = 4 */ + x->props.beet_family_out = AF_INET; + x->props.beet_family_in = AF_INET; + /* insert inner addresses into the selector */ + memcpy( &x->sel.daddr, &xp->selector.daddr, + sizeof(xfrm_address_t)); + memcpy( &x->sel.saddr, &xp->selector.saddr, + sizeof(xfrm_address_t)); + x->type = xfrm_get_type(x->id.proto, x->props.beet_family_in); + } + } else { + BUG_ON(1); + } + } +#endif out_skb = pfkey_xfrm_policy2msg_prep(xp); if (IS_ERR(out_skb)) { err = PTR_ERR(out_skb); --- linux-2.6.12.2-orig/net/xfrm/Kconfig +++ linux-2.6.12.2/net/xfrm/Kconfig @@ -10,3 +10,19 @@ If unsure, say Y. +config XFRM_BEET + bool "IPsec BEET mode" + depends on XFRM + ---help--- + IPsec BEET mode is combination of IPsec transport and tunnel mode. + Currently, it is used only by HIP. + + If unsure, say N. + +config XFRM_BEET_DEBUG + bool "IPsec BEET mode debugging" + depends on XFRM_BEET + ---help--- + Enables BEET mode debugging via syslog. + + If unsure, say N. --- linux-2.6.12.2-orig/net/xfrm/xfrm_state.c +++ linux-2.6.12.2/net/xfrm/xfrm_state.c @@ -1036,3 +1036,31 @@ INIT_WORK(&xfrm_state_gc_work, xfrm_state_gc_task, NULL); } +#ifdef CONFIG_XFRM_BEET + +struct xfrm_state * +xfrm_lookup_bydst(u8 mode, xfrm_address_t *daddr, xfrm_address_t *saddr, unsigned short family) +{ + struct xfrm_state *x; + unsigned h = xfrm_dst_hash(daddr, family); + + list_for_each_entry(x, xfrm_state_bydst+h, bydst){ + + if (x->props.family == AF_INET6 && + ipv6_addr_equal((struct in6_addr *)daddr, (struct in6_addr *)x->id.daddr.a6) && + mode == x->props.mode && + ipv6_addr_equal((struct in6_addr *)saddr, (struct in6_addr *)x->props.saddr.a6)) { + return(x); + } + + if (x->props.family == AF_INET && + daddr->a4 == x->id.daddr.a4 && + mode == x->props.mode && + saddr->a4 == x->props.saddr.a4) + return(x); + + } + return(NULL); +} + +#endif //CONFIG_XFRM_BEET --=-cxEtPhsKh15+QDSHjSKR 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 --=-cxEtPhsKh15+QDSHjSKR-- From hipsec-bounces@lists.ietf.org Wed Aug 03 05:45:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fon-0002Il-Ef; Wed, 03 Aug 2005 05:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fol-0002Ht-A7 for hipsec@megatron.ietf.org; Wed, 03 Aug 2005 05:45:43 -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 FAA00039 for ; Wed, 3 Aug 2005 05:45:41 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GLQ-0006no-7S for hipsec@ietf.org; Wed, 03 Aug 2005 06:19:28 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 12A392CFE; Wed, 3 Aug 2005 12:45:33 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A24482CEC; Wed, 3 Aug 2005 12:45:32 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j739jVw03135; Wed, 3 Aug 2005 12:45:31 +0300 (EEST) Date: Wed, 3 Aug 2005 12:45:31 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Ahrenholz, Jeffrey M" Subject: RE: [Hipsec] keymat / state machine problem with packet retransmission In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D7FF3@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: References: <0DF156EE7414494187B087A3C279BDB40D7FF3@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4-niksula20040914 X-Spam-Niksula: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Fri, 29 Jul 2005, Ahrenholz, Jeffrey M wrote: You are right, sorry for the extra fuzz. Thanks also for Jan and Julien for their offline comments. If there were issues created for the i/j and spi problems, they can be safely removed. > I don't know if this is a problem -- upon receiving the second R1, you > can compare the R1 generation counter and decide that it is not greater > than before, and drop the packet. Also, R1s are not retransmitted, so > this "reflection" would have to be some effect of the network. > Alternatively, if you receive the same R1 and you're in I2_SENT, it > seems like you can retransmit your same I2 again, containing the same > solution. > > As your example B shows, it seems like your retransmitted I2s have different solutions. I would think that the retransmitted I2 is just a copy of the previous packet. > > -Jeff > > > -----Original Message----- > > From: Miika Komu [mailto:miika@iki.fi] > > Sent: Friday, July 29, 2005 6:22 AM > > To: hipsec@ietf.org > > Subject: Re: [Hipsec] keymat / state machine problem with > > packet retransmission > > > > > > On Fri, 29 Jul 2005, Miika Komu wrote: > > > > > I discovered a problem in the state machine that may be > > worthy of noting > > > the draft. I discovered a hint for the problem during > > interops, and later > > > I could confirm it by running base exchange with the HIPL > > implementation > > > so that each HIP control packet sent was repeated always N x times. > > > > Let me elaborate more with two examples: > > > > Example A: C and D happen simultaneously: > > > > a) ----> I1 > > b) <---- R1 > > c) -----> I2 > > d) <---- R1 reflection of R1 (exactly the same as in b): initiator > > processes again! > > e) ------> I2 the cookie solution must be same as in c, otherwise > > end-up with mismatching keymat > > e) <---- R2 > > > > Example B: d and e happen simultaneously: > > > > init resp > > > > a) ----> I1 > > b) <---- R1 > > c) -----> I2 > > d) <---- R2 > > e) -----> I2 the cookie solution must be same as c, otherwise > > end-up with mismatching keymat > > > > Unless my thinking is incorrect, some text should be added that the > > initiator must remember the cookie solution it sent in I2 (and not to > > calculate a new one) upon retransmissions. The same applies > > for the SPI > > value. > > > > -- > > Miika Komu miika@iki.fi http://www.iki.fi/miika/ > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec > > > -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 03 16:57:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0QJ3-00005g-6s; Wed, 03 Aug 2005 16:57:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0QIy-0008Vk-2z for hipsec@megatron.ietf.org; Wed, 03 Aug 2005 16:57:37 -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 QAA19135 for ; Wed, 3 Aug 2005 16:57:33 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Qpi-0004wt-Ns for hipsec@ietf.org; Wed, 03 Aug 2005 17:31:27 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1E2172D3D; Wed, 3 Aug 2005 23:57:26 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A88042D16; Wed, 3 Aug 2005 23:57:25 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j73KvOm07087; Wed, 3 Aug 2005 23:57:24 +0300 (EEST) Date: Wed, 3 Aug 2005 23:57:24 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Diego Beltrami Subject: Re: [Hipsec] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux In-Reply-To: <1122984099.1214.142.camel@odysse> Message-ID: References: <1122984099.1214.142.camel@odysse> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4-niksula20040914 X-Spam-Niksula: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: netdev@oss.sgi.com, infrahip@HIIT.FI, hipl-users@freelists.org, Herbert Xu , 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 Tue, 2 Aug 2005, Diego Beltrami wrote: Hi Herbert and others, (sorry for the late comments - I am still on a holiday :) > after sending the first version of BEET patch and having received a > valuable feedback and after the discussion based upon the BEET design, > we now send the new BEET patch which allows for BEET to work without the > inter-family transform (i.e. inner address family different than outer > address family). > ... > > As it was originally designed the BEET patch at the moment works for > only ESP protocol. > As Pekka Nikader mentioned in one reply [1]: "[...] defining BEET mode > for AH might be pretty tricky. [...] it probably would require some > careful thinking to define the exact semantics, like what addresses > (inner or outer) are covered by the AH integrity protection, what does > the integrity protection really assert, etc. ". > > As previously written, the inter-family transform has been left out at > the moment since the xfrm architecture doesn't support it. As a result, > as soon as the xfrm architecture will be enhanced, the inter-family case > will be properly included as, for example, it can be useful for > supporting HIP over IPv4 network. But, as already mentioned, this would > require more work in properly designing the xfrm architecture (thing > which we consider necessary in order to make xfrm as generic as > possible). Based on the comments from Pekka Nikander, it seems like to me that generalizing XFRM to support AH with different inner and outer families may not very useful (a). On the other hand, the different inner and outer families for BEET is *extremely* useful (b). Excluding this support from BEET restricts the HIP implementations and applications quite radically. My own thinking logic tells me the (a) + (b) equals to supporting different inner and outer families in BEET in the way it is implemented currently. Don't fix it if it ain't broken!) We have tested that the BEET with different inner and outer addresses does not break anything. Further, if you don't need it, you don't have to compile it in :) Later, if AH seems really useful with different inner and outer families, or a new XYZ header is introduced, we can refactor the architecture for greater modularity. Even then, the XFRM/PFKEY APIs should remain the same. So, I'd vote for the original BEET patch, but of course it is up to you to decide. The BEET support is the minimal support required from the kernel in order for a usepace HIP implementation to work, and it would make both HIP implementors and users life much more easier :) Additionally, we would gain also more experience from using mixed inner and outer families within the XFRM architecture. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 04 03:19:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a0U-00013n-Ho; Thu, 04 Aug 2005 03:19:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0SrN-0005Un-6C for hipsec@megatron.ietf.org; Wed, 03 Aug 2005 19:41: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 TAA26385 for ; Wed, 3 Aug 2005 19:41:13 -0400 (EDT) Received: from jay.exetel.com.au ([220.233.0.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0TO6-00022n-Ux for hipsec@ietf.org; Wed, 03 Aug 2005 20:15:09 -0400 Received: (qmail 22219 invoked by uid 507); 4 Aug 2005 09:40:58 +1000 Received: from 22.107.233.220.exetel.com.au (HELO arnor.apana.org.au) (220.233.107.22) by jay.exetel.com.au with SMTP; 4 Aug 2005 09:40:58 +1000 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1E0Sr3-0006Vd-00; Thu, 04 Aug 2005 09:40:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1E0Sqy-0003Rn-00; Thu, 04 Aug 2005 09:40:52 +1000 Date: Thu, 4 Aug 2005 09:40:52 +1000 To: Diego Beltrami Message-ID: <20050803234052.GA13216@gondor.apana.org.au> References: <1122984099.1214.142.camel@odysse> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1122984099.1214.142.camel@odysse> User-Agent: Mutt/1.5.9i From: Herbert Xu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Thu, 04 Aug 2005 03:19:09 -0400 Cc: netdev@oss.sgi.com, infrahip@HIIT.FI, hipl-users@freelists.org, hipsec@ietf.org Subject: [Hipsec] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Tue, Aug 02, 2005 at 03:01:39PM +0300, Diego Beltrami wrote: > > after sending the first version of BEET patch and having received a > valuable feedback and after the discussion based upon the BEET design, > we now send the new BEET patch which allows for BEET to work without the > inter-family transform (i.e. inner address family different than outer > address family). Thanks for the new patch. Unfortunately it really looks quite similar to the previous patch :) > --- linux-2.6.12.2-orig/net/ipv4/esp4.c > +++ linux-2.6.12.2/net/ipv4/esp4.c I thought getting rid of the interfamily stuff would remove the need to touch this file, no? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 04 10:38:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gs6-00084n-SW; Thu, 04 Aug 2005 10:38:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gs5-00081Q-2A for hipsec@megatron.ietf.org; Thu, 04 Aug 2005 10:38:57 -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 KAA16014 for ; Thu, 4 Aug 2005 10:38:55 -0400 (EDT) Received: from pegasus.hiit.fi ([212.68.1.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0hOy-0005bm-As for hipsec@ietf.org; Thu, 04 Aug 2005 11:12:57 -0400 Received: from [128.214.113.174] (odysse.hiit.fi [128.214.113.174]) by pegasus.hiit.fi (Postfix) with ESMTP id 5C9A6220082; Thu, 4 Aug 2005 17:38:31 +0300 (EEST) Message-ID: <42F22867.9050804@hiit.fi> Date: Thu, 04 Aug 2005 17:38:31 +0300 From: Diego Beltrami User-Agent: Mozilla Thunderbird 1.0.2-0.fdr.1.2 (X11/20050514) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu References: <1122984099.1214.142.camel@odysse> <20050804131519.GB5831@gondor.apana.org.au> In-Reply-To: <20050804131519.GB5831@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, infrahip@hiit.fi, hipl-users@freelists.org, hipsec@ietf.org Subject: [Hipsec] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux 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 > Well to me it's more of an issue of maintainability. BEET mode is > more akin to transport/tunnel mode than AH/ESP/IPcomp. As such its > implementation would be most at home where the existing encapsulation > and decapsulation for transport/tunnel mode is done. That is, in > xfrm[46]_input.c and xfrm[46]_output.c. > > For instance, the reason the current patch has to touch esp4.c at > all is really because the patch to xfrm4_output.c isn't right. > It should do what the comment says and set skb->h to the start > of the payload, not the start of the ESP header. If it did that, > then esp_output doesn't have to care about BEET at all. This is totally true, and I agree with you but then this is somehow a controversial thing with respect to the esp6_output. In fact the esp6_output has the same purpose of esp_output, but it requires the skb->h to be set at the beginning of ESP header. > > Also, the outer header generation should be done before > x->type->output is called, not after. That way, the AH > semantics falls out quite naturally. BEET has been designed to be compatible with HIP. This means that the ESP header should be computed with respect to the inner addresses. In a very first implementation of BEET we were converting the inner addresses to the outer addresses before x->type->output, but we couldn't make interoperate BEET with HIP. That's the reason why the outer header generation has been after x->type->output. This is one of the reasons why the AH, as Pekka Nikader said, is a bit trickier with respect to ESP (the AH protocol protects the IP datagram including immutable parts of the IP header like the IP addresses whereas for ESP the IP header is not included in the calculation process). --Diego _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 04 11:28:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hdq-0003xT-Py; Thu, 04 Aug 2005 11:28:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fZc-0004aQ-Uh for hipsec@megatron.ietf.org; Thu, 04 Aug 2005 09:15:49 -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 JAA08578 for ; Thu, 4 Aug 2005 09:15:46 -0400 (EDT) Received: from jay.exetel.com.au ([220.233.0.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0g6T-00024E-JD for hipsec@ietf.org; Thu, 04 Aug 2005 09:49:48 -0400 Received: (qmail 26834 invoked by uid 507); 4 Aug 2005 23:15:29 +1000 Received: from 22.107.233.220.exetel.com.au (HELO arnor.apana.org.au) (220.233.107.22) by jay.exetel.com.au with SMTP; 4 Aug 2005 23:15:29 +1000 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1E0fZG-0002A3-00; Thu, 04 Aug 2005 23:15:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1E0fZ9-0001Yw-00; Thu, 04 Aug 2005 23:15:19 +1000 Date: Thu, 4 Aug 2005 23:15:19 +1000 To: Miika Komu Subject: Re: [Hipsec] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux Message-ID: <20050804131519.GB5831@gondor.apana.org.au> References: <1122984099.1214.142.camel@odysse> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Herbert Xu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Thu, 04 Aug 2005 11:28:17 -0400 Cc: netdev@oss.sgi.com, infrahip@HIIT.FI, hipl-users@freelists.org, Diego Beltrami , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi Miika: On Wed, Aug 03, 2005 at 11:57:24PM +0300, Miika Komu wrote: > > Based on the comments from Pekka Nikander, it seems like to me that > generalizing XFRM to support AH with different inner and outer families > may not very useful (a). On the other hand, the different inner and outer Well to me it's more of an issue of maintainability. BEET mode is more akin to transport/tunnel mode than AH/ESP/IPcomp. As such its implementation would be most at home where the existing encapsulation and decapsulation for transport/tunnel mode is done. That is, in xfrm[46]_input.c and xfrm[46]_output.c. For instance, the reason the current patch has to touch esp4.c at all is really because the patch to xfrm4_output.c isn't right. It should do what the comment says and set skb->h to the start of the payload, not the start of the ESP header. If it did that, then esp_output doesn't have to care about BEET at all. Also, the outer header generation should be done before x->type->output is called, not after. That way, the AH semantics falls out quite naturally. > families for BEET is *extremely* useful (b). Excluding this support from > BEET restricts the HIP implementations and applications quite radically. I agree with you wholeheartedly that this is extremely useful. However, I also see nothing that's BEET-specific about this feature. So for the sake of the overall consistency of the IPsec stack please keep the implementation generic instead of BEET-specific. That is, please do it in a way so that it applies to plain tunnel mode as well. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 10 10:23:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rUo-0006cF-6t; Wed, 10 Aug 2005 10:23:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rUl-0006c4-T7 for hipsec@megatron.ietf.org; Wed, 10 Aug 2005 10:23:52 -0400 Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01884 for ; Wed, 10 Aug 2005 10:23:48 -0400 (EDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 16:21:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Aug 2005 16:21:37 +0200 Message-ID: Thread-Topic: HIP questions Thread-Index: AcWdttGypkUfBS3xTFmQwG3hV5ZyFw== From: "DONG Song RD-ILAB-LON" To: X-OriginalArrivalTime: 10 Aug 2005 14:21:38.0922 (UTC) FILETIME=[D262B4A0:01C59DB6] Cc: Subject: [Hipsec] HIP questions 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="===============1424957348==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1424957348== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59DB6.D251F787" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59DB6.D251F787 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, I recently have a study on HIP. Some people say it easily supports mobility by introducing HIP layer to separate transport layer and IP layer. Therefore it will even replace MIP. I don't think so. Following is my conclusion. If anybody could point out my misunderstanding, that will be very helpful. Pls keep the reading frame as large as possible in order to have a correct display of the diagrams. Thanks, Song France Telecom R&D UK The Host Identity Protocol (HIP) is a key establishment and parameter negotiation protocol. Its primary applications are for authenticating host messages based on host identities, and establishing security associations (SAs) for ESP transport format and possibly other protocols in the future. The authors also think it could bring more efficient mobility by decoupling the transport layer and internetworking layer. I personally don't believe it will pose any impact on Mobile IP. Here are my analysis. Mobility: There are mainly two address spaces in use in the internet. In order for two hosts to communicate with each other, an address space which could represent their physical places and is easy to route is required. That is the internetworking address (IP address). Another type of addresses are Domain names, including email address, http, and SIP addresses, which are easy to memorize and used directly by applications. Therefore the communication process will normally be as follows: Transport Layer | | DNS Server (translator)=09 Domain Name ---------------------------------------------------> IP address The domain name will be tranlated into a IP address which represents the host's physical presence. Because the normal IP address is physically bound. The translation information located in DNS server is normally static and does not need dynamic(real time) update. However, because the IP address is bound to a physical site in the internet. It presents a problem for the application mobility since the transport layer is using the IP address. In this case, some sort of IP address which is not physically bound and can stay fixed during the communication is needed for the transport layer to use. That is the introduction of Mobile IP as follows: Transport Layer | | DNS Server (translator) Home Agent (translator) Domain Name ----------------------------------> Mobile IP Home Address ------------------------------> IP address (physical site) (static) Dynamically (might change) =20 >From the Mobile IP address to the physically bound IP address, there needs some sort of translator to provide the mapping information. That is the function of the Home Agent. To support mobility, the information must be updated dynamically along with the movement of the node. The Mobile Node uses Registration Request message to provide such information (or BU in IPV6). Then let's look at how HIP works. It suggests using Host Identifier (HI) to decouple the transport layer and the IP layer as follows: Transport Layer | | DNS Server (translator) DNS Server (translator) Domain Name ----------------------------------> Host Identifier Address ------------------------------> IP address (physical site) (static) Dynamically (might change) =20 Therefore, ithe transport can use the static HI address which will not change during the communication. It seems perfect for mobility. However, it is not true. The problem is that how the up-to-date mapping information from the static HI address to the possible dynamic IP address (if the node moves) is be obtained in the system. In the HIP IETF draft, it says the DNS server is used to translate the Domain Name into Host Identifier Address and IP address at the same time. No matter whoever is to translate the information, such information must be updated on a real-time style. Otherwise you are going to lose the trace of the node. Therefore, you need some sort of scheme like Registration Request and Registration Reply to provide such information to the translator dynamically. Sounds familiar? Yes, you are going to reinvent Mobile IP again. Never the less, because it introduces the static HI address to replace the traditional IP address for the transport layer to use, it requires fundmental changes for the transport layer and upper layers, e.g. all socket APIs must be rewritten to support HI addresses. I think the authors also recognised this. Let's look at its answer to the IRTF Name Space Research Group (NSRG) on the translation/resolution. 9. What would the resolution mechanisms be, or what characteristics of a resolution mechanisms would be required? For most purposes, an approach where DNS names are resolved simultaneously to HIs and IP addresses is sufficient. However, if it becomes necessary to resolve HIs into IP addresses or back to DNS names, a flat resolution infrastructure is needed. Such an infrastructure could be based on the ideas of Distributed Hash Tables, but would require significant new development and deployment. (Taken from: Host Identity Protocol Architecture draft-ietf-hip-arch-02) Considering it brings similar functions to the Mobile IP while requiring much more implement effort, I don't think it has any opportunity to replace Mobile IP, which already has some applictions. Security: However, it brings some novel ideas of security which could be used or borrowed to deal with mobile security. Current Security IPsec Problem Current IPsec uses a local valid index SPI, the IP destination address, and Security Protocol (AH/ESP) to find the cyper key in the local database to decrypt the cipertext as follows: =20 cyper text SPI local database | IP destination address ----------------------------------> cyper key -------------------->| SP | =20 clear text However, in a case where the IP address changes, the node will never be able to find the ciper key in its database using the index. Therefore, the negotiation is needed to obtain another ciper key. That is why IPsec is not working with a changed IP address. In Mobile IP, it is possible to negotiate the ciper key using the node's Home Address which will stay the same during the communication. Therefore, the cyper key can be found. This is the case of what we say IPsec inside Mobile IP tunnel. However, to support mobility, the node needs to talk with the HA in clear text because the cyper key is only used between the MN and the VPN gateway (or the CN). This brings the requirement of IPsec splitting tunnel which might pose some security risks. Let's then look at what the HIP is trying to achieve. =20 cyper text SPI local database | HI Address ----------------------------------> cyper key -------------------->| SP | =20 clear text It suggests because the HI address is static, the cyper key could be used even the node moves (IP address changes). It sounds good. But let's look back at the mobility part. The mobile node needs to report the mapping information from the static HI address to the changed IP address dynamically to the translator (DNS server), of course, in clear text, since the cyper key is between the mobile node and the VPN gateway / or the CN. It has the same splitting tunnel problem. Summary: To compare with MIP, HIP does not bring any new advantages or functionalities on mobility and security. In addition, it requires heavy development and fundmental changes for the tranport layer and upper layers. My personally view is that it is never going to replace MIP or mobility management. It might do some help on security aspect using public / private key to authenticate and exchange cyper key. Current IPsec VPN mainly uses username and password to authenticate. However, this is not a new idea as SSH is already using it. Definitly it is never going to happen that the transport layer uses the HI address (public key) as the name space to set up the communication. ------_=_NextPart_001_01C59DB6.D251F787 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HIP questions

Hi all,

I recently have a study on HIP. Some = people say it easily supports mobility by introducing HIP layer to = separate transport layer and IP layer. Therefore it will even replace = MIP. I don't think so. Following is my conclusion. If anybody could = point out my misunderstanding, that will be very helpful. Pls keep the = reading frame as large as possible in order to have a correct display of = the diagrams.

Thanks,
Song

France Telecom R&D UK


The Host Identity Protocol (HIP) is a key establishment = and parameter negotiation protocol.  Its primary applications are = for authenticating host messages based on host identities, and = establishing security associations (SAs) for ESP transport format and = possibly other protocols in the future.

The authors also think it could bring more efficient = mobility by decoupling the transport layer and internetworking layer. I = personally don't believe it will pose any impact on Mobile = IP.

Here are my analysis.

Mobility:
There are mainly two address spaces in use in the = internet. In order for two hosts to communicate with each other, an = address space which could represent their physical places and is easy to = route is required. That is the internetworking address (IP address). = Another type of addresses are Domain names, including email address, = http, and SIP addresses, which are easy to memorize and used directly by = applications.

Therefore the communication process will normally be as = follows:

        =         =         =         =         =         Transport Layer
        =         =         =         =         =         =         |
        =         =         =         =         =         =         |
        =             DNS Server = (translator)    
Domain Name   = ---------------------------------------------------> IP = address

The domain name will be tranlated into a IP address which = represents the host's physical presence. Because the normal IP address = is physically bound. The translation information located in DNS server = is normally static and does not need dynamic(real time) = update.

However, because the IP address is bound to a physical = site in the internet. It presents a problem for the application mobility = since the transport layer is using the IP address. In this case, some = sort of IP address which is not physically bound and can stay fixed = during the communication is needed for the transport layer to use. That = is the introduction of Mobile IP as follows:

        =         =         =         =         Transport Layer
        =         =         =         =         =            |
        =         =         =         =                  &nbs= p;     |
        =         DNS Server = (translator)          &= nbsp;           &n= bsp;           &nb= sp;    Home Agent (translator)
Domain Name ----------------------------------> Mobile = IP Home Address ------------------------------>  IP address = (physical site)

        =         =         =         =                (static) =         =       = Dynamically          &n= bsp;     (might change)     =

From the Mobile IP address to the physically bound IP = address, there needs some sort of translator to provide the mapping = information. That is the function of the Home Agent. To support = mobility, the information must be updated dynamically along with the = movement of the node. The Mobile Node uses Registration Request message = to provide such information (or BU in IPV6).

Then let's look at how HIP works.

It suggests using Host Identifier (HI) to decouple the = transport layer and the IP layer as follows:

        =         =         =         =          Transport = Layer
        =         =         =         =         =         |
        =         =         =         =         =         |       =         =              =
        =         DNS Server = (translator)          &= nbsp;           &n= bsp;           &nb= sp;  DNS Server (translator)
Domain Name ----------------------------------> Host = Identifier Address ------------------------------>  IP address = (physical site)

        =         =         =         =                (static) =            = Dynamically          &n= bsp;     (might change)     =

Therefore, ithe transport can use the static HI address = which will not change during the communication. It seems perfect for = mobility. However, it is not true. The problem is that how the = up-to-date mapping information from the static HI address to the = possible dynamic IP address (if the node moves) is be obtained in the = system. In the HIP IETF draft, it says the DNS server is used to = translate the Domain Name into Host Identifier Address and IP address at = the same time. No matter whoever is to translate the information, such = information must be updated on a real-time style. Otherwise you are = going to lose the trace of the node. Therefore, you need some sort of = scheme like Registration Request and Registration Reply to provide such = information to the translator dynamically. Sounds familiar? Yes, you are = going to reinvent Mobile IP again. Never the less, because it introduces = the static HI address to replace the traditional IP address for the = transport layer to use, it requires fundmental changes for the transport = layer and upper layers, e.g. all socket APIs must be rewritten to = support HI addresses.

I think the authors also recognised this. Let's look at = its answer to the IRTF Name Space Research Group (NSRG) on the = translation/resolution.

   9.  What would the resolution = mechanisms be, or what characteristics
       of a resolution = mechanisms would be required?

          = For most purposes, an approach where DNS names are = resolved
          = simultaneously to HIs and IP addresses is sufficient.
          = However, if it becomes necessary to resolve HIs into IP
          = addresses or back to DNS names, a flat resolution
          = infrastructure is needed.  Such an infrastructure could be
          = based on the ideas of Distributed Hash Tables, but would
          = require significant new development and deployment.

(Taken from: Host Identity Protocol Architecture = draft-ietf-hip-arch-02)


Considering it brings similar functions to the Mobile IP = while requiring much more implement effort, I don't think it has any = opportunity to replace Mobile IP, which already has some = applictions.

Security:
However, it brings some novel ideas of security which = could be used or borrowed to deal with mobile security.

Current Security IPsec Problem
Current IPsec uses a local valid index SPI, the IP = destination address, and Security Protocol (AH/ESP) to find the cyper = key in the local database to decrypt the cipertext as = follows:

         &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       cyper text
SPI         &= nbsp;           &n= bsp;           local = database           = ;            =             &= nbsp;            = |
IP destination address  = ----------------------------------> cyper key = -------------------->|
SP      =         =         =         =         =         =         =         =         |
         &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;         clear = text

However, in a case where the IP address changes, the node = will never be able to find the ciper key in its database using the = index. Therefore, the negotiation is needed to obtain another ciper key. = That is why IPsec is not working with a changed IP = address.

In Mobile IP, it is possible to negotiate the ciper key = using the node's Home Address which will stay the same during the = communication. Therefore, the cyper key can be found. This is the case = of what we say IPsec inside Mobile IP tunnel. However, to support = mobility, the node needs to talk with the HA in clear text because the = cyper key is only used between the MN and the VPN gateway (or the CN). = This brings the requirement of IPsec splitting tunnel which might pose = some security = risks.           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           =

Let's then look at what the HIP is trying to = achieve.

         &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   cyper text
SPI         &= nbsp;         local = database           = ;            =             &= nbsp;            = |
HI Address   ----------------------------------> cyper = key -------------------->|
SP      =         =             &= nbsp;           =         =         =         =          |
         &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;    clear text

It suggests because the HI address is static, the cyper = key could be used even the node moves (IP address changes). It sounds = good. But let's look back at the mobility part. The mobile node needs to = report the mapping information from the static HI address to the changed = IP address dynamically to the translator (DNS server), of course, in = clear text, since the cyper key is between the mobile node and the VPN = gateway / or the CN. It has the same splitting tunnel = problem.


Summary:
To compare with MIP, HIP does not bring any new = advantages or functionalities on mobility and security. In addition, it = requires heavy development and fundmental changes for the tranport layer = and upper layers. My personally view is that it is never going to = replace MIP or mobility management.

It might do some help on security aspect using public / = private key to authenticate and exchange cyper key. Current IPsec VPN = mainly uses username and password to authenticate. However, this is not = a new idea as SSH is already using it. Definitly it is never going to = happen that the transport layer uses the HI address (public key) as the = name space to set up the communication.





------_=_NextPart_001_01C59DB6.D251F787-- --===============1424957348== 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 --===============1424957348==-- From hipsec-bounces@lists.ietf.org Wed Aug 10 10:53:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rxY-0007Gw-2W; Wed, 10 Aug 2005 10:53:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rxX-0007Gr-At for hipsec@megatron.ietf.org; Wed, 10 Aug 2005 10:53:35 -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 KAA03940 for ; Wed, 10 Aug 2005 10:53:33 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2sVc-0000s1-6Z for hipsec@ietf.org; Wed, 10 Aug 2005 11:28:51 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 16:53:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Aug 2005 16:53:03 +0200 Message-ID: Thread-Topic: HIP questions ... Thread-Index: AcWduzXBABFtWItCSfSa0Kty8FfxjA== From: "DONG Song RD-ILAB-LON" To: X-OriginalArrivalTime: 10 Aug 2005 14:53:04.0483 (UTC) FILETIME=[36447B30:01C59DBB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Hipsec] HIP questions ... 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="===============1208341456==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1208341456== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59DBB.3635D013" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59DBB.3635D013 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Sorry the diagrams are a little bit distorted. -- Song ------_=_NextPart_001_01C59DBB.3635D013 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HIP questions ...

Sorry the diagrams are a little bit = distorted.

-- Song

------_=_NextPart_001_01C59DBB.3635D013-- --===============1208341456== 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 --===============1208341456==-- From hipsec-bounces@lists.ietf.org Wed Aug 10 10:54:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rxz-0007Ln-Kv; Wed, 10 Aug 2005 10:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rxx-0007LX-CV for hipsec@megatron.ietf.org; Wed, 10 Aug 2005 10:54: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 KAA03961 for ; Wed, 10 Aug 2005 10:53:58 -0400 (EDT) Message-Id: <200508101453.KAA03961@ietf.org> Received: from mail-09.iinet.net.au ([203.59.3.41] helo=mail.iinet.net.au) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2sVr-0000sF-HM for hipsec@ietf.org; Wed, 10 Aug 2005 11:29:17 -0400 Received: (qmail 15216 invoked from network); 10 Aug 2005 14:53:28 -0000 Received: from unknown (HELO T40) (203.217.39.9) by mail.iinet.net.au with SMTP; 10 Aug 2005 14:53:25 -0000 From: "Joseph" To: "'DONG Song RD-ILAB-LON'" , Subject: RE: [Hipsec] HIP questions Date: Thu, 11 Aug 2005 00:53:18 +1000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcWdttGypkUfBS3xTFmQwG3hV5ZyFwABGWFQ X-Spam-Score: 0.4 (/) X-Scan-Signature: 2d59e8aabfccff976bdddd3996aba7a3 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0567018776==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0567018776== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C59E0F.10D32BE0" This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C59E0F.10D32BE0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear Song and other folk (who read this email), I think that HIP can replace MIP or co-operate with MIP, if commercial consideration is not included. (Just similar to many people said that IPv4 should be replaced by IPv6 within 2-5 years, when I was high school student. However, I'm postgraduate student now; IPv4 is not replaced yet. In the Mobility part, I want to make some notes. Beside the DNS server, we can use RVS to map between HI/HIT and MIP. The performance of RVS in the mobility area of HIP is much better than DNS. Furthermore, during the communication, mobile node can use update packet to readdressing. As the SA is not bonded to IP, so that the connection can be mapped into different IP address. I have even written a paper to talk about the initial merging in MIP and HIP. (I have submitted to conference, I can send to you if you are interested when the paper is accepted). For the security, I think HIP is much strength than MIP, in ESP connection mode, all the package are protected by ESP, but MIP is not. I'm an also new baby in HIP, I think there are a lot of professional in here can tell you more detail about the advantage about HIP over MIP. I think the problem of HIP not able to replace MIP is not technical, but commercial reason. Please correct me if I have any mistake. Yours, Joseph _____ From: hipsec-bounces@lists.ietf.org [mailto:hipsec-bounces@lists.ietf.org] On Behalf Of DONG Song RD-ILAB-LON Sent: Thursday, August 11, 2005 12:22 AM To: hipsec@ietf.org Subject: [Hipsec] HIP questions Hi all, I recently have a study on HIP. Some people say it easily supports mobility by introducing HIP layer to separate transport layer and IP layer. Therefore it will even replace MIP. I don't think so. Following is my conclusion. If anybody could point out my misunderstanding, that will be very helpful. Pls keep the reading frame as large as possible in order to have a correct display of the diagrams. Thanks, Song France Telecom R&D UK The Host Identity Protocol (HIP) is a key establishment and parameter negotiation protocol. Its primary applications are for authenticating host messages based on host identities, and establishing security associations (SAs) for ESP transport format and possibly other protocols in the future. The authors also think it could bring more efficient mobility by decoupling the transport layer and internetworking layer. I personally don't believe it will pose any impact on Mobile IP. Here are my analysis. Mobility: There are mainly two address spaces in use in the internet. In order for two hosts to communicate with each other, an address space which could represent their physical places and is easy to route is required. That is the internetworking address (IP address). Another type of addresses are Domain names, including email address, http, and SIP addresses, which are easy to memorize and used directly by applications. Therefore the communication process will normally be as follows: Transport Layer | | DNS Server (translator) Domain Name ---------------------------------------------------> IP address The domain name will be tranlated into a IP address which represents the host's physical presence. Because the normal IP address is physically bound. The translation information located in DNS server is normally static and does not need dynamic(real time) update. However, because the IP address is bound to a physical site in the internet. It presents a problem for the application mobility since the transport layer is using the IP address. In this case, some sort of IP address which is not physically bound and can stay fixed during the communication is needed for the transport layer to use. That is the introduction of Mobile IP as follows: Transport Layer | | DNS Server (translator) Home Agent (translator) Domain Name ----------------------------------> Mobile IP Home Address ------------------------------> IP address (physical site) (static) Dynamically (might change) >From the Mobile IP address to the physically bound IP address, there needs some sort of translator to provide the mapping information. That is the function of the Home Agent. To support mobility, the information must be updated dynamically along with the movement of the node. The Mobile Node uses Registration Request message to provide such information (or BU in IPV6). Then let's look at how HIP works. It suggests using Host Identifier (HI) to decouple the transport layer and the IP layer as follows: Transport Layer | | DNS Server (translator) DNS Server (translator) Domain Name ----------------------------------> Host Identifier Address ------------------------------> IP address (physical site) (static) Dynamically (might change) Therefore, ithe transport can use the static HI address which will not change during the communication. It seems perfect for mobility. However, it is not true. The problem is that how the up-to-date mapping information from the static HI address to the possible dynamic IP address (if the node moves) is be obtained in the system. In the HIP IETF draft, it says the DNS server is used to translate the Domain Name into Host Identifier Address and IP address at the same time. No matter whoever is to translate the information, such information must be updated on a real-time style. Otherwise you are going to lose the trace of the node. Therefore, you need some sort of scheme like Registration Request and Registration Reply to provide such information to the translator dynamically. Sounds familiar? Yes, you are going to reinvent Mobile IP again. Never the less, because it introduces the static HI address to replace the traditional IP address for the transport layer to use, it requires fundmental changes for the transport layer and upper layers, e.g. all socket APIs must be rewritten to support HI addresses. I think the authors also recognised this. Let's look at its answer to the IRTF Name Space Research Group (NSRG) on the translation/resolution. 9. What would the resolution mechanisms be, or what characteristics of a resolution mechanisms would be required? For most purposes, an approach where DNS names are resolved simultaneously to HIs and IP addresses is sufficient. However, if it becomes necessary to resolve HIs into IP addresses or back to DNS names, a flat resolution infrastructure is needed. Such an infrastructure could be based on the ideas of Distributed Hash Tables, but would require significant new development and deployment. (Taken from: Host Identity Protocol Architecture draft-ietf-hip-arch-02) Considering it brings similar functions to the Mobile IP while requiring much more implement effort, I don't think it has any opportunity to replace Mobile IP, which already has some applictions. Security: However, it brings some novel ideas of security which could be used or borrowed to deal with mobile security. Current Security IPsec Problem Current IPsec uses a local valid index SPI, the IP destination address, and Security Protocol (AH/ESP) to find the cyper key in the local database to decrypt the cipertext as follows: cyper text SPI local database | IP destination address ----------------------------------> cyper key -------------------->| SP | clear text However, in a case where the IP address changes, the node will never be able to find the ciper key in its database using the index. Therefore, the negotiation is needed to obtain another ciper key. That is why IPsec is not working with a changed IP address. In Mobile IP, it is possible to negotiate the ciper key using the node's Home Address which will stay the same during the communication. Therefore, the cyper key can be found. This is the case of what we say IPsec inside Mobile IP tunnel. However, to support mobility, the node needs to talk with the HA in clear text because the cyper key is only used between the MN and the VPN gateway (or the CN). This brings the requirement of IPsec splitting tunnel which might pose some security risks. Let's then look at what the HIP is trying to achieve. cyper text SPI local database | HI Address ----------------------------------> cyper key -------------------->| SP | clear text It suggests because the HI address is static, the cyper key could be used even the node moves (IP address changes). It sounds good. But let's look back at the mobility part. The mobile node needs to report the mapping information from the static HI address to the changed IP address dynamically to the translator (DNS server), of course, in clear text, since the cyper key is between the mobile node and the VPN gateway / or the CN. It has the same splitting tunnel problem. Summary: To compare with MIP, HIP does not bring any new advantages or functionalities on mobility and security. In addition, it requires heavy development and fundmental changes for the tranport layer and upper layers. My personally view is that it is never going to replace MIP or mobility management. It might do some help on security aspect using public / private key to authenticate and exchange cyper key. Current IPsec VPN mainly uses username and password to authenticate. However, this is not a new idea as SSH is already using it. Definitly it is never going to happen that the transport layer uses the HI address (public key) as the name space to set up the communication. ------=_NextPart_000_0087_01C59E0F.10D32BE0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HIP questions

Dear Song and = other folk (who read this email),

   =         I think that HIP can replace MIP or co-operate with MIP, if commercial consideration is not included. (Just similar to many people said that = IPv4 should be replaced by IPv6 within 2-5 years, when I was high school = student. However, I’m postgraduate student now; IPv4 is not replaced = yet.

   =         In the Mobility part, I want to make some notes. Beside the DNS server, = we can use RVS to map between HI/HIT and MIP. The performance of RVS in the = mobility area of HIP is much better than DNS. Furthermore, during the = communication, mobile node can use update packet to readdressing. As the SA is not = bonded to IP, so that the connection can be mapped into different IP address. I = have even written a paper to talk about the initial merging in MIP and HIP. (I = have submitted to conference, I can send to you if you are interested when = the paper is accepted). For the security, I think HIP is much strength than MIP, = in ESP connection mode, all the package are protected by ESP, but MIP is = not.

   =         I’m an also new baby in HIP, I think there are a lot of = professional in here can tell you more detail about the advantage about HIP over MIP. I = think the problem of HIP not able to replace MIP is not technical, but = commercial reason.

   =         Please correct me if I have any mistake.

Yours,<= /span>

Joseph<= /span>

 <= /span>

 <= /span>

From: hipsec-bounces@lists.ietf.org [mailto:hipsec-bounces@lists.ietf.org] = On Behalf Of DONG Song = RD-ILAB-LON
Sent: Thursday, August = 11, 2005 12:22 AM
To: hipsec@ietf.org
Subject: [Hipsec] HIP = questions

 

 

Hi all,

I recently have a study on HIP. Some people say it easily = supports mobility by introducing HIP layer to separate transport layer and IP = layer. Therefore it will even replace MIP. I don't think so. Following is my conclusion. If anybody could point out my misunderstanding, that will be = very helpful. Pls keep the reading frame as large as possible in order to = have a correct display of the diagrams.

Thanks,
Song =

France Telecom R&D UK

 

The Host Identity Protocol (HIP) is a key establishment and parameter negotiation protocol.  Its primary applications are for authenticating host messages based on host = identities, and establishing security associations (SAs) for ESP transport format and = possibly other protocols in the future.

The authors also think it could bring more efficient mobility by decoupling the transport layer and internetworking = layer. I personally don't believe it will pose any impact on Mobile = IP.

Here are my analysis.

Mobility:
There are mainly two address spaces = in use in the internet. In order for two hosts to communicate with each other, = an address space which could represent their physical places and is easy to = route is required. That is the internetworking address (IP address). Another = type of addresses are Domain names, including email address, http, and SIP = addresses, which are easy to memorize and used directly by = applications.

Therefore the communication process will = normally be as follows:

                                        =         Transport = Layer
                                        =                 |
                                        =                 |
                    DNS Server = (translator)    
Domain Name   ---------------------------------------------------> IP = address

The domain name will be tranlated into a = IP address which represents the host's physical presence. Because the = normal IP address is physically bound. The translation information located in DNS = server is normally static and does not need dynamic(real time) = update.

However, because the IP address is bound = to a physical site in the internet. It presents a problem for the application mobility since the transport layer is using the IP address. In this = case, some sort of IP address which is not physically bound and can stay fixed = during the communication is needed for the transport layer to use. That is the introduction of Mobile IP as follows:

                                        Transport Layer
                                        =            |
        =                                           &= nbsp;    |
                DNS Server (translator)          &= nbsp;           &n= bsp;           &nb= sp;    Home Agent (translator)
Domain Name ----------------------------------> Mobile IP Home Address ------------------------------>  IP address (physical = site)

                                               (static)         =       Dynamically          &n= bsp;     (might change)    

From the Mobile IP address to the = physically bound IP address, there needs some sort of translator to provide the = mapping information. That is the function of the Home Agent. To support = mobility, the information must be updated dynamically along with the movement of the = node. The Mobile Node uses Registration Request message to provide such = information (or BU in IPV6).

Then let's look at how HIP = works.

It suggests using Host Identifier (HI) to decouple the transport layer and the IP layer as = follows:

                                         Transport = Layer
                                        =         | =
        =                                         |                            =
                DNS Server (translator)          &= nbsp;           &n= bsp;           &nb= sp;  DNS Server (translator)
Domain Name ----------------------------------> Host Identifier Address = ------------------------------>  IP address (physical site)

                                               (static)            Dynamically          &n= bsp;     (might change)    

Therefore, ithe transport can use the = static HI address which will not change during the communication. It seems perfect = for mobility. However, it is not true. The problem is that how the = up-to-date mapping information from the static HI address to the possible dynamic = IP address (if the node moves) is be obtained in the system. In the HIP = IETF draft, it says the DNS server is used to translate the Domain Name into Host Identifier Address and IP address at the same time. No matter whoever is = to translate the information, such information must be updated on a = real-time style. Otherwise you are going to lose the trace of the node. Therefore, = you need some sort of scheme like Registration Request and Registration = Reply to provide such information to the translator dynamically. Sounds familiar? = Yes, you are going to reinvent Mobile IP again. Never the less, because it introduces the static HI address to replace the traditional IP address = for the transport layer to use, it requires fundmental changes for the transport = layer and upper layers, e.g. all socket APIs must be rewritten to support HI addresses.

I think the authors also recognised this. = Let's look at its answer to the IRTF Name Space Research Group (NSRG) on the translation/resolution.

   9.  What would the = resolution mechanisms be, or what characteristics =
      = of a resolution mechanisms would be required?

       &= nbsp;  For most purposes, an approach where DNS names are = resolved
      =     simultaneously to HIs and IP addresses is = sufficient.
      =     However, if it becomes necessary to resolve HIs into = IP
      =     addresses or back to DNS names, = a flat resolution
      =     infrastructure is needed.  Such an infrastructure could be
      =     based on the ideas of Distributed Hash Tables, but = would
      =     require significant new development and deployment.

(Taken from: Host Identity Protocol = Architecture draft-ietf-hip-arch-02) =

 

Considering it brings similar functions to = the Mobile IP while requiring much more implement effort, I don't think it = has any opportunity to replace Mobile IP, which already has some = applictions.

Security:
However, it brings some novel ideas = of security which could be used or borrowed to deal with mobile = security.

Current Security IPsec = Problem
Current IPsec uses a local valid = index SPI, the IP destination address, and Security Protocol (AH/ESP) to find = the cyper key in the local database to decrypt the cipertext as = follows:

       &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;         cyper text
SPI     &nb= sp;           &nbs= p;            = ;   local = database           = ;            =             &= nbsp;            |
IP destination = address  ----------------------------------> cyper key = -------------------->|
SP                                              =                         |
      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;            clear text

However, in a case where the IP address = changes, the node will never be able to find the ciper key in its database using = the index. Therefore, the negotiation is needed to obtain another ciper key. = That is why IPsec is not working with a changed IP = address.

In Mobile IP, it is possible to negotiate = the ciper key using the node's Home Address which will stay the same during = the communication. Therefore, the cyper key can be found. This is the case = of what we say IPsec inside Mobile IP tunnel. However, to support mobility, the = node needs to talk with the HA in clear text because the cyper key is only = used between the MN and the VPN gateway (or the CN). This brings the = requirement of IPsec splitting tunnel which might pose some security risks.           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;          

Let's then look at what the HIP is trying = to achieve.

       &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;     cyper text
SPI     &nb= sp;           &nbs= p; local database           = ;            =             &= nbsp;            |
HI Address   ----------------------------------> = cyper key -------------------->|
SP                          &= nbsp;                                            |
      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =         clear text

It suggests because the HI address is = static, the cyper key could be used even the node moves (IP address changes). It = sounds good. But let's look back at the mobility part. The mobile node needs to = report the mapping information from the static HI address to the changed IP = address dynamically to the translator (DNS server), of course, in clear text, = since the cyper key is between the mobile node and the VPN gateway / or the CN. It = has the same splitting tunnel problem.

 

Summary:
To compare with MIP, HIP does not = bring any new advantages or functionalities on mobility and security. In = addition, it requires heavy development and fundmental changes for the tranport layer = and upper layers. My personally view is that it is never going to replace = MIP or mobility management.

It might do some help on security aspect = using public / private key to authenticate and exchange cyper key. Current = IPsec VPN mainly uses username and password to authenticate. However, this is not = a new idea as SSH is already using it. Definitly it is never going to happen = that the transport layer uses the HI address (public key) as the name space to = set up the communication.




------=_NextPart_000_0087_01C59E0F.10D32BE0-- --===============0567018776== 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 --===============0567018776==-- From hipsec-bounces@lists.ietf.org Wed Aug 10 11:47:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2snD-0008Dz-V4; Wed, 10 Aug 2005 11:46:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2snA-0008Bl-F2 for hipsec@megatron.ietf.org; Wed, 10 Aug 2005 11:46: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 LAA07154 for ; Wed, 10 Aug 2005 11:46:52 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2tLD-0002VM-Qt for hipsec@ietf.org; Wed, 10 Aug 2005 12:22:10 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 17:46:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: [Hipsec] HIP questions Date: Wed, 10 Aug 2005 17:46:41 +0200 Message-ID: Thread-Topic: [Hipsec] HIP questions Thread-Index: AcWdttGypkUfBS3xTFmQwG3hV5ZyFwABGWFQAADfaqAAAPiaYA== From: "DONG Song RD-ILAB-LON" To: X-OriginalArrivalTime: 10 Aug 2005 15:46:41.0697 (UTC) FILETIME=[B3E06110:01C59DC2] X-Spam-Score: 0.4 (/) X-Scan-Signature: 134781262af5db732816264224b9172c Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0729699628==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0729699628== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59DC2.B3BB59E4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59DC2.B3BB59E4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Joseph and others , =20 Thanks for your reply. Here are my points. =20 Whether using DNS or RVS, as I said is to provide the translation information to the server or the correspondent node (CN). RVS happens similarly to the Routing Optimisation in IPv6 by binding with CN directly. Even with RVS, you still need to report your presence to the DNS server in order for another person to connect you. The information in the DNS also needs freshly updated. =20 I didn't say MIP brings more security than HIP. Actually, it has no security except registration authentication. MIP plus IPsec can does the same as HIP is trying to do. Perhaps MIP could absorb the idea of Host Identifier (public key) to enhance itself, but definitely not by introducing another name space for the transport layer to use. =20 Regards, Song p.s. I would be very interesting to read your paper if it is ready. ________________________________ From: Joseph [mailto:joseph-so@gmx.net]=20 Sent: 10 August 2005 15:53 To: DONG Song RD-ILAB-LON; hipsec@ietf.org Subject: RE: [Hipsec] HIP questions Dear Song and other folk (who read this email), I think that HIP can replace MIP or co-operate with MIP, if commercial consideration is not included. (Just similar to many people said that IPv4 should be replaced by IPv6 within 2-5 years, when I was high school student. However, I'm postgraduate student now; IPv4 is not replaced yet. In the Mobility part, I want to make some notes. Beside the DNS server, we can use RVS to map between HI/HIT and MIP. The performance of RVS in the mobility area of HIP is much better than DNS. Furthermore, during the communication, mobile node can use update packet to readdressing. As the SA is not bonded to IP, so that the connection can be mapped into different IP address. I have even written a paper to talk about the initial merging in MIP and HIP. (I have submitted to conference, I can send to you if you are interested when the paper is accepted). For the security, I think HIP is much strength than MIP, in ESP connection mode, all the package are protected by ESP, but MIP is not. I'm an also new baby in HIP, I think there are a lot of professional in here can tell you more detail about the advantage about HIP over MIP. I think the problem of HIP not able to replace MIP is not technical, but commercial reason.=20 Please correct me if I have any mistake. Yours, Joseph =20 =20 ________________________________ From: hipsec-bounces@lists.ietf.org [mailto:hipsec-bounces@lists.ietf.org] On Behalf Of DONG Song RD-ILAB-LON Sent: Thursday, August 11, 2005 12:22 AM To: hipsec@ietf.org Subject: [Hipsec] HIP questions =20 =20 Hi all,=20 I recently have a study on HIP. Some people say it easily supports mobility by introducing HIP layer to separate transport layer and IP layer. Therefore it will even replace MIP. I don't think so. Following is my conclusion. If anybody could point out my misunderstanding, that will be very helpful. Pls keep the reading frame as large as possible in order to have a correct display of the diagrams. Thanks,=20 Song=20 France Telecom R&D UK=20 =20 The Host Identity Protocol (HIP) is a key establishment and parameter negotiation protocol. Its primary applications are for authenticating host messages based on host identities, and establishing security associations (SAs) for ESP transport format and possibly other protocols in the future. The authors also think it could bring more efficient mobility by decoupling the transport layer and internetworking layer. I personally don't believe it will pose any impact on Mobile IP. Here are my analysis.=20 Mobility:=20 There are mainly two address spaces in use in the internet. In order for two hosts to communicate with each other, an address space which could represent their physical places and is easy to route is required. That is the internetworking address (IP address). Another type of addresses are Domain names, including email address, http, and SIP addresses, which are easy to memorize and used directly by applications. Therefore the communication process will normally be as follows:=20 Transport Layer=20 |=20 |=20 DNS Server (translator) =20 Domain Name ---------------------------------------------------> IP address=20 The domain name will be tranlated into a IP address which represents the host's physical presence. Because the normal IP address is physically bound. The translation information located in DNS server is normally static and does not need dynamic(real time) update. However, because the IP address is bound to a physical site in the internet. It presents a problem for the application mobility since the transport layer is using the IP address. In this case, some sort of IP address which is not physically bound and can stay fixed during the communication is needed for the transport layer to use. That is the introduction of Mobile IP as follows: Transport Layer=20 |=20 |=20 DNS Server (translator) Home Agent (translator)=20 Domain Name ----------------------------------> Mobile IP Home Address ------------------------------> IP address (physical site) (static) Dynamically (might change) =20 >From the Mobile IP address to the physically bound IP address, there needs some sort of translator to provide the mapping information. That is the function of the Home Agent. To support mobility, the information must be updated dynamically along with the movement of the node. The Mobile Node uses Registration Request message to provide such information (or BU in IPV6). Then let's look at how HIP works.=20 It suggests using Host Identifier (HI) to decouple the transport layer and the IP layer as follows:=20 Transport Layer=20 |=20 | DNS Server (translator) DNS Server (translator)=20 Domain Name ----------------------------------> Host Identifier Address ------------------------------> IP address (physical site) (static) Dynamically (might change) =20 Therefore, ithe transport can use the static HI address which will not change during the communication. It seems perfect for mobility. However, it is not true. The problem is that how the up-to-date mapping information from the static HI address to the possible dynamic IP address (if the node moves) is be obtained in the system. In the HIP IETF draft, it says the DNS server is used to translate the Domain Name into Host Identifier Address and IP address at the same time. No matter whoever is to translate the information, such information must be updated on a real-time style. Otherwise you are going to lose the trace of the node. Therefore, you need some sort of scheme like Registration Request and Registration Reply to provide such information to the translator dynamically. Sounds familiar? Yes, you are going to reinvent Mobile IP again. Never the less, because it introduces the static HI address to replace the traditional IP address for the transport layer to use, it requires fundmental changes for the transport layer and upper layers, e.g. all socket APIs must be rewritten to support HI addresses. I think the authors also recognised this. Let's look at its answer to the IRTF Name Space Research Group (NSRG) on the translation/resolution. 9. What would the resolution mechanisms be, or what characteristics=20 of a resolution mechanisms would be required?=20 For most purposes, an approach where DNS names are resolved=20 simultaneously to HIs and IP addresses is sufficient.=20 However, if it becomes necessary to resolve HIs into IP=20 addresses or back to DNS names, a flat resolution=20 infrastructure is needed. Such an infrastructure could be=20 based on the ideas of Distributed Hash Tables, but would=20 require significant new development and deployment.=20 (Taken from: Host Identity Protocol Architecture draft-ietf-hip-arch-02) =20 Considering it brings similar functions to the Mobile IP while requiring much more implement effort, I don't think it has any opportunity to replace Mobile IP, which already has some applictions. Security:=20 However, it brings some novel ideas of security which could be used or borrowed to deal with mobile security.=20 Current Security IPsec Problem=20 Current IPsec uses a local valid index SPI, the IP destination address, and Security Protocol (AH/ESP) to find the cyper key in the local database to decrypt the cipertext as follows: =20 cyper text=20 SPI local database |=20 IP destination address ----------------------------------> cyper key -------------------->|=20 SP |=20 =20 clear text=20 However, in a case where the IP address changes, the node will never be able to find the ciper key in its database using the index. Therefore, the negotiation is needed to obtain another ciper key. That is why IPsec is not working with a changed IP address. In Mobile IP, it is possible to negotiate the ciper key using the node's Home Address which will stay the same during the communication. Therefore, the cyper key can be found. This is the case of what we say IPsec inside Mobile IP tunnel. However, to support mobility, the node needs to talk with the HA in clear text because the cyper key is only used between the MN and the VPN gateway (or the CN). This brings the requirement of IPsec splitting tunnel which might pose some security risks. Let's then look at what the HIP is trying to achieve.=20 =20 cyper text=20 SPI local database |=20 HI Address ----------------------------------> cyper key -------------------->|=20 SP |=20 =20 clear text=20 It suggests because the HI address is static, the cyper key could be used even the node moves (IP address changes). It sounds good. But let's look back at the mobility part. The mobile node needs to report the mapping information from the static HI address to the changed IP address dynamically to the translator (DNS server), of course, in clear text, since the cyper key is between the mobile node and the VPN gateway / or the CN. It has the same splitting tunnel problem. =20 Summary:=20 To compare with MIP, HIP does not bring any new advantages or functionalities on mobility and security. In addition, it requires heavy development and fundmental changes for the tranport layer and upper layers. My personally view is that it is never going to replace MIP or mobility management. It might do some help on security aspect using public / private key to authenticate and exchange cyper key. Current IPsec VPN mainly uses username and password to authenticate. However, this is not a new idea as SSH is already using it. Definitly it is never going to happen that the transport layer uses the HI address (public key) as the name space to set up the communication. ------_=_NextPart_001_01C59DC2.B3BB59E4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HIP = questions
 
Joseph  and = others ,
 
Thanks for your reply. Here are my=20 points.
 
Whether using DNS or RVS, as I said is to = provide the=20 translation information to the server or the correspondent node (CN). = RVS=20 happens similarly to the Routing Optimisation in IPv6 by binding with CN = directly. Even with RVS, you still need to report your presence to the = DNS=20 server in order for another person to connect you. The information in = the DNS=20 also needs freshly updated.
 
I didn't say MIP brings more security than HIP. = Actually,=20 it has no security except registration authentication. MIP plus IPsec = can does=20 the same as HIP is trying to do. Perhaps MIP could absorb the idea = of Host=20 Identifier (public key) to enhance itself, but definitely not by=20 introducing another name space for the transport layer to=20 use.
 
Regards,
Song
p.s. I would be very interesting t= o read your paper if it is ready.
From: Joseph = [mailto:joseph-so@gmx.net]=20
Sent: 10 August 2005 15:53
To: DONG Song = RD-ILAB-LON;=20 hipsec@ietf.org
Subject: RE: [Hipsec] HIP=20 questions

Dear Song and = other folk=20 (who read this email),

          =20 I think that HIP can replace MIP or co-operate with MIP, if commercial=20 consideration is not included. (Just similar to many people said that = IPv4=20 should be replaced by IPv6 within 2-5 years, when I was high school = student.=20 However, I’m postgraduate student now; IPv4 is not replaced=20 yet.

          =20 In the Mobility part, I want to make some notes. Beside the DNS server, = we can=20 use RVS to map between HI/HIT and MIP. The performance of RVS in the = mobility=20 area of HIP is much better than DNS. Furthermore, during the = communication,=20 mobile node can use update packet to readdressing. As the SA is not = bonded to=20 IP, so that the connection can be mapped into different IP address. I = have even=20 written a paper to talk about the initial merging in MIP and HIP. (I = have=20 submitted to conference, I can send to you if you are interested when = the paper=20 is accepted). For the security, I think HIP is much strength than MIP, = in ESP=20 connection mode, all the package are protected by ESP, but MIP is=20 not.

          =20 I’m an also new baby in HIP, I think there are a lot of = professional in here can=20 tell you more detail about the advantage about HIP over MIP. I think the = problem=20 of HIP not able to replace MIP is not technical, but commercial reason.=20

          =20 Please correct me if I have any mistake.

Yours,

Joseph

 

 

From: = hipsec-bounces@lists.ietf.org=20 [mailto:hipsec-bounces@lists.ietf.org] On=20 Behalf Of DONG Song RD-ILAB-LON
Sent: Thursday, August 11, 2005 = 12:22=20 AM
To:=20 hipsec@ietf.org
Subject:=20 [Hipsec] HIP questions

 

 

Hi all,

I recently have a study on = HIP. Some=20 people say it easily supports mobility by introducing HIP layer to = separate=20 transport layer and IP layer. Therefore it will even replace MIP. I = don't think=20 so. Following is my conclusion. If anybody could point out my = misunderstanding,=20 that will be very helpful. Pls keep the reading frame as large as = possible in=20 order to have a correct display of the diagrams.

Thanks,
Song=20

France=20 Telecom R&D UK=20

 

The Host = Identity=20 Protocol (HIP) is a key establishment and parameter negotiation = protocol. =20 Its primary applications are for authenticating host messages based on = host=20 identities, and establishing security associations (SAs) for ESP = transport=20 format and possibly other protocols in the future.

The authors = also think=20 it could bring more efficient mobility by decoupling the transport layer = and=20 internetworking layer. I personally don't believe it will pose any = impact on=20 Mobile IP.

Here are my=20 analysis.

Mobility:
There are = mainly two=20 address spaces in use in the internet. In order for two hosts to = communicate=20 with each other, an address space which could represent their physical = places=20 and is easy to route is required. That is the internetworking address = (IP=20 address). Another type of addresses are Domain names, including email = address,=20 http, and SIP addresses, which are easy to memorize and used directly by = applications.

Therefore the = communication process will normally be as follows:

       =20        =20        =20        =20        =20         Transport=20 Layer
       =20        =20        =20        =20        =20        =20         |
       =20        =20        =20        =20        =20        =20         |
       =20             DNS=20 Server (translator)    
Domain = Name  =20 ---------------------------------------------------> IP=20 address

The domain = name will be=20 tranlated into a IP address which represents the host's physical = presence.=20 Because the normal IP address is physically bound. The translation = information=20 located in DNS server is normally static and does not need dynamic(real = time)=20 update.

However, = because the IP=20 address is bound to a physical site in the internet. It presents a = problem for=20 the application mobility since the transport layer is using the IP = address. In=20 this case, some sort of IP address which is not physically bound and can = stay=20 fixed during the communication is needed for the transport layer to use. = That is=20 the introduction of Mobile IP as follows:

       =20        =20        =20        =20         Transport=20 Layer
       =20        =20        =20        =20        =20           =20 |
       =20        =20        =20        =20                    =    =20 |
       =20         DNS Server=20 (translator)          &= nbsp;           &n= bsp;           &nb= sp;   =20 Home Agent (translator) =
Domain Name=20 ----------------------------------> Mobile IP Home Address=20 ------------------------------>  IP address (physical=20 site)

       =20        =20        =20        =20               =20 (static)        =20      =20 Dynamically          &n= bsp;    =20 (might change)    

From the = Mobile IP=20 address to the physically bound IP address, there needs some sort of = translator=20 to provide the mapping information. That is the function of the Home = Agent. To=20 support mobility, the information must be updated dynamically along with = the=20 movement of the node. The Mobile Node uses Registration Request message = to=20 provide such information (or BU in IPV6).

Then let's = look at how=20 HIP works.

It suggests = using Host=20 Identifier (HI) to decouple the transport layer and the IP layer as=20 follows:

       =20        =20        =20        =20          Transport=20 Layer
       =20        =20        =20        =20        =20         |
       =20        =20        =20        =20        =20         |      =20        =20             =20
       =20         DNS Server=20 (translator)          &= nbsp;           &n= bsp;           &nb= sp; =20 DNS Server (translator) =
Domain Name=20 ----------------------------------> Host Identifier Address=20 ------------------------------>  IP address (physical=20 site)

       =20        =20        =20        =20               =20 (static)           =20 Dynamically          &n= bsp;    =20 (might change)    

Therefore, = ithe=20 transport can use the static HI address which will not change during the = communication. It seems perfect for mobility. However, it is not true. = The=20 problem is that how the up-to-date mapping information from the static = HI=20 address to the possible dynamic IP address (if the node moves) is be = obtained in=20 the system. In the HIP IETF draft, it says the DNS server is used to = translate=20 the Domain Name into Host Identifier Address and IP address at the same = time. No=20 matter whoever is to translate the information, such information must be = updated=20 on a real-time style. Otherwise you are going to lose the trace of the = node.=20 Therefore, you need some sort of scheme like Registration Request and=20 Registration Reply to provide such information to the translator = dynamically.=20 Sounds familiar? Yes, you are going to reinvent Mobile IP again. Never = the less,=20 because it introduces the static HI address to replace the traditional = IP=20 address for the transport layer to use, it requires fundmental changes = for the=20 transport layer and upper layers, e.g. all socket APIs must be rewritten = to=20 support HI addresses.

I think the = authors=20 also recognised this. Let's look at its answer to the IRTF Name Space = Research=20 Group (NSRG) on the translation/resolution.

   = 9. =20 What would the resolution mechanisms be, or what=20 characteristics
      =20 of a resolution mechanisms would be required?=20

         =20 For most purposes, an approach where DNS names are = resolved
         =20 simultaneously to HIs and IP addresses is = sufficient.
         =20 However, if it becomes necessary to resolve HIs into = IP
         =20 addresses or back to DNS names,=20 a flat=20 resolution
         =20 infrastructure is needed.  Such = an=20 infrastructure could be =
         =20 based on the ideas of Distributed Hash Tables, but = would
         =20 require significant new development and deployment.

(Taken from: = Host=20 Identity Protocol Architecture = draft-ietf-hip-arch-02)

 

Considering = it brings=20 similar functions to the Mobile IP while requiring much more implement = effort, I=20 don't think it has any opportunity to replace Mobile IP, which already = has some=20 applictions.

Security:
However, it = brings some=20 novel ideas of security which could be used or borrowed to deal with = mobile=20 security.

Current = Security IPsec=20 Problem
Current IPsec = uses a=20 local valid index SPI, the IP destination address, and Security Protocol = (AH/ESP) to find the cyper key in the local database to decrypt the = cipertext as=20 follows:

           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;    =20 cyper text
SPI          &nb= sp;           &nbs= p;         =20 local=20 database           = ;            =             &= nbsp;           =20 |
IP = destination=20 address =20 ----------------------------------> cyper key=20 -------------------->| =
SP     =20        =20        =20        =20        =20        =20        =20        =20         |=20
           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;      =20 clear text

However, in a = case=20 where the IP address changes, the node will never be able to find the = ciper key=20 in its database using the index. Therefore, the negotiation is needed to = obtain=20 another ciper key. That is why IPsec is not working with a changed IP=20 address.

In Mobile IP, = it is=20 possible to negotiate the ciper key using the node's Home Address which = will=20 stay the same during the communication. Therefore, the cyper key can be = found.=20 This is the case of what we say IPsec inside Mobile IP tunnel. However, = to=20 support mobility, the node needs to talk with the HA in clear text = because the=20 cyper key is only used between the MN and the VPN gateway (or the CN). = This=20 brings the requirement of IPsec splitting tunnel which might pose some = security=20 risks.           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;          =20

Let's then = look at what=20 the HIP is trying to achieve.=20

           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =  =20 cyper text
SPI          &nb= sp;       =20 local=20 database           = ;            =             &= nbsp;           =20 |
HI=20 Address  =20 ----------------------------------> cyper key=20 -------------------->| =
SP     =20        =20             &= nbsp;          =20        =20        =20        =20          |
           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =   =20 clear text

It suggests = because the=20 HI address is static, the cyper key could be used even the node moves = (IP=20 address changes). It sounds good. But let's look back at the mobility = part. The=20 mobile node needs to report the mapping information from the static HI = address=20 to the changed IP address dynamically to the translator (DNS server), of = course,=20 in clear text, since the cyper key is between the mobile node and the = VPN=20 gateway / or the CN. It has the same splitting tunnel=20 problem.

 

Summary:
To compare = with MIP,=20 HIP does not bring any new advantages or functionalities on mobility and = security. In addition, it requires heavy development and fundmental = changes for=20 the tranport layer and upper layers. My personally view is that it is = never=20 going to replace MIP or mobility management.

It might do = some help=20 on security aspect using public / private key to authenticate and = exchange cyper=20 key. Current IPsec VPN mainly uses username and password to = authenticate.=20 However, this is not a new idea as SSH is already using it. Definitly it = is=20 never going to happen that the transport layer uses the HI address = (public key)=20 as the name space to set up the communication.




------_=_NextPart_001_01C59DC2.B3BB59E4-- --===============0729699628== 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 --===============0729699628==-- From hipsec-bounces@lists.ietf.org Wed Aug 10 12:27:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2tQn-0003Tv-3i; Wed, 10 Aug 2005 12:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2tQl-0003Tn-Qp for hipsec@megatron.ietf.org; Wed, 10 Aug 2005 12:27: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 MAA09385 for ; Wed, 10 Aug 2005 12:27:48 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2tym-0003Z0-V3 for hipsec@ietf.org; Wed, 10 Aug 2005 13:03:08 -0400 Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5D301A3E50E; Wed, 10 Aug 2005 18:27:24 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: FW: [Hipsec] HIP questions Date: Wed, 10 Aug 2005 18:28:45 +0200 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508101828.46250.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit 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 On Wednesday 10 August 2005 17:46, DONG Song RD-ILAB-LON wrote: > > Whether using DNS or RVS, as I said is to provide the translation > information to the server or the correspondent node (CN). RVS > happens similarly to the Routing Optimisation in IPv6 by binding > with CN directly. Even with RVS, you still need to report your > presence to the DNS server in order for another person to connect > you. The information in the DNS also needs freshly updated. When you use a RVS, you don't report your presence to the DNS nor do you updated it regularly. You just happen to store your RVS's IP address or FQDN, and then you only update the RVS with your current location. > I didn't say MIP brings more security than HIP. Actually, it has no > security except registration authentication. MIP plus IPsec can > does the same as HIP is trying to do. Perhaps MIP could absorb the > idea of Host Identifier (public key) to enhance itself, but > definitely not by introducing another name space for the transport > layer to use. Well... In your first email you also wrote "all socket APIs must be rewritten to support HI addresses." First there's are no such HI addresses. There are HIs, HITs, and IP addresses. And as a matter of a fact, the mail client with which I write this message sits on vanilla socket API and TCP/IP stack (i.e. unmodified), in which HITs and IPv6 addresses have lived happily together in the same data structures for now more than three years. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 10 12:59:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2tvd-00047G-1L; Wed, 10 Aug 2005 12:59:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2tvb-00047A-CK for hipsec@megatron.ietf.org; Wed, 10 Aug 2005 12:59:43 -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 MAA10976 for ; Wed, 10 Aug 2005 12:59:40 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2uTk-0004TI-1k for hipsec@ietf.org; Wed, 10 Aug 2005 13:35:00 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 18:59:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: FW: [Hipsec] HIP questions Date: Wed, 10 Aug 2005 18:59:24 +0200 Message-ID: Thread-Topic: FW: [Hipsec] HIP questions Thread-Index: AcWdyHRtEQrS9mQJRkaklffHng3yTQAAwPBA From: "DONG Song RD-ILAB-LON" To: X-OriginalArrivalTime: 10 Aug 2005 16:59:25.0403 (UTC) FILETIME=[DCD912B0:01C59DCC] X-Spam-Score: 0.6 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0904308015==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0904308015== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59DCC.DCCF96A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59DCC.DCCF96A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Julien Laganier [mailto:julien.IETF@laposte.net] Sent: 10 August 2005 17:29 To: hipsec@ietf.org Cc: DONG Song RD-ILAB-LON Subject: Re: FW: [Hipsec] HIP questions On Wednesday 10 August 2005 17:46, DONG Song RD-ILAB-LON wrote: > > Whether using DNS or RVS, as I said is to provide the translation > information to the server or the correspondent node (CN). RVS happens > similarly to the Routing Optimisation in IPv6 by binding with CN > directly. Even with RVS, you still need to report your presence to the > DNS server in order for another person to connect you. The information > in the DNS also needs freshly updated. When you use a RVS, you don't report your presence to the DNS nor do you updated it regularly. You just happen to store your RVS's IP address or FQDN, and then you only update the RVS with your current location. To me, it is the same as to register with the HA using CoA (the foreign agent's address) in mobile ip. If you move within the same FA area, you don't need to register with you HA regularly. > I didn't say MIP brings more security than HIP. Actually, it has no > security except registration authentication. MIP plus IPsec can does > the same as HIP is trying to do. Perhaps MIP could absorb the idea of > Host Identifier (public key) to enhance itself, but definitely not by > introducing another name space for the transport layer to use. Well... In your first email you also wrote "all socket APIs must be rewritten to support HI addresses." First there's are no such HI addresses. There are HIs, HITs, and IP addresses. And as a matter of a fact, the mail client with which I write this message sits on vanilla socket API and TCP/IP stack (i.e. unmodified), in which HITs and IPv6 addresses have lived happily together in the same data structures for now more than three years. I am not surprised it works ok as the HIT has the same length with a IPv6 address (128 bits). Of course you can reutilise it if you have a IPv6 stack or dual stack. But does anybody have it? --Song ------_=_NextPart_001_01C59DCC.DCCF96A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable



-----Original Message-----
From: Julien = Laganier [mailto:julien.IETF@laposte.net]
Sent:=20 10 August 2005 17:29
To: hipsec@ietf.org
Cc: DONG Song=20 RD-ILAB-LON
Subject: Re: FW: [Hipsec] HIP questions

On = Wednesday 10=20 August 2005 17:46, DONG Song RD-ILAB-LON wrote:
>
> Whether = using=20 DNS or RVS, as I said is to provide the translation
> information = to the=20 server or the correspondent node (CN). RVS happens
> similarly to = the=20 Routing Optimisation in IPv6 by binding with CN
> directly. Even = with RVS,=20 you still need to report your presence to the
> DNS server in = order for=20 another person to connect you. The information
> in the DNS also = needs=20 freshly updated.

When you use a RVS, you don't report your = presence to=20 the DNS nor do you updated it regularly. You just happen to store your = RVS's IP=20 address or FQDN, and then you only update the RVS with your current=20 location.

To me, it is the same as to = register with=20 the HA using CoA (the foreign agent's address) in mobile ip. If you move = within=20 the same FA area, you don't need to register with you HA=20 regularly.

> I didn't say MIP brings more security than = HIP.=20 Actually, it has no
> security except registration authentication. = MIP=20 plus IPsec can does
> the same as HIP is trying to do. Perhaps MIP = could=20 absorb the idea of
> Host Identifier (public key) to enhance = itself, but=20 definitely not by
> introducing another name space for the = transport layer=20 to use.

Well... In your first email you also wrote "all socket = APIs must=20 be rewritten to support HI addresses."

First there's are no such = HI=20 addresses. There are HIs, HITs, and IP addresses. And as a matter of a = fact, the=20 mail client with which I write this message sits on vanilla socket API = and=20 TCP/IP stack (i.e.
unmodified), in which HITs and IPv6 addresses have = lived=20 happily together in the same data structures for now more than three=20 years.

I am not surprised it works ok as = the HIT has=20 the same length with a IPv6 address (128 bits). Of course you can = reutilise it=20 if you have a IPv6 stack or dual stack. But does anybody have=20 it?

--Song

------_=_NextPart_001_01C59DCC.DCCF96A0-- --===============0904308015== 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 --===============0904308015==-- From hipsec-bounces@lists.ietf.org Thu Aug 11 08:05:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Boa-00089e-Qz; Thu, 11 Aug 2005 08:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3BoZ-00088T-2P for hipsec@megatron.ietf.org; Thu, 11 Aug 2005 08:05:39 -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 IAA26147 for ; Thu, 11 Aug 2005 08:05:38 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3CMo-0002gs-UP for hipsec@ietf.org; Thu, 11 Aug 2005 08:41:06 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 41585212CB1 for ; Thu, 11 Aug 2005 15:05:23 +0300 (EEST) From: Petri Jokela To: hipsec@ietf.org In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512A88@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D512A88@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain Date: Thu, 11 Aug 2005 15:05:20 +0300 Message-Id: <1123761920.15953.28.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Type 1 and 2 HITs X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, at the HIP WG meeting in Paris, it was proposed that Type 2 HITs will be removed from specifications (base draft, DNS draft) and Type 1 HITs will be the only type of HITs at this point of time. Concensus was that Type 2 HITs will be removed. Current implementations do not support them and there were no plans from anyone to implement the support now. The HIT will be formed from a prefix and a hash over the HI (like it is already defined in the base draft version -03). In addition, a new draft will be written describing the prefix that would be used for HITs (and for other similar purposes). This prefix should be allocated from the IPv6 address space and the draft is planned to be submitted to the IPv6 WG. Using the prefix, new HIT types can be defined in the future. If there comes up a need for "Type 2" properties, a new HIT type can be defined later using this prefix. So, before removing them from the base draft, please give comments if you think that Type 2 HITs should be kept in the draft. This request is mainly targetted to those who were not able to participate the HIP WG meeting. /Petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 12 08:45:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3YuI-0005rm-Pf; Fri, 12 Aug 2005 08:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3YuF-0005m3-3R for hipsec@megatron.ietf.org; Fri, 12 Aug 2005 08:45: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 IAA19610 for ; Fri, 12 Aug 2005 08:45:01 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ZSk-0007yz-9V for hipsec@ietf.org; Fri, 12 Aug 2005 09:20:43 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BAADD212CA9; Fri, 12 Aug 2005 15:44:52 +0300 (EEST) Subject: Re: [Hipsec] comments on the WGLC drafts From: Petri Jokela To: "Henderson, Thomas R" In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512A97@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D512A97@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain Date: Fri, 12 Aug 2005 15:44:49 +0300 Message-Id: <1123850690.10662.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Sun, 2005-07-31 at 15:17 -0700, Henderson, Thomas R wrote: > I read through them this weekend again and think they are in good shape > to move forward. A few minor points below to add to the final "issues" > list: > > Base draft > ---------- > Appendices A and B probably can be deleted at this time, or edited > (perhaps combined into a combined informative appendix "Probabilities > on certain HIP computations". At the very least, Appendix B reads like > it was copied and pasted from an email message and should be edited. > The Appendix B refers to the old limit 2^K when cookie solution is calculated. That value has not been around for a long time (not since draft -00). Current draft limits calculation to the puzzle lifetime: When the puzzle lifetime expires, the Initiator shoud give up and restart the HIP negotiation. Thus, in the current form, Appendix B does not give any relevant information. It should be completely rewritten, taking into account the puzzle lifetime that is not a fixed value, but decided by the Responder. In Appendix A, when the Type 2 HIT is dropped from the draft, the only information will be the HIT collision probability related to 120-bit HITs: 0.001% probability with 5*10^15 hosts. I vote for dropping the appendices A and B from the draft. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Aug 15 09:10:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ejY-0005Ec-3Q; Mon, 15 Aug 2005 09:10:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ejR-0005EX-Qq for hipsec@megatron.ietf.org; Mon, 15 Aug 2005 09:10:25 -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 JAA01955 for ; Mon, 15 Aug 2005 09:10:24 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4fIZ-0006kR-Hq for hipsec@ietf.org; Mon, 15 Aug 2005 09:46:44 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3A81D212CA9 for ; Mon, 15 Aug 2005 16:10:06 +0300 (EEST) From: Petri Jokela To: hipsec@ietf.org Content-Type: text/plain Date: Mon, 15 Aug 2005 16:10:03 +0300 Message-Id: <1124111403.10041.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Base draft & ESP draft: snapshots 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 snapshots of the base draft and ESP draft to our server. Few small existing issues are missing still from those, but mainly all comments are included. http://hip4inter.net/drafts.php draft-ietf-hip-base-04-pre150805 draft-ietf-hip-esp-01-pre150805 ESP draft references are fixed (there were few bugs in them). BEET reference is still wrong in the web version, but fixed on my disk. Base draft references must still be verfied. Draft's date is wrong (fixed on my disk). TXT, HTML, XML and diffs available. /Petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 16 08:54:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50xp-0008Vf-Om; Tue, 16 Aug 2005 08:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50xn-0008Ul-Td for hipsec@megatron.ietf.org; Tue, 16 Aug 2005 08:54:44 -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 IAA08358 for ; Tue, 16 Aug 2005 08:54:42 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E51X9-00005E-2t for hipsec@ietf.org; Tue, 16 Aug 2005 09:31:15 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CF04E212CA9 for ; Tue, 16 Aug 2005 15:54:29 +0300 (EEST) From: Petri Jokela To: hipsec@ietf.org Content-Type: text/plain Date: Tue, 16 Aug 2005 15:54:27 +0300 Message-Id: <1124196867.9248.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] HIP base draft issues X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, I found some definition related problems from the base draft. MSL was not defined in the draft, so I added the following paragraph in 2.3. "Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is expected to spend in the network. " There are conflicting notations in the draft. "|" is defined to be both concatenation (section 2.2) and "or" operation (section 5.3) and "y" is defined to be "x encrypted with y" (2.2) and "x exists y times" (5.3). >From these, the following were not used anywhere (or at least I couldn't find them) and I removed them to avoid conflicting definitions: y indicates that "x" is encrypted with the key "y". x|y x or y If you have anything else to add to Notation or Definitions sections, please give input. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 16 11:05:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E530M-00070B-3s; Tue, 16 Aug 2005 11:05:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E530J-0006xk-UF for hipsec@megatron.ietf.org; Tue, 16 Aug 2005 11:05:27 -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 LAA16868 for ; Tue, 16 Aug 2005 11:05:25 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E53Zf-0003aZ-Og for hipsec@ietf.org; Tue, 16 Aug 2005 11:42:00 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 581C4212CA9; Tue, 16 Aug 2005 18:05:08 +0300 (EEST) In-Reply-To: <1124111403.10041.10.camel@localhost.localdomain> References: <1124111403.10041.10.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Tue, 16 Aug 2005 17:05:05 +0200 To: Petri Jokela X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 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 Petri, Late comments on the drafts; I am really sorry for being this late. In general, I'm afraid that the document is *NOT* ready for the =20 IESG. That is, as we are now proceeding to publication, I'd like us =20 to apply a little bit of extra scrutiny to see that everything really =20= is as we would like to see them during the next 2-5 years, at least. =20= We have to remember that *if* HIP takes its potential place in the =20 Internet architecture, the document that we are about to launch may =20 become as seminal as RFC 791 is today. I also feel that my review, =20 resulting in these comments, is *NOT* sufficient. We also need to =20 get some serious cross-area reviews. Now, based on that background, I'd first like to discuss if we really =20= find the current abstract to say what we want to say: > This memo specifies the details of the Host Identity Protocol =20 > (HIP). HIP provides a rapid exchange of Host Identities (public =20 > keys) between hosts and uses a Sigma-compliant Diffie-Hellman key =20 > exchange to establish shared secrets between such endpoints. The =20 > protocol is designed to be resistant to Denial-of-Service (DoS) and =20= > Man-in-the-middle (MitM) attacks, and when used together with =20 > another suitable security protocol, such as Encapsulated Security =20 > Payload (ESP), it provides encryption and/or authentication =20 > protection for upper layer protocols such as TCP and UDP, while =20 > enabling continuity of communications across network layer address =20 > changes. Discussion related to this document is going on at IETF =20 > HIP Working Group mailing list. I would suggest replacing it with almost completely with new text. =20 Here is an initial approximation of what it could be: This memo specifies the details of the Host Identity Protocol (HIP). =20= HIP allows consenting hosts to securely establish and maintain shared =20= IP-layer state, allowing separation of the identifier and locator =20 roles of IP addresses, thereby enabling continuity of communications =20 across IP address changes. HIP is based on a Sigma-compliant Diffie-=20 Hellman key exchange, using public-key identifiers from a new Host =20 Identity name space for mutual peer authentication. The protocol is =20 designed to be resistant to Denial-of-Service (DoS) and Man-in-the-=20 middle (MitM) attacks, and when used together with another suitable =20 security protocol, such as Encapsulated Security Payload (ESP), it =20 provides integrity protection and optional encryption for upper layer =20= protocols, such as TCP and UDP. Comments? -- Another substantial issues is the HIT format (Sections 3.1 and 3.2; =20 plus Appendix B). Personally, I expect it to change slightly as a =20 result of the forthcoming discussion in the IPv6 WG. BTW, the draft =20 that Julien and I promised in Paris has been written but currently =20 waits for additional comments from Francis; once we get them, it will =20= be out. Somewhat relatedly, now that we are proposing that the HIT prefix =20 would be defaulted back to IANA in 2009, unless the IETF decided =20 otherwise, perhaps we should do the same for the HIP protocol number =20 (Section 4?). If so, an appropriate IANA note should be added to the =20= IANA Considerations section. -- In Section 5.1.1, do we need the SHT and DHT fields any more, now =20 that we are giving up other types of HIT than Type 1, and determined =20 that the prefix must give unique encoding to the rest of the HIT? I =20 think we can safely drop them, leaving the A bit the only control =20 currently defined. If we decide to remove these, I think we can also =20= remove the HIT Type number space from the IANA considerations section. - - - - - - - Semi-substantial: Section 1: Some sort of further guidance to the other features of the protocol =20 are needed in the end of Section 1.2. THat is, a sentence or two =20 about UPDATE and CLOSING associations. Secondly, we need some kind of a document roadmap section towards the =20= end of Section 1. Perhaps something like the following (with all =20 "Section XXX" being links): 1.3 Memo structure The rest of this memo is structured as follows. Section 2 defines =20 the central keywords, notation, and terms used throughout the rest of =20= the document. Section 3 defines the structure of the Host Identity =20 and its various representations. Section 4 gives an overview of the =20 HIP base exchange protocol. Sections 5 and 6 define the detail =20 packet formats and rules for packet processing. Finally, sections 7, =20= 8, and 9 discuss policy, security, and IANA considerations, =20 respectively. Section 3: I think we need to add one sentence into the beginning. In this section, the properties of the Host Identifier and Host =20 Identifier Tag are discussed, and the exact format for them is =20 defined. In HIP, ... Section 4.1, paragraph 3: > The Initiator first sends a trigger packet, I1, to the Responder. =20 > The packet contains only the HIT of the Initiator and possibly the =20 > HIT of the Responder, if it is known. I suggest that we add the following sentence to the end of the =20 paragraph: Note that in some cases it may be possible to replace this trigger =20 packet by some other form of a trigger, in which case the protocol =20 starts with the Responder sending the R1 packet. Section 4.1.1: I think the following recommendation is too strong, and I propose =20 that we replace it as follows: > Against such an attacker it is probably best to create a piece of =20 > local state, and remember that the puzzle check has previously failed. replace with: Against such an attacker a viable approach may be to create a piece =20 of local state, and remember that the puzzle check has previously =20 failed. Section 4.1.1: I propose adding a new subsection title before the paragraph starting =20= "The Responder starts the cookie ..." A suitable title might be 4.1.2 Puzzle exchange (N.B. I didn't check the table and figure in 4.4.2 and 4.4.3; I =20 suggest someone would do that, with scrutiny. I find myself wondering if sections 5.1.3 and 5.1.4 should be moved =20 to Section 6, e.g., between current 6.2 and 6.3? There appears to be a minor problem between 6.13 and 6.14. 6.13 says =20= that CLOSE may be answered with an ICMP, 6.14 that they are dropped. I am not sure if the division of references between normative and =20 informative is right, but after having read through the document I am =20= too tired to consider each of them in detail. - - - - - - - Terminology: Section 4.1, figure, and rest of the document: What is the difference between "check cookie" and "check puzzle". I =20 propose that we give up using the term "cookie" altogether and just =20 just "puzzle" instead. Section 4.1.1, and later: I propose changing the term "TLV", when used as a noun, with the term =20= "parameter", and use the term "TLV" only as an adjective, as in "TLV =20 format". Need to specify "LSI" briefly in Section 2 as it is used in 6.1 Replace all occurences of "HIP session" with "HIP association", e.g. =20 in 6.1. "Opportunistic mode" should be explained: "HIP base exchange where =20 the Responder's HIT is not a priori known to the Initiator" or =20 something like that. - - - - - - - Editorial: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Seciotn 1: > Instead, in HIP, the host identifiers are public keys of a public/=20 > private key pair. By using public keys (and their representations) =20= > as host identifiers, to which higher layer protocols are bound =20 > instead of an IP address, dynamic changes to IP address sets can be =20= > directly authenticated between hosts, and ... replace with: In HIP, public cryptographic keys, of a public/private key pair, are =20 used as Host Identifiers, to which higher layer protocols are bound =20 instead of an IP address. By using public keys (and their representations) as host identifiers, =20= dynamic changes to IP address sets can be directly authenticated =20 between hosts and ... > to establish communications context (keying material, per-packet =20 > context tags) replace with: to establish an IP-layer communications context, called HIP =20 association, ... > for encryption and/or authentication protection, mobility and host =20 > multihoming extensions, DNS extensions for storing host identities, =20= > HIP-related infrastructure in the network, techniques for NAT =20 > traversal, and possibly other future extensions. replace with: for integrity protection and optional encryption, mobility and multi-=20 homing extensions to HIP, extensions to the Domain Name System (DNS) =20 for storing Host Identities there, proposals on added HIP-related =20 infrastructure into the networks, and techniques for NAT traversal. 1.1; editorial: > The Host Identity Protocol introduces a new namespace, the Host =20 > Identity. Some ramifications of this new namespace are explained in =20= > the companion document, the HIP architecture (Moskowitz, R., =93Host =20= > Identity Protocol Architecture,=94 January 2005.)[25] specification. replace with: The Host Identity Protocol introduces a new name space, the Host =20 Identity name space. Some ramifications of this new namespace are =20 explained in the HIP architecture description [25]. 2; editorial: All notes about sections needing work need to be resolved. We can't =20 send a document to the IESG noting that it needs work somewhere. 2.2 and 2.3; formatting: I suggest using a definition list format instead of the currently =20 used normal paragraphs. Section 3, before 3.1: The last paragraph is hard to understand; it feels out of context. I =20= don't have any suggestion how to correct that now, though. Section 4: Replace the current Editor's note with an appropriate IANA note > change HIP state replace with: change HIP association state > separate extension documents, replace with: separate documents, Section 4.1: > a signature using such key. The insert "a" between "such" and "key". Section 4.1.1: The following sentences requires a forward references to the =20 approriate TLVs: > The Initiator SHOULD give up after exceeding the puzzle lifetime in =20= > the PUZZLE TLV. > Using the Opaque data field in an ECHO_REQUEST parameter, W.r.t > The Responder MUST change the secret periodically. replace "the secret" with "such a secret" Section 4.1.2: > key and its (optionally) encrypted public authentication key. replace "its (optionally) encrypted public" with "its (optionally encrypted) public" Section 4.4: > may be introduced by mechanisms in other drafts (such as mobility and replace "drafts" with "documents" or "specifications".. 4.4.1, the table Replace "HIP" in "Initiating HIP" and "finish HIP" with "base exchange". Replace "finish" with "complete" 4.5.1, > sockets bound to HITs, the IPv6 pseudo-header format [11] MUST be =20 > used, even if the outer addresses on the packet are IPv4 addresses. =20= > Additionally, the HITs MUST Replace "outer" with "actual" 4.5.4 would benefit from slight editing, especially the second and =20 last paragraphs. 4.6: > The parameter type value, used for carrying certificates, is =20 > reserved: CERT, Type 768. replace with A parameter type value, meant to used for carrying certificates, is =20 reserved, though: CERT, Type 768; see Section X.X. 5.1: s/IPV6/IPv6/ > However, implementations MUST ignore trailing data replace with: However, current implementations MUST ignore trailing data 5.1.3 > MUST be implemented only in IPv4 (IPv4 stacks and networks will =20 > usually do this by default) and SHOULD be implemented in IPv6. In =20 > IPv6 networks, the minimum replace with is REQUIRED to be implemented in IPv4 (IPv4 stacks and networks will =20 usually do this by default) and RECOMMENDED to be implemented in =20 IPv6. In IPv6 networks, the minimum 5.2: s/beteween/between/ Sections 6.1. and 6.2. appear hard to read to the uninitiated, most =20 probably due to their long and convoluted history. Partial rewrite =20 would probably help. 6.11.1 s/paramaeter/parameter/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 16 11:39:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53Ws-0004g6-99; Tue, 16 Aug 2005 11:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53Wr-0004fy-3f for hipsec@megatron.ietf.org; Tue, 16 Aug 2005 11:39:05 -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 LAA18722 for ; Tue, 16 Aug 2005 11:39:02 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E546A-0004TT-MN for hipsec@ietf.org; Tue, 16 Aug 2005 12:15:38 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA07029; Tue, 16 Aug 2005 10:38:44 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j7GFchs27297; Tue, 16 Aug 2005 08:38:43 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 08:38:37 -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] Base draft & ESP draft: snapshots Date: Tue, 16 Aug 2005 08:38:37 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D512B07@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base draft & ESP draft: snapshots Thread-Index: AcWidBanzLwx7L03QReMg8P9+HiIKwAAd/sA From: "Henderson, Thomas R" To: "Pekka Nikander" , "Petri Jokela" X-OriginalArrivalTime: 16 Aug 2005 15:38:37.0515 (UTC) FILETIME=[91C291B0:01C5A278] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, August 16, 2005 8:05 AM > To: Petri Jokela > Cc: hipsec@ietf.org > Subject: Re: [Hipsec] Base draft & ESP draft: snapshots >=20 > Petri, >=20 > Late comments on the drafts; I am really sorry for being this late. >=20 > In general, I'm afraid that the document is *NOT* ready for=20 > the IESG. That is, as we are now proceeding to publication,=20 > I'd like us to apply a little bit of extra scrutiny to see=20 > that everything really =20 > is as we would like to see them during the next 2-5 years, at=20 > least. =20 > We have to remember that *if* HIP takes its potential place=20 > in the Internet architecture, the document that we are about=20 > to launch may become as seminal as RFC 791 is today. I also=20 > feel that my review, resulting in these comments, is *NOT*=20 > sufficient. We also need to get some serious cross-area reviews. Pekka, I happen to agree with you that the drafts could be improved. However, when I have suggested this in the past, the feedback that I received was that the WG wanted to err on the side of publishing sooner (perhaps with less polish), so as to get stable interoperability. So I had to reorient my thinking towards viewing the drafts mainly from an interoperability standpoint. From that standpoint, although you have revealed some inconsistencies below, they seem to be minor and easily fixable. The main substantial open issue seems to be the HIT format. Cross-area reviews will take some time especially if there are objections or discussions as to how we are doing things. I personally do not mind to wait to improve the drafts, because I think they are stable enough now that interoperable (experimental) implementations can be produced and easily tweaked, and I also think that we are just pushing the review problem onto the IESG reviewers (i.e., it would be nice to say to the IESG that there has been cross-area review), but I am eager to hear the priorities of the rest of the WG. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 17 02:45:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Hg9-00043g-KL; Wed, 17 Aug 2005 02:45:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Hg6-00043D-LS for hipsec@megatron.ietf.org; Wed, 17 Aug 2005 02:45:35 -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 CAA09677 for ; Wed, 17 Aug 2005 02:45:32 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5IFY-0004Mh-Gy for hipsec@ietf.org; Wed, 17 Aug 2005 03:22:15 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 64980212CA9; Wed, 17 Aug 2005 09:45:12 +0300 (EEST) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512B07@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D512B07@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E241DC5-CFA8-4102-9EC2-604B49652521@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Wed, 17 Aug 2005 08:45:10 +0200 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Tom, >> In general, I'm afraid that the document is *NOT* ready for the >> IESG. That is, as we are now proceeding to publication, I'd like >> us to apply a little bit of extra scrutiny ... > > Pekka, I happen to agree with you that the drafts could be improved. Maybe I used too strong language. I was just disappointed since we are now past the WG last call, and received very few comments... [I know, I didn't have time during the WG LC but I told this to the chairs, telling them that I'll do my review ASAP after Paris.] What I am concerned about is the *document* quality, not technical quality. As far as I can see, technical quality seems to be fine. Maybe we should state that from a technical point of view the draft is now frozen, unless we detect something alarming that warrants it to be changed? [Consensus call on this, chairs?] My worry is that we might get stuck at the IESG just because the introduction or some other part of the document is not sufficiently clear, making it hard for an outsider (such as the ADs) to understand what we want to say. Hence, I think that we still need a few outsiders to review the document in order to make it readable in one pass. I don't want us to get stuck because we don't have sufficient meta-discussion about what we want to say and why. > Cross-area reviews will take some time especially if there are > objections or discussions as to how we are doing things. We can minimise the potentiality for objections by stating that this is chartered for experimental. Discussion is more likely to indicate parts of the document that are not clear enough. Now, I was thinking mostly that we should get reviews from the OPS area and also from the SEC area. From SEC area mostly as a presentation matter; we have Tuomas Aura's paper to lean on about the security aspects. Hmm. Maybe we should point to it more strongly in the introduction, stating that the protocol has been analysed by crypto protocol experts and no serious problems were found? (And that we know that one analysis is no guarantee of security yada yada yada...) APS area may be another potential source of DISCUSSes. We may need some more introductory text saying that while we have considered API issues, they are outside of the scope of the protocol spec? This is a little bit murky still due to the problems with 6.1 and 6.2. So, ask for a review of -04 by e.g. Pekka Savola (OPS), Nico Williams (SEC), and Ned Freed (APS)? I can't see anything alarming from RTG or TSV point of view. > I am eager to hear the priorities of the rest of the WG. Me too. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 17 06:18:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5L0J-0004ir-G0; Wed, 17 Aug 2005 06:18:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5L0H-0004gV-UP for hipsec@megatron.ietf.org; Wed, 17 Aug 2005 06:18:38 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19290 for ; Wed, 17 Aug 2005 06:18:34 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42F86D8500345929; Wed, 17 Aug 2005 12:18:06 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Wed, 17 Aug 2005 12:19:35 +0200 User-Agent: KMail/1.8 References: <77F357662F8BFA4CA7074B0410171B6D512B07@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512B07@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: <200508171219.36404.julien.IETF@laposte.net> 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 16 August 2005 17:38, Henderson, Thomas R wrote: > > Pekka, I happen to agree with you that the drafts could be > improved. However, when I have suggested this in the past, the > feedback that I received was that the WG wanted to err on the side > of publishing sooner (perhaps with less polish), so as to get > stable interoperability. So I had to reorient my thinking towards > viewing the drafts mainly from an interoperability standpoint. > From that standpoint, although you have revealed some > inconsistencies below, they seem to be minor and easily fixable. > The main substantial open issue seems to be the HIT format. > > Cross-area reviews will take some time especially if there are > objections or discussions as to how we are doing things. I > personally do not mind to wait to improve the drafts, because I > think they are stable enough now that interoperable (experimental) > implementations can be produced and easily tweaked, and I also > think that we are just pushing the review problem onto the IESG > reviewers (i.e., it would be nice to say to the IESG that there has > been cross-area review), but I am eager to hear the priorities of > the rest of the WG. Hi Tom, some thoughts on that matter: As you noted above, if there are any technical inconsistencies they don't prevent people from producing inter-operable implementations. I don't believe that anybody in the WG will now want to change a major aspect in the protocol specification, so the current (-03) draft seems to be a quite stable reference for implementors. I agree that cross area review will take time, but I also think that for the sake of publishing the RFC faster, the cross-area path is most probably the fastest: We won't only tell the IESG that there was cross area review, we will also give them a document more readable by non-HIPpies. I, at least, have trouble finding unclear/confusing/etc statements in a document I've read so much. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 17 06:19:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5L0p-0004n9-6V; Wed, 17 Aug 2005 06:19:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5L0o-0004mj-0n for hipsec@megatron.ietf.org; Wed, 17 Aug 2005 06:19:10 -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 GAA19319 for ; Wed, 17 Aug 2005 06:19:07 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5LaE-0002AW-Ee for hipsec@ietf.org; Wed, 17 Aug 2005 06:55:52 -0400 Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42F86D8500345929; Wed, 17 Aug 2005 12:18:06 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Wed, 17 Aug 2005 12:19:35 +0200 User-Agent: KMail/1.8 References: <77F357662F8BFA4CA7074B0410171B6D512B07@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512B07@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: <200508171219.36404.julien.IETF@laposte.net> X-Spam-Score: 2.2 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 16 August 2005 17:38, Henderson, Thomas R wrote: > > Pekka, I happen to agree with you that the drafts could be > improved. However, when I have suggested this in the past, the > feedback that I received was that the WG wanted to err on the side > of publishing sooner (perhaps with less polish), so as to get > stable interoperability. So I had to reorient my thinking towards > viewing the drafts mainly from an interoperability standpoint. > From that standpoint, although you have revealed some > inconsistencies below, they seem to be minor and easily fixable. > The main substantial open issue seems to be the HIT format. > > Cross-area reviews will take some time especially if there are > objections or discussions as to how we are doing things. I > personally do not mind to wait to improve the drafts, because I > think they are stable enough now that interoperable (experimental) > implementations can be produced and easily tweaked, and I also > think that we are just pushing the review problem onto the IESG > reviewers (i.e., it would be nice to say to the IESG that there has > been cross-area review), but I am eager to hear the priorities of > the rest of the WG. Hi Tom, some thoughts on that matter: As you noted above, if there are any technical inconsistencies they don't prevent people from producing inter-operable implementations. I don't believe that anybody in the WG will now want to change a major aspect in the protocol specification, so the current (-03) draft seems to be a quite stable reference for implementors. I agree that cross area review will take time, but I also think that for the sake of publishing the RFC faster, the cross-area path is most probably the fastest: We won't only tell the IESG that there was cross area review, we will also give them a document more readable by non-HIPpies. I, at least, have trouble finding unclear/confusing/etc statements in a document I've read so much. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 18 09:04:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5k4F-0003yS-6p; Thu, 18 Aug 2005 09:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5k4C-0003xu-Be for hipsec@megatron.ietf.org; Thu, 18 Aug 2005 09:04:20 -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 JAA02836 for ; Thu, 18 Aug 2005 09:04:18 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5kdv-0008Ew-N7 for hipsec@ietf.org; Thu, 18 Aug 2005 09:41:17 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CEC39212C91; Thu, 18 Aug 2005 16:04:09 +0300 (EEST) Subject: Re: [Hipsec] Base draft & ESP draft: snapshots From: Petri Jokela To: Pekka Nikander In-Reply-To: References: <1124111403.10041.10.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 18 Aug 2005 16:04:08 +0300 Message-Id: <1124370248.8997.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Tue, 2005-08-16 at 17:05 +0200, Pekka Nikander wrote > There appears to be a minor problem between 6.13 and 6.14. 6.13 says > that CLOSE may be answered with an ICMP, 6.14 that they are dropped. Actually, there is a whole section "5.4.4 Non-existing HIP Association" that discusses about responding to CLOSE and NOTIFY messages with an ICMP if we do not have any state with that peer. In Paris, I think we agreed that we are not going to respond to an incoming CLOSE with any message. Should we ignore also incoming NOTIFYs if there is no association? Is there any reason why we would like to answer to NOTIFYs in UNASSOCIATED state? > Need to specify "LSI" briefly in Section 2 as it is used in 6.1 Should we remove all text related to LSIs, and concentrate only on HITs in this draft? All LSI related stuff would be in draft-henderson-hip-applications. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 18 09:12:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kBg-000549-31; Thu, 18 Aug 2005 09:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kBZ-00053r-V3 for hipsec@megatron.ietf.org; Thu, 18 Aug 2005 09:11: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 JAA03123 for ; Thu, 18 Aug 2005 09:11:56 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5klK-0008QW-Ky for hipsec@ietf.org; Thu, 18 Aug 2005 09:48:55 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id AC1AF212C91; Thu, 18 Aug 2005 16:11:48 +0300 (EEST) In-Reply-To: <1124370248.8997.15.camel@localhost.localdomain> References: <1124111403.10041.10.camel@localhost.localdomain> <1124370248.8997.15.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <942EE334-6314-4626-83F0-B277EF0DE97A@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Thu, 18 Aug 2005 15:11:45 +0200 To: Petri Jokela X-Mailer: Apple Mail (2.734) 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 >> There appears to be a minor problem between 6.13 and 6.14. 6.13 says >> that CLOSE may be answered with an ICMP, 6.14 that they are dropped. >> > > Actually, there is a whole section "5.4.4 Non-existing HIP > Association" > that discusses about responding to CLOSE and NOTIFY messages with an > ICMP if we do not have any state with that peer. In Paris, I think we > agreed that we are not going to respond to an incoming CLOSE with any > message. Should we ignore also incoming NOTIFYs if there is no > association? Is there any reason why we would like to answer to > NOTIFYs > in UNASSOCIATED state? Good question. I don't have any strong opinion; I'm just worried about us not being consistent. >> Need to specify "LSI" briefly in Section 2 as it is used in 6.1 >> > > Should we remove all text related to LSIs, and concentrate only on > HITs > in this draft? All LSI related stuff would be in > draft-henderson-hip-applications. Either way works for me. I'd slightly prefer rewriting 6.1. and 6.2 so that they don't refer to LSIs as all, because IMHO those two sections should be completely rewritten anyway. They are currently crumby, as a remaining issue resulting from the document split. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 18 09:59:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kvM-0000pl-IN; Thu, 18 Aug 2005 09:59:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kvL-0000pG-6r for hipsec@megatron.ietf.org; Thu, 18 Aug 2005 09:59:15 -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 JAA05946 for ; Thu, 18 Aug 2005 09:59:13 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5lV2-0001Z7-9k for hipsec@ietf.org; Thu, 18 Aug 2005 10:36:12 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA17618; Thu, 18 Aug 2005 08:58:53 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j7IDwrs28566; Thu, 18 Aug 2005 06:58:53 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 06:58:53 -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] Base draft & ESP draft: snapshots Date: Thu, 18 Aug 2005 06:58:52 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D512B21@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base draft & ESP draft: snapshots Thread-Index: AcWj9pPkfiQJJhWYSUaNoAJ6NHkjDAABCqnw From: "Henderson, Thomas R" To: "Pekka Nikander" , "Petri Jokela" X-OriginalArrivalTime: 18 Aug 2005 13:58:53.0095 (UTC) FILETIME=[F7980B70:01C5A3FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, August 18, 2005 6:12 AM > To: Petri Jokela > Cc: hipsec@ietf.org > Subject: Re: [Hipsec] Base draft & ESP draft: snapshots >=20 > >> There appears to be a minor problem between 6.13 and 6.14.=20 > 6.13 says=20 > >> that CLOSE may be answered with an ICMP, 6.14 that they=20 > are dropped. > >> > > > > Actually, there is a whole section "5.4.4 Non-existing HIP=20 > > Association" > > that discusses about responding to CLOSE and NOTIFY=20 > messages with an=20 > > ICMP if we do not have any state with that peer. In Paris,=20 > I think we=20 > > agreed that we are not going to respond to an incoming=20 > CLOSE with any=20 > > message. Should we ignore also incoming NOTIFYs if there is no=20 > > association? Is there any reason why we would like to answer to=20 > > NOTIFYs in UNASSOCIATED state? >=20 > Good question. I don't have any strong opinion; I'm just=20 > worried about us not being consistent. >=20 I would suggest not responding to NOTIFY (i.e., no change to current text). As for 6.14, I think it should be aligned to 5.4.4 which is the newer text on this matter. > >> Need to specify "LSI" briefly in Section 2 as it is used in 6.1 > >> > > > > Should we remove all text related to LSIs, and concentrate only on=20 > > HITs in this draft? All LSI related stuff would be in=20 > > draft-henderson-hip-applications. >=20 > Either way works for me. I'd slightly prefer rewriting 6.1. and > 6.2 so that they don't refer to LSIs as all, because IMHO those > two sections should be completely rewritten anyway. They are > currently crumby, as a remaining issue resulting from the=20 > document split. I think we need some section in this document that at least hints at how one might map from applications (and application-level names for hosts) to host identities, even if it mostly points to a separate document. Note that the document it is pointing to is not in the current WG charter to develop, but has instead been sent to the RG based on Minneapolis meeting discussions. I actually don't have a problem with how 6.1 and 6.2 are currently written, except that they don't really allow for some of the opportunistic HIP scenarios (e.g., HIT in TCP option) that have been recently discussed (in which case, the address used by the application may really be an IP address and not an LSI or HIT). This part of HIP implementation will likely be quite different from implementation to implementation, so it seems best to keep it as a loose sketch of how processing might be done. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 18 10:06:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5l2E-0002st-TZ; Thu, 18 Aug 2005 10:06:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5l2D-0002sn-Fq for hipsec@megatron.ietf.org; Thu, 18 Aug 2005 10:06: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 KAA06530 for ; Thu, 18 Aug 2005 10:06:19 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5lbx-0001mo-B0 for hipsec@ietf.org; Thu, 18 Aug 2005 10:43:18 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B36F8212C91; Thu, 18 Aug 2005 17:06:10 +0300 (EEST) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512B21@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D512B21@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FCA8BC4-8F39-4877-866E-3046780F36A0@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Thu, 18 Aug 2005 16:06:07 +0200 To: "Henderson, Thomas R" 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 would suggest not responding to NOTIFY (i.e., no change to > current text). > > As for 6.14, I think it should be aligned to 5.4.4 which is the > newer text on this matter. WFM. > I actually don't have a problem with how 6.1 and 6.2 are currently > written, except that they don't really allow for some of the > opportunistic HIP scenarios ... This part of HIP implementation > will likely be quite different from implementation to > implementation, so it seems best to keep it as a loose sketch of > how processing might be done. Agreed that implementations will differ. My only problem with the sections is that they don't read well if you are reading the document for the first time, and linearly. The text just doesn't make sense, easily; I'm just calling for a simple rewrite to make them more readable. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 19 09:01:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E66VP-00072H-R0; Fri, 19 Aug 2005 09:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E66VM-000723-P2 for hipsec@megatron.ietf.org; Fri, 19 Aug 2005 09:01:53 -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 JAA01467 for ; Fri, 19 Aug 2005 09:01:50 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E675I-0008WN-GV for hipsec@ietf.org; Fri, 19 Aug 2005 09:39:02 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0491C212C91; Fri, 19 Aug 2005 16:01:32 +0300 (EEST) In-Reply-To: <1124111403.10041.10.camel@localhost.localdomain> References: <1124111403.10041.10.camel@localhost.localdomain> 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, 19 Aug 2005 15:01:30 +0200 To: Petri Jokela X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 > draft-ietf-hip-esp-01-pre150805 In general, this one seems to be more consistent and ready than the base exchange spec, probably due to being freshly written. :-) Note that I did NOT read all of the document; more the introduction and end to make sure that they make sense to the non-initiated reader. 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. At the same time I would remove all references to the BEET mode from the security considerations. Minor nits: > the network, because the SPI value in the ESP packet is used as the > hint for the correct HIT pair used for the connection. ..., because the SPI value, together with the integrity protection, allow the packet to be securely associated with the right HIP pair. > This mode of operation avoids overhead typically associated with > ESP tunnel mode. This mode of operation avoids the extra inner header overhead associated with ESP tunnel mode. > In ESP, the packet processing and SA lookup are based on IP addresses. This is not strictly true any more in ESPbis. I'd suggest removing the sentence, and fixing the language afterwards to fit. > done, e.g. using IKE [[11]]. This document specifies how Host > Identity Protocol is used to Remove extra [] > ESP_TRANSFORM is 2048. This doesn't really matter, but I would find it slightly more appealing if it was 4095... --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Aug 22 18:50:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7L7L-0005Kl-S8; Mon, 22 Aug 2005 18:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7L7D-0005HM-IN; Mon, 22 Aug 2005 18:50: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 SAA28574; Mon, 22 Aug 2005 18:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7L7C-0004eX-MA; Mon, 22 Aug 2005 18:50:03 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E7L7B-0000Bg-RB; Mon, 22 Aug 2005 18: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: Mon, 22 Aug 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION: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 --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 Architecture Author(s) : R. Moskowitz, P. Nikander Filename : draft-ietf-hip-arch-03.txt Pages : 24 Date : 2005-8-22 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 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-arch-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-arch-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-22160020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-arch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-22160020.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 Tue Aug 23 12:59:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7c7V-0003U9-H1; Tue, 23 Aug 2005 12:59:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7c7T-0003Tk-Hf for hipsec@megatron.ietf.org; Tue, 23 Aug 2005 12:59:27 -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 MAA15412 for ; Tue, 23 Aug 2005 12:59:24 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7c7Z-0002WB-Ih for hipsec@ietf.org; Tue, 23 Aug 2005 12:59:37 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA14476 for ; Tue, 23 Aug 2005 09:59:08 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j7NGx8s13884 for ; Tue, 23 Aug 2005 09:59:08 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 09:58:58 -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 Date: Tue, 23 Aug 2005 09:58:58 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D512B5D@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: I-D ACTION:draft-ietf-hip-arch-03.txt Thread-Index: AcWnbKYERVllSebsSz2JEsLAzUBfCwAlzQ+A From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 23 Aug 2005 16:58:58.0694 (UTC) FILETIME=[F44C5A60:01C5A803] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hipsec] FW: I-D ACTION: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 FYI (this revision is in response to IESG comments)=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, August 22, 2005 3:50 PM To: i-d-announce@ietf.org Cc: hipsec@ietf.org Subject: I-D ACTION:draft-ietf-hip-arch-03.txt=20 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 Architecture Author(s) : R. Moskowitz, P. Nikander Filename : draft-ietf-hip-arch-03.txt Pages : 24 Date : 2005-8-22 =09 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 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 24 15:53:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81JJ-0007YG-Ak; Wed, 24 Aug 2005 15:53:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81JH-0007Y8-8K for hipsec@megatron.ietf.org; Wed, 24 Aug 2005 15:53:19 -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 PAA15675 for ; Wed, 24 Aug 2005 15:53:17 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81Jb-0005GP-JZ for hipsec@ietf.org; Wed, 24 Aug 2005 15:53:43 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA29254; Wed, 24 Aug 2005 12:52:33 -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 j7OJqkv25295; Wed, 24 Aug 2005 14:52:46 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Aug 2005 12:52:43 -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 Date: Wed, 24 Aug 2005 12:52:43 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D802A@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: Boeing test server and implementation Thread-Index: AcWo5WQiJJ4EdzGwTxKQcM6+r/kBZQ== From: "Ahrenholz, Jeffrey M" To: , X-OriginalArrivalTime: 24 Aug 2005 19:52:43.0626 (UTC) FILETIME=[64747CA0:01C5A8E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hipsec] Boeing test server and 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 All, We've released a new version of our HIP software for Linux/Windows XP: http://hipserver.mct.phantomworks.org/ Supporting base-03, esp-00, and mm-02 drafts, and interops from the last IETF meeting. New in this version is user-mode HIP (UMH) that runs entirely in Linux userspace so you don't need to patch your Linux kernel. Also, our HIP test server is back and should now remain online permanently. -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 25 03:14:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8BwT-0007z2-BH; Thu, 25 Aug 2005 03:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8BwQ-0007xF-3K for hipsec@megatron.ietf.org; Thu, 25 Aug 2005 03:14:27 -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 DAA03975 for ; Thu, 25 Aug 2005 03:14:24 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Bws-0000p6-LA for hipsec@ietf.org; Thu, 25 Aug 2005 03:14:56 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CFC7ABF7; Thu, 25 Aug 2005 09:14:07 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 09:14:06 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 09:14:06 +0200 Received: from [131.160.36.106] (EGIUM000L5C5TEU.lmf.ericsson.se [131.160.36.106]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6E2092647; Thu, 25 Aug 2005 10:14:06 +0300 (EEST) Message-ID: <430D6FBD.8000804@ericsson.com> Date: Thu, 25 Aug 2005 10:14:05 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2005 07:14:06.0644 (UTC) FILETIME=[94A1F740:01C5A944] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: David Ward Subject: [Hipsec] Draft minutes of Paris meeting X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, here you have an initial version of the minutes of the Paris meeting: http://users.piuha.net/gonzalo/hip/meetings/ietf63/notes/minutes-hip-ietf63.txt Let us know if you have any comments. We intend to submit them shortly. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 25 04:04:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Cik-0006dC-Vn; Thu, 25 Aug 2005 04:04:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Cih-0006Zy-Vq for hipsec@megatron.ietf.org; Thu, 25 Aug 2005 04:04:20 -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 EAA05767 for ; Thu, 25 Aug 2005 04:04:18 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8CjA-0002ON-Tw for hipsec@ietf.org; Thu, 25 Aug 2005 04:04:50 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0839D1527D; Thu, 25 Aug 2005 10:04:09 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Aug 2005 10:04:08 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id B6B9820B6E7; Thu, 25 Aug 2005 10:04:07 +0200 (CEST) In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D802A@XCH-NW-6V1.nw.nos.boeing.com> References: <0DF156EE7414494187B087A3C279BDB40D802A@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v734) Message-Id: <91DFCC27-CFD0-4F8C-980E-90BC6AF07DEB@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] Boeing test server and implementation Date: Thu, 25 Aug 2005 10:04:04 +0200 To: "Ahrenholz, Jeffrey M" X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 25 Aug 2005 08:04:08.0952 (UTC) FILETIME=[9225CF80:01C5A94B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: hipsec-rg@honor.trusecure.com, hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1620306640==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============1620306640== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-32-620956709; protocol="application/pkcs7-signature" --Apple-Mail-32-620956709 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, On Aug 24, 2005, at 21:52, Ahrenholz, Jeffrey M wrote: > We've released a new version of our HIP software for Linux/Windows XP: > http://hipserver.mct.phantomworks.org/ great news, thanks! But this leaves me a bit confused - I thought the Boeing HIP was available as OpenHIP? Guess I'm wrong; what is the relation between OpenHIP and Boeing HIP then? Thanks, Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-32-620956709 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUwODI1MDgwNDA0WjAjBgkqhkiG9w0BCQQxFgQUdOp8hHYvjYopcxDqHiqm voLb3pswgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAG/lIt9IwiEe06wXtkgNkfi6i+1L84KnpKZ82fOC9ZiK6Sd661tNRRNkzGQ43Td7v79AOB+i eCB11jzh1CfDhoyAsT2v88s+AXPpzdX0DGg/acuyOvooCx66laaqTWV/OTye9C6GtD7TL5yPkz/6 eXdlmHD1PbURDuJE+1Qp3l++qJrQUY5LGmL48xLB+zGKwh2Vi9Dd3K4jTVoXQR2l3aK6sPPUthhv u2JmL9in4/Sfcq/Y6lWL4+opZIdM2KoM8ktNrfRaHqMxNym14TL4Dcsts9CFYHrWUIzyCeqUEZyf PyVZq+FRC2I+b8yGU6wStX+yzBj74ia1/8QaVMB5nPcAAAAAAAA= --Apple-Mail-32-620956709-- --===============1620306640== 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 --===============1620306640==-- From hipsec-bounces@lists.ietf.org Thu Aug 25 10:57:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JAi-0003G0-H9; Thu, 25 Aug 2005 10:57:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JAg-0003Fm-Fw for hipsec@megatron.ietf.org; Thu, 25 Aug 2005 10:57:38 -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 KAA21835 for ; Thu, 25 Aug 2005 10:57:36 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8JBA-0005dz-Sk for hipsec@ietf.org; Thu, 25 Aug 2005 10:58:12 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA16163; Thu, 25 Aug 2005 07:56:52 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j7PEv7v06140; Thu, 25 Aug 2005 09:57:07 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 07:57:00 -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-rg] Re: [Hipsec] Boeing test server and implementation Date: Thu, 25 Aug 2005 07:57:02 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D512B77@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec-rg] Re: [Hipsec] Boeing test server and implementation Thread-Index: AcWpS75J2oTMzX/oR/iLwKdhvY24AwAOOhUg From: "Henderson, Thomas R" To: "Lars Eggert" , "Ahrenholz, Jeffrey M" X-OriginalArrivalTime: 25 Aug 2005 14:57:00.0262 (UTC) FILETIME=[3EFFC060:01C5A985] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: hipsec-rg@honor.trusecure.com, 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 =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 > Sent: Thursday, August 25, 2005 1:04 AM > To: Ahrenholz, Jeffrey M > Cc: hipsec@ietf.org; hipsec-rg@honor.trusecure.com > Subject: [Hipsec-rg] Re: [Hipsec] Boeing test server and=20 > implementation >=20 > Hi, >=20 > On Aug 24, 2005, at 21:52, Ahrenholz, Jeffrey M wrote: > > We've released a new version of our HIP software for=20 > Linux/Windows XP: > > http://hipserver.mct.phantomworks.org/ >=20 > great news, thanks! >=20 > But this leaves me a bit confused - I thought the Boeing HIP=20 > was available as OpenHIP? Guess I'm wrong; what is the=20 > relation between OpenHIP and Boeing HIP then? >=20 Sorry for the confusion; we plan to patch the OpenHIP code shortly, and host future development there. This is just an early release. I will announce to the list when that occurs. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 26 08:51:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dff-00041T-VZ; Fri, 26 Aug 2005 08:50:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dfe-00041O-4j for hipsec@megatron.ietf.org; Fri, 26 Aug 2005 08:50: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 IAA16271 for ; Fri, 26 Aug 2005 08:50:56 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8dgM-0005DD-7o for hipsec@ietf.org; Fri, 26 Aug 2005 08:51:43 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 376DF212C91; Fri, 26 Aug 2005 15:50:32 +0300 (EEST) Message-ID: <430F1007.7000800@nomadiclab.com> Date: Fri, 26 Aug 2005 15:50:15 +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=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Thanks Pekka, most of the comments are included in the current pre-version. I uploaded it to http://hip4inter.net/drafts.php The draft is named as draft-ietf-hip-base-04-pre250805 (The date in the actual draft is 26th. For some reason I was not well calibrated today.) More comments inline. Pekka Nikander wrote: > Another substantial issues is the HIT format (Sections 3.1 and 3.2; > plus Appendix B). Personally, I expect it to change slightly as a > result of the forthcoming discussion in the IPv6 WG. BTW, the draft > that Julien and I promised in Paris has been written but currently > waits for additional comments from Francis; once we get them, it will > be out. If we define the draft dependent to the HIT format specified in your document, we would have to wait with base spec until that IPv6 prefix draft is ready. Otherwise, we cannot make a normative reference to it in the base spec. Currently the base defines the prefix as it was in -03. Maybe there should be some addition that "This may change in the future, when ...." > Somewhat relatedly, now that we are proposing that the HIT prefix would > be defaulted back to IANA in 2009, unless the IETF decided otherwise, > perhaps we should do the same for the HIP protocol number (Section > 4?). If so, an appropriate IANA note should be added to the IANA > Considerations section. Do we want to do like this? I haven't yet put it into the draft. > (N.B. I didn't check the table and figure in 4.4.2 and 4.4.3; I > suggest someone would do that, with scrutiny. Has anyone on the list done this lately? > I find myself wondering if sections 5.1.3 and 5.1.4 should be moved to > Section 6, e.g., between current 6.2 and 6.3? I move puzzle solving (5.1.4) as it seems to fit to the packet processing, but left 5.1.3 (fragmentation support) where it was. Fragmentation is still "old procedure" while puzzle solving is something directly HIP related processing. But I don't know if this is correct thinking. Checksum section (5.1.2) could also be somewhere in 6 if 5.1.3 goes there. > > Sections 6.1. and 6.2. appear hard to read to the uninitiated, most > probably due to their long and convoluted history. Partial rewrite > would probably help. Tom wrote earlier, related to this: "I actually don't have a problem with how 6.1 and 6.2 are currently written, except that they don't really allow for some of the opportunistic HIP scenarios (e.g., HIT in TCP option) that have been recently discussed (in which case, the address used by the application may really be an IP address and not an LSI or HIT). This part of HIP implementation will likely be quite different from implementation to implementation, so it seems best to keep it as a loose sketch of how processing might be done." I edited 6.1 and 6.2 slightly. I tried to generalize the text a bit, not discussing only about HITs towards applications. Please, have a look and see if it is ok or not. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 26 10:59:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fgJ-0007dT-I1; Fri, 26 Aug 2005 10:59:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fgI-0007dO-AK for hipsec@megatron.ietf.org; Fri, 26 Aug 2005 10:59:46 -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 KAA25111 for ; Fri, 26 Aug 2005 10:59:44 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fgy-00012t-ND for hipsec@ietf.org; Fri, 26 Aug 2005 11:00:33 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA01104; Fri, 26 Aug 2005 09:59:23 -0500 (CDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j7QExNs27189; Fri, 26 Aug 2005 07:59:23 -0700 (PDT) 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.0); Fri, 26 Aug 2005 07:59:21 -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] Base draft & ESP draft: snapshots Date: Fri, 26 Aug 2005 07:59:21 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D512B96@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base draft & ESP draft: snapshots Thread-Index: AcWqPUKvNLxLv/J8SAum+YrSfG5IsAAEPE6w From: "Henderson, Thomas R" To: "Petri Jokela" , "Pekka Nikander" X-OriginalArrivalTime: 26 Aug 2005 14:59:21.0915 (UTC) FILETIME=[BDD808B0:01C5AA4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 =20 > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Friday, August 26, 2005 5:50 AM > To: Pekka Nikander > Cc: hipsec@ietf.org > Subject: Re: [Hipsec] Base draft & ESP draft: snapshots > > Somewhat relatedly, now that we are proposing that the HIT prefix =20 > > would be defaulted back to IANA in 2009, unless the IETF decided =20 > > otherwise, perhaps we should do the same for the HIP=20 > protocol number =20 > > (Section 4?). If so, an appropriate IANA note should be=20 > added to the =20 > > IANA Considerations section. >=20 > Do we want to do like this? I haven't yet put it into the draft. >=20 My suggestion would be to ask the Area Directors for some guidance here (if that hasn't happened already-- I do not know). In particular, one of the former ADs has written this draft: http://ietfreport.isoc.org/all-ids/draft-narten-iana-experimental-alloca tions-05.txt If you want, I will volunteer to inquire with Thomas, Margaret, and Mark on this issue. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Aug 27 08:37:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8zwF-0003Ta-LG; Sat, 27 Aug 2005 08:37:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8zwD-0003TV-PS for hipsec@megatron.ietf.org; Sat, 27 Aug 2005 08:37:34 -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 IAA11482 for ; Sat, 27 Aug 2005 08:37:32 -0400 (EDT) Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8zx8-0007b3-L3 for hipsec@ietf.org; Sat, 27 Aug 2005 08:38:31 -0400 Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 7AF6937FE9; Sat, 27 Aug 2005 14:37:09 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 6D85537FCE; Sat, 27 Aug 2005 14:37:09 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 61F6637E42; Sat, 27 Aug 2005 14:37:09 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1E8zvo-0000Ul-9J; Sat, 27 Aug 2005 14:37:08 +0200 Message-ID: <43105E74.4090606@levkowetz.com> Date: Sat, 27 Aug 2005 14:37:08 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] Base draft & ESP draft: snapshots References: <77F357662F8BFA4CA7074B0410171B6D512B96@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512B96@XCH-NW-5V1.nw.nos.boeing.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) 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 on 2005-08-26 16:59 Henderson, Thomas R said the following: >> From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] [...] >> Do we want to do like this? I haven't yet put it into the draft. >> > > My suggestion would be to ask the Area Directors for some guidance here > (if that hasn't happened already-- I do not know). In particular, one > of the former ADs has written this draft: > http://ietfreport.isoc.org/all-ids/draft-narten-iana-experimental-alloca > tions-05.txt Which is now RFC 3692, and might have some relevance. Henrik _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 30 04:55:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA1uC-0005aL-4C; Tue, 30 Aug 2005 04:55:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA1u9-0005aG-VV for hipsec@megatron.ietf.org; Tue, 30 Aug 2005 04:55: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 EAA29687 for ; Tue, 30 Aug 2005 04:55:39 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA1ve-00020r-S5 for hipsec@ietf.org; Tue, 30 Aug 2005 04:57:16 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 26C64212C91; Tue, 30 Aug 2005 11:55:18 +0300 (EEST) Message-ID: <43141EF4.7060507@nomadiclab.com> Date: Tue, 30 Aug 2005 11:55:16 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Hipsec] Base draft & ESP draft: snapshots References: <77F357662F8BFA4CA7074B0410171B6D512B96@XCH-NW-5V1.nw.nos.boeing.com> <43105E74.4090606@levkowetz.com> In-Reply-To: <43105E74.4090606@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Henrik Levkowetz wrote: > on 2005-08-26 16:59 Henderson, Thomas R said the following: > > >>>From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] > > [...] > >>>Do we want to do like this? I haven't yet put it into the draft. >>> >> >>My suggestion would be to ask the Area Directors for some guidance here >>(if that hasn't happened already-- I do not know). In particular, one >>of the former ADs has written this draft: >>http://ietfreport.isoc.org/all-ids/draft-narten-iana-experimental-alloca >>tions-05.txt > > > Which is now RFC 3692, and might have some relevance. Thanks for these pointers! If I understood correctly RFC3692, we can use the IP protocol number 253 or 254 for testing purposes (instead of the current 99) by defining it in the IANA considerations section. There is no requirement for IANA actions at this point. It seems that other kinds of solutions are not considered to be a good idea, e.g. temporary protocol number assignment by IANA. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 30 05:01:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA20E-0006Tu-Ec; Tue, 30 Aug 2005 05:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA20C-0006Tn-H7 for hipsec@megatron.ietf.org; Tue, 30 Aug 2005 05:01:56 -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 FAA00034 for ; Tue, 30 Aug 2005 05:01:54 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA21i-0002CZ-FC for hipsec@ietf.org; Tue, 30 Aug 2005 05:03:30 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 23165212C91; Tue, 30 Aug 2005 12:01:47 +0300 (EEST) In-Reply-To: <43141EF4.7060507@nomadiclab.com> References: <77F357662F8BFA4CA7074B0410171B6D512B96@XCH-NW-5V1.nw.nos.boeing.com> <43105E74.4090606@levkowetz.com> <43141EF4.7060507@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61F110EB-08B6-4EBB-8C36-73BC179E3F05@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Tue, 30 Aug 2005 11:01:46 +0200 To: Petri Jokela X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 > It seems that other kinds of solutions are not considered to be a good > idea, e.g. temporary protocol number assignment by IANA. AFAIK there is a difference between a temporary assignment with a default date when the assignment reverts vs. temporary assignment without such a date. But I may be wrong. Other than that, I pretty much agree with you. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 30 10:00:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6fL-0005sL-M2; Tue, 30 Aug 2005 10:00:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6fJ-0005sD-9A for hipsec@megatron.ietf.org; Tue, 30 Aug 2005 10:00:41 -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 KAA13735 for ; Tue, 30 Aug 2005 10:00:39 -0400 (EDT) Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA6gq-000242-LP for hipsec@ietf.org; Tue, 30 Aug 2005 10:02:18 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 0EED837E5B; Tue, 30 Aug 2005 15:57:22 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 9F2D337E43; Tue, 30 Aug 2005 15:57:21 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 0C36937E44; Tue, 30 Aug 2005 16:00:24 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EA6f2-0003Kq-FI; Tue, 30 Aug 2005 16:00:24 +0200 Message-ID: <43146677.4080900@levkowetz.com> Date: Tue, 30 Aug 2005 16:00:23 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petri Jokela Subject: Re: [Hipsec] Base draft & ESP draft: snapshots References: <77F357662F8BFA4CA7074B0410171B6D512B96@XCH-NW-5V1.nw.nos.boeing.com> <43105E74.4090606@levkowetz.com> <43141EF4.7060507@nomadiclab.com> In-Reply-To: <43141EF4.7060507@nomadiclab.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 2005-08-30 10:55 Petri Jokela said the following: > Henrik Levkowetz wrote: >> on 2005-08-26 16:59 Henderson, Thomas R said the following: >> >> >>>>From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] >> >> [...] >> >>>>Do we want to do like this? I haven't yet put it into the draft. >>>> >>> >>>My suggestion would be to ask the Area Directors for some guidance here >>>(if that hasn't happened already-- I do not know). In particular, one >>>of the former ADs has written this draft: >>>http://ietfreport.isoc.org/all-ids/draft-narten-iana-experimental-alloca >>>tions-05.txt >> >> >> Which is now RFC 3692, and might have some relevance. > > Thanks for these pointers! If I understood correctly RFC3692, we can use > the IP protocol number 253 or 254 for testing purposes (instead of the > current 99) by defining it in the IANA considerations section. There is > no requirement for IANA actions at this point. > > It seems that other kinds of solutions are not considered to be a good > idea, e.g. temporary protocol number assignment by IANA. This matches my understanding. Note that this restricts you to not run this at the same time as you run another experiment using the same experimental IP protocol number. But this mostly makes sense anyhow, as it is much more difficult to draw clear conclusions from 2 simultaneous experiments... Of course, as soon as there is deployment which is not experimental, you'll need to get a protocol number so that you don't become a squatter on the experimental protocol number. Henrik _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 31 05:25:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAOqT-0007Sf-RK; Wed, 31 Aug 2005 05:25:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAOqR-0007SK-UH for hipsec@megatron.ietf.org; Wed, 31 Aug 2005 05:25:24 -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 FAA09820 for ; Wed, 31 Aug 2005 05:25:21 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAOs9-0007jv-Gu for hipsec@ietf.org; Wed, 31 Aug 2005 05:27:11 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CD641A9B; Wed, 31 Aug 2005 11:25:09 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:25:06 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:25:06 +0200 Received: from [131.160.126.47] (rvi2-126-47.lmf.ericsson.se [131.160.126.47]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6936F2656; Wed, 31 Aug 2005 12:25:06 +0300 (EEST) Message-ID: <43157770.3000400@ericsson.com> Date: Wed, 31 Aug 2005 12:25:04 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] Base draft & ESP draft: snapshots References: <77F357662F8BFA4CA7074B0410171B6D512B96@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512B96@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2005 09:25:06.0762 (UTC) FILETIME=[E01B4AA0:01C5AE0D] X-Brightmail-Tracker: AAAAAA== 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 Thomas, > My suggestion would be to ask the Area Directors for some guidance here > (if that hasn't happened already-- I do not know). In particular, one > of the former ADs has written this draft: > http://ietfreport.isoc.org/all-ids/draft-narten-iana-experimental-alloca > tions-05.txt > > If you want, I will volunteer to inquire with Thomas, Margaret, and Mark > on this issue. Petri agreed to contact Thomas Narten on this one and report back to the list with the conclusion. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 31 05:34:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAOzL-0001fS-3g; Wed, 31 Aug 2005 05:34:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAOzJ-0001bm-JX for hipsec@megatron.ietf.org; Wed, 31 Aug 2005 05:34: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 FAA10234 for ; Wed, 31 Aug 2005 05:34:30 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAP11-00080m-0w for hipsec@ietf.org; Wed, 31 Aug 2005 05:36:20 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D6457CDE; Wed, 31 Aug 2005 11:34:17 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:34:17 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:34:16 +0200 Received: from [131.160.126.47] (rvi2-126-47.lmf.ericsson.se [131.160.126.47]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8058B265D; Wed, 31 Aug 2005 12:34:16 +0300 (EEST) Message-ID: <43157997.2020406@ericsson.com> Date: Wed, 31 Aug 2005 12:34:15 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] Base draft & ESP draft: snapshots References: <77F357662F8BFA4CA7074B0410171B6D512B07@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512B07@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2005 09:34:16.0927 (UTC) FILETIME=[2807CEF0:01C5AE0F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, David Ward X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, Thomas wrote: > Pekka, I happen to agree with you that the drafts could be improved. > However, when I have suggested this in the past, the feedback that I > received was that the WG wanted to err on the side of publishing sooner > (perhaps with less polish), so as to get stable interoperability. So I > had to reorient my thinking towards viewing the drafts mainly from an > interoperability standpoint. yes, your understanding of our charter is correct. Pekka wrote: > What I am concerned about is the *document* quality, not technical > quality. As far as I can see, technical quality seems to be fine. > > Maybe we should state that from a technical point of view the draft is > now frozen, unless we detect something alarming that warrants it to be > changed? [Consensus call on this, chairs?] > yes, as Thomas pointed out, that is the idea. Let's proceed as follows: Petri incorporates your comments and releases a new revision of the drafts within a week. I will then request the people you suggested to perform a review of the document within one month. After that, Petri incorporates the comments, we run the new revision briefly thru the WG, and send it to the IESG. Pekka, what is the status of the HIT draft you are working on with Julien? Thanks, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 31 05:36:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAP0l-00020J-0y; Wed, 31 Aug 2005 05:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAP0j-0001zz-1C for hipsec@megatron.ietf.org; Wed, 31 Aug 2005 05:36: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 FAA10317 for ; Wed, 31 Aug 2005 05:35:58 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAP2Q-00083w-K3 for hipsec@ietf.org; Wed, 31 Aug 2005 05:37:48 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CCEC14F0001; Wed, 31 Aug 2005 11:35:20 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:35:20 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:35:19 +0200 Received: from [131.160.126.47] (rvi2-126-47.lmf.ericsson.se [131.160.126.47]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 628942656; Wed, 31 Aug 2005 12:35:19 +0300 (EEST) Message-ID: <431579D6.8060507@ericsson.com> Date: Wed, 31 Aug 2005 12:35:18 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] FW: I-D ACTION:draft-ietf-hip-arch-03.txt References: <77F357662F8BFA4CA7074B0410171B6D512B5D@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512B5D@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2005 09:35:19.0721 (UTC) FILETIME=[4D756990:01C5AE0F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Folks, FYI: all the discusses on this draft have now been cleared. Cheers, Gonzalo Henderson, Thomas R wrote: > FYI (this revision is in response to IESG comments) > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, August 22, 2005 3:50 PM > To: i-d-announce@ietf.org > Cc: hipsec@ietf.org > Subject: I-D ACTION:draft-ietf-hip-arch-03.txt > > 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 Architecture > Author(s) : R. Moskowitz, P. Nikander > Filename : draft-ietf-hip-arch-03.txt > Pages : 24 > Date : 2005-8-22 > > 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 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 31 06:15:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAPcP-0004Jy-B4; Wed, 31 Aug 2005 06:14:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAPcO-0004Jp-9y for hipsec@megatron.ietf.org; Wed, 31 Aug 2005 06:14:56 -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 GAA11636 for ; Wed, 31 Aug 2005 06:14:53 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAPe6-0000Z3-Hr for hipsec@ietf.org; Wed, 31 Aug 2005 06:16:43 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id F2157212C91; Wed, 31 Aug 2005 13:14:30 +0300 (EEST) In-Reply-To: <43157997.2020406@ericsson.com> References: <77F357662F8BFA4CA7074B0410171B6D512B07@XCH-NW-5V1.nw.nos.boeing.com> <43157997.2020406@ericsson.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71458613-4198-4C78-959C-4902515AF577@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Wed, 31 Aug 2005 12:14:29 +0200 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, David Ward X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Pekka, what is the status of the HIT draft you are working on with > Julien? The draft exists and is basically ready (has been for two weeks), but we are trying to get Francis Dupont as a third author, and have some internal controversies in some details. Once we manage to decide how to deal with them, we'll submit it. Hopefully this week. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 31 06:30:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAPrM-0000RY-UJ; Wed, 31 Aug 2005 06:30:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAPrK-0000RQ-G3 for hipsec@megatron.ietf.org; Wed, 31 Aug 2005 06:30: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 GAA12182 for ; Wed, 31 Aug 2005 06:30:19 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAPt2-0000zg-Kn for hipsec@ietf.org; Wed, 31 Aug 2005 06:32:10 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F32C555E; Wed, 31 Aug 2005 12:30:17 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 12:30:17 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 12:30:16 +0200 Received: from [131.160.126.47] (rvi2-126-47.lmf.ericsson.se [131.160.126.47]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AA9532656; Wed, 31 Aug 2005 13:30:16 +0300 (EEST) Message-ID: <431586B7.2030602@ericsson.com> Date: Wed, 31 Aug 2005 13:30:15 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2005 10:30:17.0013 (UTC) FILETIME=[FACC3E50:01C5AE16] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: David Ward Subject: [Hipsec] Milestones update X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, we intend to update the milestones in our charter. This is what we intend to propose: http://hip.piuha.net/hip-milestones.txt Comments? Thanks, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 31 07:37:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAQuf-0003mM-Oq; Wed, 31 Aug 2005 07:37:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAQue-0003mE-5o for hipsec@megatron.ietf.org; Wed, 31 Aug 2005 07:37:52 -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 HAA15037 for ; Wed, 31 Aug 2005 07:37:50 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAQwH-0002kn-PW for hipsec@ietf.org; Wed, 31 Aug 2005 07:39:40 -0400 Received: from lars.local (unknown [213.196.222.242]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6B7F31BAC4D; Wed, 31 Aug 2005 13:37:28 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 20FCF227AA6; Wed, 31 Aug 2005 13:37:24 +0200 (CEST) In-Reply-To: <431586B7.2030602@ericsson.com> References: <431586B7.2030602@ericsson.com> Mime-Version: 1.0 (Apple Message framework v734) Message-Id: From: Lars Eggert Subject: Re: [Hipsec] Milestones update Date: Wed, 31 Aug 2005 13:37:21 +0200 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: HIP , David Ward X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0499457770==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============0499457770== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-31--995329389; protocol="application/pkcs7-signature" --Apple-Mail-31--995329389 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Aug 31, 2005, at 12:30, Gonzalo Camarillo wrote: > we intend to update the milestones in our charter. This is what we > intend to propose: > http://hip.piuha.net/hip-milestones.txt > Comments? Looks OK! Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-31--995329389 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUwODMxMTEzNzIyWjAjBgkqhkiG9w0BCQQxFgQUvdwYgfvO3O0NF9HLv/uv Z4mCIMgwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBANDTabdTFASJrzCRMMTiDHKW3IHaESO7IUHV1twxw3GeQ7k4nR2YjAYMnLMCM60x2tQw1J/F l2CLkDeOcVn6yQhghRnVTKG+DTuo3TbTnRvxlNsJIc62nQ/RqKFqRKzaY7ll00hiHZfTHKn6EjCy /vKfC9HxSQVFV9bZGTUBgW13/c3Tsa9ttTFuRcKqKF0beTwhNemY+4mzi78nICJS2hPnxlRANpVz nvthnpWHFlI/J7ybrmFBMJh190/dM5aVWZ/fvYvUgn/EaYUXFnR24Kz3F21rWIrYvCQeUz//pdNh XDFG8bQ3DaYzY0RC72Lqvj09BILToHxpO470KEr+OywAAAAAAAA= --Apple-Mail-31--995329389-- --===============0499457770== 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 --===============0499457770==-- From hipsec-bounces@lists.ietf.org Wed Aug 31 09:24:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASZg-00039R-Bv; Wed, 31 Aug 2005 09:24:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASZf-00039J-2h for hipsec@megatron.ietf.org; Wed, 31 Aug 2005 09:24:19 -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 JAA20243 for ; Wed, 31 Aug 2005 09:24:17 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EASbM-0005p3-P6 for hipsec@ietf.org; Wed, 31 Aug 2005 09:26:08 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BF7FA212C91; Wed, 31 Aug 2005 16:23:56 +0300 (EEST) In-Reply-To: <430F1007.7000800@nomadiclab.com> References: <1124111403.10041.10.camel@localhost.localdomain> <430F1007.7000800@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <689C45D8-6F0C-4696-8F76-612803EB68EE@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Base draft & ESP draft: snapshots Date: Wed, 31 Aug 2005 15:23:54 +0200 To: Petri Jokela X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 >> Another substantial issues is the HIT format (Sections 3.1 and 3.2; >> plus Appendix B). > > If we define the draft dependent to the HIT format specified in your > document, we would have to wait with base spec until that IPv6 prefix > draft is ready. Otherwise, we cannot make a normative reference to it > in the base spec. Currently the base defines the prefix as it was in > -03. Maybe there should be some addition that "This may change in the > future, when ...." Personally, I'd wait until the "HIT draft" is out and we've got some initial reaction from the IPv6 WG. If it seems to go fast, let's wait. If it seems to get stuck, we can forget it at this point and proceed to IESG. It may come back as a DISCUSS from some AD, though, due to the other draft... > I move puzzle solving (5.1.4) as it seems to fit to the packet > processing, but left 5.1.3 (fragmentation support) where it was. > Fragmentation is still "old procedure" while puzzle solving is > something > directly HIP related processing. But I don't know if this is correct > thinking. Checksum section (5.1.2) could also be somewhere in 6 if > 5.1.3 > goes there. Looked ok. > I edited 6.1 and 6.2 slightly. I tried to generalize the text a bit, > not discussing only about HITs towards applications. Please, have a > look > and see if it is ok or not. Looked better to me. Thanks! --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec