From hipsec-bounces@lists.ietf.org Tue May 02 05:36:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarJG-0001Ki-5H; Tue, 02 May 2006 05:36:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarJF-0001Im-Fo for hipsec@ietf.org; Tue, 02 May 2006 05:36:45 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FarJD-0001Rt-Um for hipsec@ietf.org; Tue, 02 May 2006 05:36:45 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 75CF5212C44 for ; Tue, 2 May 2006 12:36:41 +0300 (EEST) Received: from [193.234.219.71] (n71.nomadiclab.com [193.234.219.71]) by n2.nomadiclab.com (Postfix) with ESMTP id 0DB12212C3D for ; Tue, 2 May 2006 12:36:41 +0300 (EEST) Message-ID: <44572828.2020005@nomadiclab.com> Date: Tue, 02 May 2006 12:36:40 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Subject: [Hipsec] HIP Base draft X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, I have done some modifications to the base draft based on the Bellovin-Rescorla analysis. The current version ( 06-pre020506 ) can be found from: http://hip4inter.net/drafts.php A list of issues generated from the analysis follows including some comments based on agreed fixes, proposed fixes, and things still to be done. Issue numbers refer to roundup issue tracker ("Show all" on the left side shows also closed issues): http://hip4inter.net/cgi-bin/roundup.cgi/hip-base/index /Petri ISSUE 81: D-H group negotiation I included the simple version of the negotiation in the text to initiate some discussion (I'm not sure if I have covered all places in the text). The DIFFIE_HELLMAN could contain one or two different values, and the Initiator must select the stronger supported Group ID of those present in R1. (Is MUST too strong for this purpose?) Modifications in the text: 4.1.3. Authenticated Diffie-Hellman Protocol 5.2.6. DIFFIE_HELLMAN What if the hosts initiate the connection setup simultaneously? (Section 6.9, bullet 5) Do we run into new kinds of problem cases with the new negotiation? ISSUE 82: Hash algorithm dependency on the ORCHID draft Still open. Any opinions on this? Shall we keep the dependency to the ORCHID draft as it is now? ISSUE 83: Key expansion: SHA1 wired in This is changed to RHASH (Section 6.5) ISSUE 84: Fixed 160-bit field for HMAC 5.2.9, 5.2.10: changed the HMAC into variable length field. (The table in 5.2. contains still fixed length value for the parameter, will be fixed in next release) ISSUE 85: No key size negotiation (AES implies use of 128 bit keys) A text modification in 6.5. ISSUE 86: Mandatory AWES128CBC or NULL encryption Text changed in 5.2.7 ISSUE 88: Vague statement: text change required Text changed in 5.1.3 ISSUE 89: NOTIFY messages are not acknowledged Text changed in: 5.3.6., 6.13., and Security considerations ISSUE 90: Opportunistic mode needs clarification 4.1.6 added, Security considerations text changed. (+ some references to this 4.1.6 added in various places in the document) ISSUE 87: Pre-generating R1s These ISSUE 87 texts are _not_ in the published pre-version document, I just wrote some text to clarify the D-H value usage. More text is needed. 4.1.4 HIP Replay protection (changes required ?) 5.3.2 R1 - the HIP Responder Packet The Diffie-Hellman value is ephemeral, and one value SHOULD be used only for one connection. Once the Responder has received a valid response to an R1 packet, that Diffie-Hellman value SHOULD be deprecated. Because it is possible that the Responder has sent the same Diffie-Hellman value to different hosts simultaneously in corresponding R1 packets, also those responses should be accepted. However, as a defense agains I1 storms, and implementation MAY use the same Diffie-Hellman value for a period of time, for example, 15 minutes. By using a small number of different puzzles for a given Diffie-Hellman value, the R1 packets can be pre- computed and delivered as quickly as I1 packets arrive. A scavenger process should clean up unused DHs and puzzles. 6.7.1 R1 management All compliant implementations MUST produce R1 packets. An R1 packet MAY be precomputed. An R1 packet MAY be reused for time Delta T, which is implementation dependent, and SHOULD be deprecated and not used once a valid response I2 packet has been received from an Initiator. Under I1 message storm, an R1 packet may be re-used beyond this limit. R1 information MUST not be discarded until Delta S after T. Time S is the delay needed for the last I2 to arrive back to the Responder. Security considerations Denial-of-service attacks take advantage of the cost of start of state for a protocol on the Responder compared to the 'cheapness' on the Initiator. HIP makes no attempt to increase the cost of the start of state on the Initiator, but makes an effort to reduce the cost to the Responder. This is done by having the Responder start the 3-way exchange instead of the Initiator, making the HIP protocol 4 packets long. In doing this, packet 2 becomes a 'stock' packet that the Responder MAY use many times, until some Initiator has provided a valid response to such and R1 packet. During an I1 storm the host may re-use the same D-H value also beyond that point. Using the same Diffie-Hellman values and random puzzle #I has some risk. This risk needs to be balanced against a potential storm of HIP I1 packets. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 03 03:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbBnt-0002O0-KP; Wed, 03 May 2006 03:29:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbBns-0002NX-Hl for hipsec@ietf.org; Wed, 03 May 2006 03:29:44 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbBkm-0000hv-5g for hipsec@ietf.org; Wed, 03 May 2006 03:26:33 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 05299212C44; Wed, 3 May 2006 10:26:30 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B55A0212C3D; Wed, 3 May 2006 10:26:29 +0300 (EEST) In-Reply-To: <44572828.2020005@nomadiclab.com> References: <44572828.2020005@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E57EE3A-101E-4316-846C-1A2330019310@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] HIP Base draft Date: Wed, 3 May 2006 10:26:44 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > There MUST NOT be more than six (6) HIP Suite-IDs in one HIP > transform parameter. The limited number of transforms sets > the maximum size of HIP_TRANSFORM parameter. As the default > configuration, the HIP_TRANSFORM parameter MUST contain at > least one of the mandatory Suite-IDs. There MAY be a > configuration option that allows the administrator to > override this default. I would suggest starting with the following: The sender of a HIP transform parameter MUST make sure that there are no more than six (6) HIP Suite-IDs in one HIP transform parameter. Conversely, a recipient MUST be prepared to handle received transport parameters that contain more than six Suite-IDs. The limited .... [i.e. be strict in what you send and liberal in what you accept.] --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 03 09:17:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHEd-0003BT-Az; Wed, 03 May 2006 09:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHEc-0003BO-8o for hipsec@ietf.org; Wed, 03 May 2006 09:17:42 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbHEa-0007lo-UD for hipsec@ietf.org; Wed, 03 May 2006 09:17:42 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 2BDB73281; Wed, 3 May 2006 16:17:40 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 98EEC324E; Wed, 3 May 2006 16:17:39 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k43DHc6B021897; Wed, 3 May 2006 16:17:39 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Wed, 3 May 2006 16:17:38 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Petri Jokela Subject: Re: [Hipsec] HIP Base draft In-Reply-To: <44572828.2020005@nomadiclab.com> Message-ID: References: <44572828.2020005@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: HIP , Julien Laganier X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 2 May 2006, Petri Jokela wrote: > ISSUE 81: D-H group negotiation > > I included the simple version of the negotiation in the text to initiate > some discussion (I'm not sure if I have covered all places in the text). > The DIFFIE_HELLMAN could contain one or two different values, and the > Initiator must select the stronger supported Group ID of those present in R1. > (Is MUST too strong for this purpose?) I think RECOMMENDED or at least SHOULD would be better for smaller devices with lower CPU capacity. > Modifications in the text: > > 4.1.3. Authenticated Diffie-Hellman Protocol > 5.2.6. DIFFIE_HELLMAN > > What if the hosts initiate the connection setup simultaneously? (Section > 6.9, bullet 5) Do we run into new kinds of problem cases with the new > negotiation? No? System behaviour in state I1-SENT, Table 3. | Receive I1 | If the local HIT is smaller than the peer | | | HIT, drop I1 and stay at I1-SENT | | | | | | If the local HIT is greater than the peer | | | HIT, send R1 and stay at I1_SENT | So, in the case of simultaneous base exchange, the host with the smaller HIT does not reply with a R1. Petri, could you verify this also? (If I am wrong about this, we could also let the I2 carry multiple DH parameters and select max(intersection(R1_DH, I2_DH)) but I hope this is not necessary) > ISSUE 82: Hash algorithm dependency on the ORCHID draft > > Still open. Any opinions on this? Shall we keep the dependency to the > ORCHID draft as it is now? So, there are two problems: a) 120 bits and b) SHA-X wired in. What about modifying the the orchid draft so that SHA1 is just HASH() and actual hash algo is determined by the prefix? Then we need to rename all references to 120 and 128 to (ID_LEN - PREFIX_LEN) and ID_LEN. Then we need to have some recommended values for PREFIX_LEN, ID_LEN and HASH algo in the base draft. The PREFIX_LEN should 8, ID_LEN 128 and hash algos as SHA1-IME and SHA256. The two hash algos would require two different prefixes. How would this sound? -- 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 May 04 03:47:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbYYU-0003Uo-45; Thu, 04 May 2006 03:47:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbYYS-0003Uj-Ox for hipsec@ietf.org; Thu, 04 May 2006 03:47:20 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbYYR-0004xw-Ew for hipsec@ietf.org; Thu, 04 May 2006 03:47:20 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C70F1212C44; Thu, 4 May 2006 10:47:17 +0300 (EEST) Received: from [193.234.219.71] (n71.nomadiclab.com [193.234.219.71]) by n2.nomadiclab.com (Postfix) with ESMTP id 8A405212C3D; Thu, 4 May 2006 10:47:17 +0300 (EEST) Message-ID: <4459B184.4020604@nomadiclab.com> Date: Thu, 04 May 2006 10:47:16 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] HIP Base draft References: <44572828.2020005@nomadiclab.com> <2E57EE3A-101E-4316-846C-1A2330019310@nomadiclab.com> In-Reply-To: <2E57EE3A-101E-4316-846C-1A2330019310@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Pekka Nikander wrote: >> There MUST NOT be more than six (6) HIP Suite-IDs in one HIP >> transform parameter. The limited number of transforms sets >> the maximum size of HIP_TRANSFORM parameter. As the default >> configuration, the HIP_TRANSFORM parameter MUST contain at >> least one of the mandatory Suite-IDs. There MAY be a >> configuration option that allows the administrator to >> override this default. > > I would suggest starting with the following: > > The sender of a HIP transform parameter MUST make sure that there are no > more than six (6) HIP Suite-IDs in one HIP transform parameter. > Conversely, a recipient MUST be prepared to handle received transport > parameters that contain more than six Suite-IDs. The limited .... Ok, I added this. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu May 04 04:43:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZQ4-0000nH-Cl; Thu, 04 May 2006 04:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZQ3-0000nC-WF for hipsec@ietf.org; Thu, 04 May 2006 04:42:44 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbZQ2-0006ut-M2 for hipsec@ietf.org; Thu, 04 May 2006 04:42:43 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 53EC2212C44 for ; Thu, 4 May 2006 11:42:38 +0300 (EEST) Received: from [193.234.219.71] (n71.nomadiclab.com [193.234.219.71]) by n2.nomadiclab.com (Postfix) with ESMTP id DF75F212C3D for ; Thu, 4 May 2006 11:42:37 +0300 (EEST) Message-ID: <4459BE7C.6080005@nomadiclab.com> Date: Thu, 04 May 2006 11:42:36 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Hipsec] HIP ESP draft X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, I made two modifications to the ESP draft based on the security analysis. - The ESP Sequence Number is now a 64-bit value o 3.3.6 Sequence Number section is modified o 5.1.2 ESP_TRANSFORM packet description is modified The ESP_TRANSFORM contains at the moment a 16-bit reserved field. It is possible now to start Suites immediately after the length field unless we want to keep the reserved field for some possible future versions of the protocol. - 5.1.2 ESP_TRANSFORM text was changed similarly to the HIP_TRANSFORM in the base draft. The possibility to change the default configuration was added. The pre-version (040506) is available at: http://hip4inter.net/drafts.php /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 08 07:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd465-0001zl-W6; Mon, 08 May 2006 07:40:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd464-0001tS-Pj for hipsec@ietf.org; Mon, 08 May 2006 07:40:16 -0400 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd462-0002jH-FN for hipsec@ietf.org; Mon, 08 May 2006 07:40:16 -0400 Received: from [192.168.1.102] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 442BB44201FF224C; Mon, 8 May 2006 13:39:21 +0200 From: Julien Laganier To: Miika Komu Subject: Re: [Hipsec] HIP Base draft Date: Mon, 8 May 2006 13:38:54 +0200 User-Agent: KMail/1.8.2 References: <44572828.2020005@nomadiclab.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605081338.54704.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Wednesday 03 May 2006 15:17, Miika Komu wrote: > On Tue, 2 May 2006, Petri Jokela wrote: > > > > ISSUE 82: Hash algorithm dependency on the ORCHID draft > > > > Still open. Any opinions on this? Shall we keep the dependency to > > the ORCHID draft as it is now? > > So, there are two problems: a) 120 bits and b) SHA-X wired in. What > about modifying the the orchid draft so that SHA1 is just HASH() > and actual hash algo is determined by the prefix? Then we need to > rename all references to 120 and 128 to (ID_LEN - PREFIX_LEN) and > ID_LEN. > > Then we need to have some recommended values for PREFIX_LEN, ID_LEN > and HASH algo in the base draft. The PREFIX_LEN should 8, ID_LEN > 128 and hash algos as SHA1-IME and SHA256. The two hash algos would > require two different prefixes. > > How would this sound? I think that's what the draft currently recommends. The text in the security cons. sections is: All mechanism using ORCHIDs MUST use exactly the same mechanism for generating a ORCHID from the input bitstring. Allowing different mechanisms, without explicitly encoding the mechanism in the ORCHID itself, would allow so called bidding down attacks. That is, if multiple different hash functions were allowed in constructing ORCHIDs in a given shared name space, and if one of the hash functions became insecure, that would allow attacks against even those ORCHIDs that had been constructed using the other, still secure hash functions. Due to the desire to keep the hash output value as long as possible, the present design allows only one method for constructing ORCHIDs from input bitstrings. If other methods (perhaps using more secure hash functions) are later needed, they MUST use a different prefix. Consequently, the suggested method to react to the hash result becoming too short, due to increased computational power or to the used hash function becoming insecure due to advances in cryptology, is to allocate a new prefix and cease to use the present one. As of today, SHA-1 applied in conjunction with a proper expansion function of the hash input is considered as satisfying the second- preimage resistance requirement [I-D.irtf-cfrg-sha1-ime]. Hash output of at least 100 bits, but preferably up to 120 bits, is considered to have a low enough probability of collisions. How would you like that to be changed? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 08 08:35:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4wg-0002fq-Qv; Mon, 08 May 2006 08:34:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4we-0002ei-8y for hipsec@ietf.org; Mon, 08 May 2006 08:34:36 -0400 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd4uT-0005do-HX for hipsec@ietf.org; Mon, 08 May 2006 08:32:23 -0400 Received: from [192.168.10.109] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 442BB58F0232BADC; Mon, 8 May 2006 14:31:00 +0200 From: Julien Laganier To: Miika Komu Subject: SHA1 hard coded / wired in (Was: [Hipsec] HIP Base draft) Date: Mon, 8 May 2006 14:30:34 +0200 User-Agent: KMail/1.8.2 References: <44572828.2020005@nomadiclab.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605081430.35227.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Wednesday 03 May 2006 15:17, Miika Komu wrote: > On Tue, 2 May 2006, Petri Jokela wrote: > > > ISSUE 82: Hash algorithm dependency on the ORCHID draft > > > > Still open. Any opinions on this? Shall we keep the dependency to > > the ORCHID draft as it is now? > > So, there are two problems: a) 120 bits and b) SHA-X wired in. What > about modifying the the orchid draft so that SHA1 is just HASH() > and actual hash algo is determined by the prefix? Then we need to > rename all references to 120 and 128 to (ID_LEN - PREFIX_LEN) and > ID_LEN. One more thought w.r.t. to b) : IMHO saying that SHA1 is hardcoded in the ORCHID draft is more less like saying that SHA1 is hardcoded in the SHA1 RFC. The ORCHID draft defines the allocation of _a prefix_ to store ORCHIDs based on SHA1. if SHA1 ORCHIDs are deemed unsecured then one can choose a new hash function X and define HASH_X ORCHIDs which would be stored under a new prefix to be chosen (that is explained in sec-cons of the draft). It would be the role of another draft to define that prefix and that hash X. Perhaps this should be stressed more strongly in the draft; any text suggestion is welcomed. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 08 08:37:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4z9-0003U9-8y; Mon, 08 May 2006 08:37:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4z7-0003U4-MP for hipsec@ietf.org; Mon, 08 May 2006 08:37:09 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd4z5-00066d-B5 for hipsec@ietf.org; Mon, 08 May 2006 08:37:09 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7BE162E17; Mon, 8 May 2006 15:37:06 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 0E3B32C7F; Mon, 8 May 2006 15:37:06 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k48Cb5tC011582; Mon, 8 May 2006 15:37:05 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Mon, 8 May 2006 15:37:05 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: SHA1 hard coded / wired in (Was: [Hipsec] HIP Base draft) In-Reply-To: <200605081430.35227.julien.IETF@laposte.net> Message-ID: References: <44572828.2020005@nomadiclab.com> <200605081430.35227.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 8 May 2006, Julien Laganier wrote: > On Wednesday 03 May 2006 15:17, Miika Komu wrote: >> On Tue, 2 May 2006, Petri Jokela wrote: >> >>> ISSUE 82: Hash algorithm dependency on the ORCHID draft >>> >>> Still open. Any opinions on this? Shall we keep the dependency to >>> the ORCHID draft as it is now? >> >> So, there are two problems: a) 120 bits and b) SHA-X wired in. What >> about modifying the the orchid draft so that SHA1 is just HASH() >> and actual hash algo is determined by the prefix? Then we need to >> rename all references to 120 and 128 to (ID_LEN - PREFIX_LEN) and >> ID_LEN. > > One more thought w.r.t. to b) : > > IMHO saying that SHA1 is hardcoded in the ORCHID draft is more less > like saying that SHA1 is hardcoded in the SHA1 RFC. > > The ORCHID draft defines the allocation of _a prefix_ to store ORCHIDs > based on SHA1. if SHA1 ORCHIDs are deemed unsecured then one can > choose a new hash function X and define HASH_X ORCHIDs which would be > stored under a new prefix to be chosen (that is explained in sec-cons > of the draft). It would be the role of another draft to define that > prefix and that hash X. > > Perhaps this should be stressed more strongly in the draft; any text > suggestion is welcomed. First, I'll take back my original suggestion. Second, if there is going to be a 02 version (not sure if it is necessary), I'd just clarify section 2 (Cryptographic Hash Identifier Construction). In the algorithm description, SHA1 and 128 bits look like they were hardcoded (hence my original comments), but they are clarified in the following text. -- 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 May 11 07:44:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9ah-0004qP-R4; Thu, 11 May 2006 07:44:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9ag-0004qK-4j for hipsec@ietf.org; Thu, 11 May 2006 07:44:22 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe9af-0004nL-La for hipsec@ietf.org; Thu, 11 May 2006 07:44:22 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D6865212C5D; Thu, 11 May 2006 14:44:11 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id A017F212C59; Thu, 11 May 2006 14:44:11 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 66AA2BDC40; Thu, 11 May 2006 14:44:11 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 2E58BBDC38; Thu, 11 May 2006 14:44:11 +0300 (EEST) In-Reply-To: <200605081430.35227.julien.IETF@laposte.net> References: <44572828.2020005@nomadiclab.com> <200605081430.35227.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: SHA1 hard coded / wired in (Was: [Hipsec] HIP Base draft) Date: Thu, 11 May 2006 14:44:27 +0300 To: Julien Laganier X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org El 08/05/2006, a las 15:30, Julien Laganier escribi=F3: > On Wednesday 03 May 2006 15:17, Miika Komu wrote: >> On Tue, 2 May 2006, Petri Jokela wrote: >> >>> ISSUE 82: Hash algorithm dependency on the ORCHID draft >>> >>> Still open. Any opinions on this? Shall we keep the dependency to >>> the ORCHID draft as it is now? >> >> So, there are two problems: a) 120 bits and b) SHA-X wired in. What >> about modifying the the orchid draft so that SHA1 is just HASH() >> and actual hash algo is determined by the prefix? Then we need to >> rename all references to 120 and 128 to (ID_LEN - PREFIX_LEN) and >> ID_LEN. > > One more thought w.r.t. to b) : > > IMHO saying that SHA1 is hardcoded in the ORCHID draft is more less > like saying that SHA1 is hardcoded in the SHA1 RFC. > > The ORCHID draft defines the allocation of _a prefix_ to store ORCHIDs > based on SHA1. if SHA1 ORCHIDs are deemed unsecured then one can > choose a new hash function X and define HASH_X ORCHIDs which would be > stored under a new prefix to be chosen (that is explained in sec-cons > of the draft). It would be the role of another draft to define that > prefix and that hash X. > but this would require an additional /8 allocated to the orchids, right? i mean, in order to specify what hash algorithm is used, you need bits=20= in the address, the question is whether you take this bits out of the=20 prefix or out of the crypto part. If you take them out of the crypto=20 part, the result is that the security is weaker (less hash bits), but=20 if you take them out of the prefix part, this means that you need to=20 use more global address space for this, which may well be unacceptable In this global address space conservation/security tradeoff i would=20 suggest to preserve global address space and use some bits (e.g. 3=20 bots) from the hash part to encode the hash function used... regards, marcelo > Perhaps this should be stressed more strongly in the draft; any text > suggestion is welcomed. > > --julien > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu May 11 08:39:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeARG-0004OA-MF; Thu, 11 May 2006 08:38:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeARE-0004O5-QD for hipsec@lists.ietf.org; Thu, 11 May 2006 08:38:40 -0400 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeARE-00073q-FN for hipsec@lists.ietf.org; Thu, 11 May 2006 08:38:40 -0400 Received: from [192.168.1.102] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 442BB4E402A4F8F4; Thu, 11 May 2006 14:38:27 +0200 From: Julien Laganier To: marcelo bagnulo braun Subject: Re: SHA1 hard coded / wired in (Was: [Hipsec] HIP Base draft) Date: Thu, 11 May 2006 14:37:54 +0200 User-Agent: KMail/1.8.2 References: <44572828.2020005@nomadiclab.com> <200605081430.35227.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605111437.55188.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: hipsec@lists.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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Marcelo, On Thursday 11 May 2006 13:44, marcelo bagnulo braun wrote: > > > IMHO saying that SHA1 is hardcoded in the ORCHID draft is more > > less like saying that SHA1 is hardcoded in the SHA1 RFC. > > > > The ORCHID draft defines the allocation of _a prefix_ to store > > ORCHIDs based on SHA1. if SHA1 ORCHIDs are deemed unsecured then > > one can choose a new hash function X and define HASH_X ORCHIDs > > which would be stored under a new prefix to be chosen (that is > > explained in sec-cons of the draft). It would be the role of > > another draft to define that prefix and that hash X. > > but this would require an additional /8 allocated to the orchids, > right? If we decide to allocate an 8 bits for SHA1 ORCHIDs yes. However I don't think we reached yet any sort of agreements on the *right* size of the prefix. My educated guess is that it seems fine as long as we have at least 96 bits to store the hash output (i.e. prefix is a /32). Others might disagree. > i mean, in order to specify what hash algorithm is used, you need > bits in the address, the question is whether you take this bits out > of the prefix or out of the crypto part. If you take them out of > the crypto part, the result is that the security is weaker (less > hash bits), but if you take them out of the prefix part, this means > that you need to use more global address space for this, which may > well be unacceptable Right. I think we discussed that a while ago. I try to summarize the conclusion we once reached below... > In this global address space conservation/security tradeoff i would > suggest to preserve global address space and use some bits (e.g. 3 > bots) from the hash part to encode the hash function used... Actually as long as we did not decide on the prefix length, doing one way or another (i.e. allocating new prefixes for store new hashes, or reserving bits under the prefix to indicate the prefix) is the same thing. You propose to have plen = 8, and then 3 bits for hash, that would let us 117 bits for the hash while allowing for 8 different hash functions. But it would be exactly equivalent to use plen = 11, have as much bits for the hash (117), and reserve a new prefix per new hash function, _as long as we do not need to define more than 8 different hash functions for ORCHIDs_ I think the real issue here is to evaluate how many different hash functions we will need in the future. Once you're settled on that doing it one way (single prefix per hash function, as in the ORCHID I-D) or the other way (hash function encoded by some bits under the prefix, as proposed by some people) is IMO exactly equivalent. It's a matter of taste, and on that matter I think I'm tasteless :-) Best, --julien > regards, marcelo > > > Perhaps this should be stressed more strongly in the draft; any > > text suggestion is welcomed. > > > > --julien > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu May 11 08:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAcA-0005Sh-2k; Thu, 11 May 2006 08:49:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAc8-0005R0-IZ for hipsec@lists.ietf.org; Thu, 11 May 2006 08:49:56 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeAc4-0007e6-0A for hipsec@lists.ietf.org; Thu, 11 May 2006 08:49:56 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 27CC5212C5D; Thu, 11 May 2006 15:49:48 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id B4151212C59; Thu, 11 May 2006 15:49:47 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 46F33BDC40; Thu, 11 May 2006 15:49:47 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 1093BBDC38; Thu, 11 May 2006 15:49:47 +0300 (EEST) In-Reply-To: <200605111437.55188.julien.IETF@laposte.net> References: <44572828.2020005@nomadiclab.com> <200605081430.35227.julien.IETF@laposte.net> <200605111437.55188.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <577a91e8c9393a726e851d5add7d519f@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: SHA1 hard coded / wired in (Was: [Hipsec] HIP Base draft) Date: Thu, 11 May 2006 15:50:03 +0300 To: Julien Laganier X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: hipsec@lists.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: , Errors-To: hipsec-bounces@lists.ietf.org El 11/05/2006, a las 15:37, Julien Laganier escribi=F3: > Hi Marcelo, > > On Thursday 11 May 2006 13:44, marcelo bagnulo braun wrote: >> >>> IMHO saying that SHA1 is hardcoded in the ORCHID draft is more >>> less like saying that SHA1 is hardcoded in the SHA1 RFC. >>> >>> The ORCHID draft defines the allocation of _a prefix_ to store >>> ORCHIDs based on SHA1. if SHA1 ORCHIDs are deemed unsecured then >>> one can choose a new hash function X and define HASH_X ORCHIDs >>> which would be stored under a new prefix to be chosen (that is >>> explained in sec-cons of the draft). It would be the role of >>> another draft to define that prefix and that hash X. >> >> but this would require an additional /8 allocated to the orchids, >> right? > > If we decide to allocate an 8 bits for SHA1 ORCHIDs yes. However I > don't think we reached yet any sort of agreements on the *right* size > of the prefix. My educated guess is that it seems fine as long as we > have at least 96 bits to store the hash output (i.e. prefix is > a /32). Others might disagree. > ok, i wasn't aware of this. I thought that the idea was to assign a /8=20= so i didn't thought it was acceptable to use even more global address=20 space for the orchids to support another hash function but if you think that a /32 per hash function is enough i strongly=20 suggest to state it clearly in the draft, since it would be much easier=20= to get it accepted than as it is written now where it seems that the=20 proposal is to ask for a /8 allocation for this experiment (you may=20 even ask for a RIR allocation for experimental purposes, of a /30 or=20 similar) >> i mean, in order to specify what hash algorithm is used, you need >> bits in the address, the question is whether you take this bits out >> of the prefix or out of the crypto part. If you take them out of >> the crypto part, the result is that the security is weaker (less >> hash bits), but if you take them out of the prefix part, this means >> that you need to use more global address space for this, which may >> well be unacceptable > > Right. I think we discussed that a while ago. I try to summarize the > conclusion we once reached below... > >> In this global address space conservation/security tradeoff i would >> suggest to preserve global address space and use some bits (e.g. 3 >> bots) from the hash part to encode the hash function used... > > Actually as long as we did not decide on the prefix length, doing one > way or another (i.e. allocating new prefixes for store new hashes, or > reserving bits under the prefix to indicate the prefix) is the same > thing. > > You propose to have plen =3D 8, and then 3 bits for hash, that would = let > us 117 bits for the hash while allowing for 8 different hash > functions. > > But it would be exactly equivalent to use plen =3D 11, have as much = bits > for the hash (117), and reserve a new prefix per new hash function, > _as long as we do not need to define more than 8 different hash > functions for ORCHIDs_ > > I think the real issue here is to evaluate how many different hash > functions we will need in the future. > > Once you're settled on that doing it one way (single prefix per hash > function, as in the ORCHID I-D) or the other way (hash function > encoded by some bits under the prefix, as proposed by some people) is > IMO exactly equivalent. It's a matter of taste, and on that matter I > think I'm tasteless :-) > agree regards, marcelo > Best, > > --julien > >> regards, marcelo >> >>> Perhaps this should be stressed more strongly in the draft; any >>> text suggestion is welcomed. >>> >>> --julien >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu May 11 09:10:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAvq-0002wR-1P; Thu, 11 May 2006 09:10:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAvo-0002wM-Ua for hipsec@lists.ietf.org; Thu, 11 May 2006 09:10:16 -0400 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeAvo-0000Jn-L9 for hipsec@lists.ietf.org; Thu, 11 May 2006 09:10:16 -0400 Received: from [192.168.1.102] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 442BB27001A239AE; Thu, 11 May 2006 15:09:36 +0200 From: Julien Laganier To: marcelo bagnulo braun Subject: Re: SHA1 hard coded / wired in (Was: [Hipsec] HIP Base draft) Date: Thu, 11 May 2006 15:09:03 +0200 User-Agent: KMail/1.8.2 References: <44572828.2020005@nomadiclab.com> <200605111437.55188.julien.IETF@laposte.net> <577a91e8c9393a726e851d5add7d519f@it.uc3m.es> In-Reply-To: <577a91e8c9393a726e851d5add7d519f@it.uc3m.es> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200605111509.03720.julien.IETF@laposte.net> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: hipsec@lists.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: , Errors-To: hipsec-bounces@lists.ietf.org On Thursday 11 May 2006 14:50, marcelo bagnulo braun wrote: > El 11/05/2006, a las 15:37, Julien Laganier escribi=F3: > > > > If we decide to allocate an 8 bits for SHA1 ORCHIDs yes. However > > I don't think we reached yet any sort of agreements on the > > *right* size of the prefix. My educated guess is that it seems > > fine as long as we have at least 96 bits to store the hash output > > (i.e. prefix is a /32). Others might disagree. > > ok, i wasn't aware of this. I thought that the idea was to assign a > /8 so i didn't thought it was acceptable to use even more global > address space for the orchids to support another hash function > > but if you think that a /32 per hash function is enough i strongly > suggest to state it clearly in the draft, since it would be much > easier to get it accepted than as it is written now where it seems > that the proposal is to ask for a /8 allocation for this experiment > (you may even ask for a RIR allocation for experimental purposes, > of a /30 or similar) Well, I'm not so sure about that. The current draft says: As a baseline (TO BE DISCUSSED), we propose an 8-bit prefix to be allocated from the 1000::/4 block. IIRC, none of the people opposing ORCHIDs did so based on the length=20 of the prefix allocation, and we did not discuss it much either.=20 Rather, they opposed the idea of "stealing" locator space to store=20 unroutable identifiers (and flat, furthermore ;-)=20 =2D-julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 15 19:22:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfmNh-0007rB-4B; Mon, 15 May 2006 19:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfmNf-0007r1-Kr for hipsec@ietf.org; Mon, 15 May 2006 19:21:39 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfmNe-0002Hu-Bn for hipsec@ietf.org; Mon, 15 May 2006 19:21:39 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA10742; Mon, 15 May 2006 18:21:27 -0500 (CDT) 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 k4FNLRG13080; Mon, 15 May 2006 18:21:27 -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.1830); Mon, 15 May 2006 16:21:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] HIP Base draft Date: Mon, 15 May 2006 16:21:25 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F1EF@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <44572828.2020005@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] HIP Base draft Thread-Index: AcZty/d5fW1Hex0KRjOxMug0sFxojAKoYU4g From: "Henderson, Thomas R" To: "Petri Jokela" , "HIP" X-OriginalArrivalTime: 15 May 2006 23:21:25.0283 (UTC) FILETIME=[48FFB730:01C67876] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Tuesday, May 02, 2006 2:37 AM > To: HIP > Subject: [Hipsec] HIP Base draft >=20 > Folks, >=20 > I have done some modifications to the base draft based on the=20 > Bellovin-Rescorla analysis. The current version (=20 > 06-pre020506 ) can be=20 > found from: >=20 > http://hip4inter.net/drafts.php Petri and others, I have some comments on the deltas from -05 to -06pre020506. I will respond to the other open issues in a separate message. 1. HIT format (Section 3.1) I found this to be ambiguous. From the current -06pre draft: 0 2 0 1 2 3 4 5 6 7 8 ... 7 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | Hash | +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (8 bits) - Fixed prefix, TBD (0x11, TO BE DISCUSSED), as defined per [22]. Encoding (120 bits) - Encoding of the public key and KHI ORCHID context identifier as defined per [22]. As I understand it, the ORCHID is the entire 128-bit quantity, but the above description implies to me that the HIT is a Prefix + ORCHID (btw, "Encoding" does not match with "Hash" in the figure). I think we have the situation now that a HIT is a specific type of ORCHID, differentiated from other ORCHIDs by use of the Prefix and Context ID in the ORCHID generation. Maybe the draft should state this clearly. Further, if KHI is intended to be normative for this draft, then HIP draft maybe should just describe HITs here as "a type of ORCHID, based on a SHA1 hash of the host identity (Section 2 of [22])" and not try to imprecisely replicate the specification text. As an aside, from the ORCHID draft: As a baseline (TO BE DISCUSSED), we propose taking middlemost bits from the SHA1 output. this seems like a dangerous way to specify it-- what does "middlemost" mean?-- should clarify exactly which bits you mean. Finally (also an ORCHID comment), it seems that one can determine the hash function used for the ORCHID by inspection of the ORCHID (the Prefix identifies this), but one cannot determine whether it is a HIT or other usage (e.g. TMI) because the context identifier is buried in the hash input-- is this intentional or of any practical concern? 2. RHASH algorithm It is not directly stated in the draft how RHASH is determined. It should state clearly something like the following: "RHASH can be determined by inspecting the Prefix of the ORCHID (HIT). The Prefix value has a one-to-one mapping to a hash function." Maybe this could be added to the definition in Section 2.3.=20 * Note, this requires resolution of the issue of "Prefix + hash ID" vs. "longer prefix" thread where Julien lost his taste. 3. Text in section 4.1.3 When the Initiator receives an R1, it gets one or two Responder's public Diffie-Hellman values. If there are two values, it selects the stronger value of these, and computes the Diffie-Hellman session key. =20 ^^^^^ I think you mean to say "selects the value corresponding to the strongest supported Group ID" Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 16 08:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyHs-0007wL-8v; Tue, 16 May 2006 08:04:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyHr-0007wC-Bf for hipsec@ietf.org; Tue, 16 May 2006 08:04:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfyHr-0002jq-AC for hipsec@ietf.org; Tue, 16 May 2006 08:04:27 -0400 Received: from creon.otaverkko.fi ([212.68.0.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ffy3R-0004tv-SN for hipsec@ietf.org; Tue, 16 May 2006 07:49:39 -0400 Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id BC2BB21AF43; Tue, 16 May 2006 14:49:31 +0300 (EEST) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24342-05; Tue, 16 May 2006 14:49:26 +0300 (EEST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 2870B21AF38; Tue, 16 May 2006 14:49:26 +0300 (EEST) Received: from [217.152.227.136] (unknown [217.152.227.136]) by argo.otaverkko.fi (Postfix) with ESMTP id F367125ED06; Tue, 16 May 2006 14:49:25 +0300 (EEST) Message-ID: <4469BC4B.8030507@hiit.fi> Date: Tue, 16 May 2006 14:49:31 +0300 From: Andrey Khurri User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipl , HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at otaverkko.fi X-Spam-Score: -0.4 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Hipsec] hipl for Nokia 770 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Dear all, I have been working on porting HIPL userspace applications to Nokia 770 Internet Tablet http://europe.nokia.com/nokia/0,,74866,00.html. The purpose was to try HIP protocol with a mobile device such as this Linux based Tablet and more specifically to run HIP base exchange in between tablet and i386 PC, and then evaluate its perfomance. Various aspects are interesting to test, i.e. mobility, resource consumption for the Nokia while running HIP, time issues etc. I have HIPL userspace applications as a debian binary package for the Nokia 770. It can be installed on the Tablet using either 'Application Installer' from the 'Control panel' or 'app-installer-tool' from the command line in the terminal. HIP base exchange seems to be working now however I didn't experiment much on that yet. So additional tests are needed to see if it might run into a trouble and to get more perfomance results. In order to run HIPL applications some modifications to the Linux kernel and patches are neccesary. With regards to this I recompiled Nokia 770 kernel. The new kernel image can be deployed onto the device using special utility called 'flasher'. The hipl debian package, kernel image along with some other useful packages for the Nokia 770 are available now at http://www.infrahip.net/MERCoNe So in case you have your Nokia 770 and are interested in trying hipl on it you might download packages from the given link and install them on your device. You would better do this while following HOWTO which you will find on http://www.infrahip.net/MERCoNe/HOWTO.html If you have any problems or misunderstanding on the matter feel free to ask by email. That would be very useful to get your feedback on how it all works for you. Best regards, Andrey -- Andrey Khurri, Researcher Helsinki Institute for Information Technology (HIIT) Tel: +358 50 384 1510 Fax: +358 9 694 9768 andrey.khurri@hiit.fi _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 16 11:21:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg1M5-0001tG-PC; Tue, 16 May 2006 11:21:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg1M4-0001tB-6V for hipsec@ietf.org; Tue, 16 May 2006 11:21:00 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg1M2-0003YZ-SW for hipsec@ietf.org; Tue, 16 May 2006 11:21:00 -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 IAA16491; Tue, 16 May 2006 08:20:47 -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 k4GFKmG19273; Tue, 16 May 2006 10:20:48 -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.1830); Tue, 16 May 2006 08:20:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] HIP Base draft Date: Tue, 16 May 2006 08:20:47 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F1F1@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <44572828.2020005@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] HIP Base draft Thread-Index: AcZty/d5fW1Hex0KRjOxMug0sFxojAKp5dSA From: "Henderson, Thomas R" To: "Petri Jokela" , "HIP" X-OriginalArrivalTime: 16 May 2006 15:20:48.0195 (UTC) FILETIME=[4F2B0930:01C678FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Responding now to the issues below. > A list of issues generated from the analysis follows including some > comments based on agreed fixes, proposed fixes, and things still to be > done. Issue numbers refer to roundup issue tracker ("Show all" on the > left side shows also closed issues): >=20 > http://hip4inter.net/cgi-bin/roundup.cgi/hip-base/index >=20 > /Petri >=20 >=20 >=20 > ISSUE 81: D-H group negotiation >=20 > I included the simple version of the negotiation in the text=20 > to initiate > some discussion (I'm not sure if I have covered all places in=20 > the text). > The DIFFIE_HELLMAN could contain one or two different values, and the > Initiator must select the stronger supported Group ID of=20 > those present=20 > in R1. (Is MUST too strong for this purpose?) I don't know what the criteria are for "MUST"-- I think SHOULD would suffice since it doesn't affect interoperability, but maybe MUST is appropriate as a really strong hint to implementors. >=20 > Modifications in the text: >=20 > 4.1.3. Authenticated Diffie-Hellman Protocol > 5.2.6. DIFFIE_HELLMAN >=20 > What if the hosts initiate the connection setup=20 > simultaneously? (Section > 6.9, bullet 5) Do we run into new kinds of problem cases with the new > negotiation? >=20 I'll respond to Miika's post on this. >=20 >=20 > ISSUE 82: Hash algorithm dependency on the ORCHID draft >=20 > Still open. Any opinions on this? Shall we keep the dependency to the > ORCHID draft as it is now? >=20 This handled in another thread-- I do not have a strong opinion. I do not know what the way forward is on the ORCHID draft since it doesn't seem to be generating any current activity. I don't have any comment on (am OK with) the other issue resolutions. I agree with Pekka's proposal on HIP transform parameter. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 16 12:52:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg2mI-00069Z-46; Tue, 16 May 2006 12:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg2mH-00069O-4y for hipsec@ietf.org; Tue, 16 May 2006 12:52:09 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg2mG-0001Rw-MX for hipsec@ietf.org; Tue, 16 May 2006 12:52:09 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA16542; Tue, 16 May 2006 09:51:49 -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 k4GGpmG14931; Tue, 16 May 2006 11:51:48 -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.1830); Tue, 16 May 2006 09:51:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: collision in base exchange (was RE: [Hipsec] HIP Base draft) Date: Tue, 16 May 2006 09:51:47 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F1F6@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: collision in base exchange (was RE: [Hipsec] HIP Base draft) Thread-Index: AcZutHfy6Nun/2h9RrGyS34OYBIRxwKQ3SBw From: "Henderson, Thomas R" To: "Miika Komu" , "Petri Jokela" X-OriginalArrivalTime: 16 May 2006 16:51:47.0995 (UTC) FILETIME=[057666B0:01C67909] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: HIP , Julien Laganier X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Responding to the question about whether the current specification is correct for cases in which two hosts are trying to establish an association simultaneously to one another: > > What if the hosts initiate the connection setup=20 > simultaneously? (Section > > 6.9, bullet 5) Do we run into new kinds of problem cases=20 > with the new > > negotiation? >=20 > No? System behaviour in state I1-SENT, Table 3. >=20 > | Receive I1 | If the local HIT is smaller than=20 > the peer | > | | HIT, drop I1 and stay at I1-SENT =20 > | > | | =20 > | > | | If the local HIT is greater than=20 > the peer | > | | HIT, send R1 and stay at I1_SENT =20 > | >=20 > So, in the case of simultaneous base exchange, the host with=20 > the smaller=20 > HIT does not reply with a R1. Petri, could you verify this also? > I agree. The normative text is in section 6.7: 3. If the Responder is in I1-SENT state, it must make a comparison between the sender's HIT and its own HIT. If the sender's HIT is greater than its own HIT, it should drop the I1 and stay at I1- SENT. If the sender's HIT is smaller than its own HIT, it should send R1 and stay at I1-SENT. The HIT comparison goes similarly as in Section 6.5. Note that there may be some transient failure cases when the host with the smaller HIT is having trouble reaching the host with the larger HIT for some reason (such as when the two hosts are using different locators in the base exchange), but that is a multihoming case outside the scope of this spec, probably is relatively rare, and probably just incurs some timeouts before recovering correctly. It might be worth clarifying: s/its own HIT/its own (i.e., the receiver's) HIT/ I decided to check the rest of the existing text on collisions by examining some sketched out collision cases. While nothing is technically wrong as currently stated, I would suggest some clarifications (below). *********** In Section 6.8 (R1 processing): " The following steps define the conceptual processing rules for responding to an R1 packet: 1. A system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., it has a HIP association that is in state I1-SENT and that is associated with the HITs in the R1. IP addresses in the received R1 packet SHOULD be ignored and the match SHOULD be based on HITs only). If so, it should process the R1 as described below. Note that when the connection was initialized in opportunistic mode, HITs cannot be used, but the Initiator must rely on the Responder's IP address in the received R1 packet. See also "HIP Opportunistic Mode" (Section 4.1.6)." I would suggest the following, to avoid saying too much constraining future definition of opportunistic mode: 1. A system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., it has a HIP association that is in state I1-SENT and that is associated with the HITs in the R1). Unless the I1 was sent in opportunistic mode (see also "HIP Opportunistic Mode" (Section 4.1.6)), IP=20 addresses in the received R1 packet SHOULD be ignored and the match SHOULD be based on HITs only. If a match exists, the system should process the R1 as described below. =20 Also, I came across this sentence later in this section: " 8. The system SHOULD attempt to validate the HIT against the received Host Identity." I couldn't find anywhere in the draft where "validate the HIT" is explained, so it might be worth adding a phrase for clarity: "by using the received Host Identity to construct a HIT and verify that it matches the Sender's HIT." ************* In section 6.9 (I2 processing): " 4. If the system is in the I2-SENT state, it makes a comparison between its local and sender's HITs (similarly as in Section 6.5). If the local HIT is smaller than the sender's HIT, it should drop the I2 packet. Otherwise, the system should process the received I2 packet." I would add to the end of this last sentence "and drop any previously derived Diffie-Hellman keying material Kij it might have formed upon sending the I2 previously.", just to be clear. " 5. To avoid the possibility to end up with different session keys due to symmetric operation of the peer nodes, the Diffie-Hellman key, I, and J selection is also based on the HIT comparison. If the local HIT is smaller than the peer HIT, the system uses peer Diffie-Hellman key and nonce I from the R1 packet received earlier. The local Diffie-Hellman key and nonce J are taken from the I2 packet sent to the peer earlier. Otherwise, it uses peer Diffie-Hellman key and nonce J from the just arrived I2. The local Diffie-Hellman key and nonce I are the ones that it sent ealier in the R1 packet." The text above only makes sense ("R1 packet received earlier") in a collision scenario. Normally, when a responder receives I2, it has not previously received an R1. I would therefore suggest merging the above #5 as a continuation of #4 (i.e., it applies only in the case where the receiver is in I2-SENT state). If we merge #5 with #4, then we can add a new #5 that clarifies, in the case of being in I1-SENT and receiving I2 that matches the HITs in its previous I1, that the I1 retransmission timer is stopped. Something like: 5. If the system is in the I1-SENT state, and the HITs in the I2 match those used in the previously sent I1, the system uses this received I2 as the basis for the HIP assocation it was trying=20 to form, and stops retransmitting I1 (provided that the I2 passes the below additional checks). Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 16 13:03:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg2xS-0000c7-O1; Tue, 16 May 2006 13:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg2xR-0000c1-C2 for hipsec@ietf.org; Tue, 16 May 2006 13:03:41 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg2xQ-0001rT-3B for hipsec@ietf.org; Tue, 16 May 2006 13:03:41 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA01425; Tue, 16 May 2006 10:03:35 -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 k4GH3br14784; Tue, 16 May 2006 10:03:37 -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.1830); Tue, 16 May 2006 10:03:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] HIP ESP draft Date: Tue, 16 May 2006 10:03:30 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F1F8@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <4459BE7C.6080005@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] HIP ESP draft Thread-Index: AcZvVsjGjrTsqLJbQ4+Wf8n+lR3JbgJsylUw From: "Henderson, Thomas R" To: "Petri Jokela" , "HIP" X-OriginalArrivalTime: 16 May 2006 17:03:30.0296 (UTC) FILETIME=[A8110780:01C6790A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Thursday, May 04, 2006 1:43 AM > To: HIP > Subject: [Hipsec] HIP ESP draft >=20 > Folks, >=20 > I made two modifications to the ESP draft based on the=20 > security analysis. >=20 >=20 > - The ESP Sequence Number is now a 64-bit value >=20 > o 3.3.6 Sequence Number section is modified > o 5.1.2 ESP_TRANSFORM packet description is modified >=20 > The ESP_TRANSFORM contains at the moment a 16-bit reserved field. > It is possible now to start Suites immediately after the length > field unless we want to keep the reserved field for some=20 > possible future > versions of the protocol. Unless someone thinks of an anticipated need, I would suggest to remove the reserved field here. >=20 > - 5.1.2 ESP_TRANSFORM text was changed similarly to the HIP_TRANSFORM > in the base draft. The possibility to change the default configuration > was added. OK >=20 > The pre-version (040506) is available at: >=20 > http://hip4inter.net/drafts.php >=20 > /petri >=20 Some minor editorial nits in Section 5.1.2: first party sends a selection of transfrom families in the ^^^^^^^^^^ transform are no more than six (6) HIP Suite-IDs in one ^^^ (suggest to delete "HIP" and call them Suite-IDs) =20 Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 16 17:45:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7Lm-00031A-56; Tue, 16 May 2006 17:45:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7Ll-000315-8c for hipsec@ietf.org; Tue, 16 May 2006 17:45:05 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7Lh-0001Ja-Ja; Tue, 16 May 2006 17:45:05 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CF25030D3; Wed, 17 May 2006 00:45:00 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id F37A63088; Wed, 17 May 2006 00:44:59 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k4GLixio008069; Wed, 17 May 2006 00:44:59 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Wed, 17 May 2006 00:44:59 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: hipsec-rg@ietf.org Subject: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org (Apologies for double copies, used the old list address by accident) Earlier I left the topic "RE: feedback from draft-hip-applications-02" dangling on hipsec-rg list. Let me now return to that topic by providing some more concrete text to the draft. Sorry for crossposting both to WG and RG lists, but the draft is now an official WG item. Comments are welcome, as always. Thomas, feel free modify and adapt the text to the draft. 3.2. Using DNS .. New paragraph: "Return HIP HITs instead of IP addresses": For legacy applications that are not hard coded using IPv4 addresses, it is also possible to return HITs in resolver calls. An advantage of returning a HIT in comparison to returning an LSI is that a HIT is not only a locally created identifier but rather has a global meaning. The drawbacks are mostly related to referrals which are discussed in detail in section <3.4>. Additionally, the resolver implementation has to be careful to return the HITs only when the application requests AF_ANY or AF_INET6 type of addresses. A HIP enabled resolver is expected to return first the HITs and only after that a list of IPv6 addresses, unless the AI_HIP flag is set, as descibed in more detail in section <3.5>. Suggest adding new section 3.4: Referral issues A referral is the case when three or more instances of an application interacts and the first instance communicates with the second instance, and then communicates with the third instances and wishes to tell the third instance how to contact the second instance [B]. In order to maximize backwards compatibility with legacy applications, it is important to consider the type of referrals that applications use. However, maximizing backwards compatibility may have some negative impacts that need to be considered. In this section, we consider four types of referrals: end-point identifiers (HITs), end-point locators (IP addresses) and middlebox locators (rendezvous). Using HITs as referrals may not work with legacy hosts that are not HIP capable as the HITs are not routable. Having routable HITs requires additional infrastructure, such as overlays [C]. In addition, resolving HITs to IP addresses in HIP aware applications requires also extra infrastructure such as DHTs because HITs contain no hierarchical information, which is really required by DNS. A benefit of using HITs at the application layer is that they have a longer expected lifetime than IP addresses in mobile environments. However, there may be middleboxes, such as NATs between the end-points. As a HIT denotes an end-point rather than "middle-point", HITs might be more useful than locators with NATted environments, especially when end-points are mobile and when both communicating end-points are behind NATs. On the other hand, the use of end-point IP addresses as referrals has the quite the opposite benefits and drawbacks to HITs. One benefit of using end-point IP addresses as referrals is that they are backwards compatible even with legacy hosts that are not HIP capable. In addition, they do not require any new infrastructure. As a drawback, the expected lifetime of IP addresses in mobile environments is lower than HITs. Another drawback is that it may be more difficult to disambiquite whether a given IP address belongs to the end-point host or e.g. a NAT middle-box. Using rendezvous IP addresses as referrals does not work with legacy hosts that are not HIP capable. In addition, the rendezvous servers themselves are required as an additional infrastructure. As a benefit, the expected lifetime of this type of referrals is also longer than for end-point addresses in mobile environments. As a second benefit, this case might be useful for establishing opportunistic HIP connection between HIP capable hosts assuming that the rendezvous server has a sufficient supply of locators (one dedicated locator per one responder). When a single rendezvous address is dedicated for a single responder, using rendezvous addresses as referrals may be less ambigious than when using end-point addresses, but more ambiguous than when using HITs. New section "3.5 Enforcing the use of HIP in legacy applications" In general, legacy applications are expected to be HIP unaware. In practice, this means that the source code of the actual application remains unmodified. However, there might be cases when the use of HIP is being enforced by either very minimal changes to the application source code or to the underlying, dynamically loadable resolver libraries. The motivation for doing this is to force the application to establish connections using HIP, or to not to establish them at all [A]. When the application source code can be modified, AI_HIP flag can set to getaddrinfo() resolver call. This way, the application either gets LSIs/HITs or nothing at all. Alternatively, the resolver library can be configured to force the resolver to enforce system specific behaviour when the source code of the application cannot be modified. In this case, the resolver can return either LSIs/HITs or nothing at all. [A] Applying a cryptographic namespace to applications http://portal.acm.org/ft_gateway.cfm?id=1080786&type=pdf&coll=portal&dl=ACM&CFID=76024067&CFTOKEN=9663775 [B] http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt [C] http://www.ambient-networks.org/docs/Host_Identity_Indirection_Infrastructure_Hi3.pdf -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec-rg mailing list Hipsec-rg@listserv.cybertrust.com https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 17 14:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgRCR-0004OY-I7; Wed, 17 May 2006 14:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgRCQ-0004OT-24 for hipsec@ietf.org; Wed, 17 May 2006 14:56:46 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgRCM-0001kP-HD for hipsec@ietf.org; Wed, 17 May 2006 14:56:46 -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 NAA07301; Wed, 17 May 2006 13:56:31 -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 k4HIuVr09945; Wed, 17 May 2006 11:56:31 -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.1830); Wed, 17 May 2006 11:56:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft Date: Wed, 17 May 2006 11:56:25 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F20C@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft Thread-Index: AcZ5Nh7NOsaolsgrS0um2nf0cMp+cAAqBapQ From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 17 May 2006 18:56:26.0358 (UTC) FILETIME=[9953C960:01C679E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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: , Errors-To: hipsec-bounces@lists.ietf.org (posting only to hipsec) > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Tuesday, May 16, 2006 2:45 PM > To: hipsec@ietf.org > Cc: hipsec-rg@ietf.org > Subject: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft >=20 (snip) > but the draft is now an official WG item. Results of rechartering discussions have not been announced to the list, AFAIK. >=20 > Comments are welcome, as always. Thomas, feel free modify and=20 > adapt the > text to the draft. >=20 >=20 > 3.2. Using DNS >=20 > .. >=20 > New paragraph: "Return HIP HITs instead of IP addresses": >=20 > For legacy applications that are not hard coded using IPv4=20 > addresses, it > is also possible to return HITs in resolver calls. An advantage of > returning a HIT in comparison to returning an LSI is that a HIT is not > only a locally created identifier but rather has a global meaning. The > drawbacks are mostly related to referrals which are discussed=20 > in detail in > section <3.4>.=20 I think the best way to handle the above suggestion is to add HITs as an alternative to LSI in the existing paragraph and in this section in general. The advantage of using a HIT is that it may be resolvable or routable by a third-party (referral) HIP-aware system in some cases. =20 For that matter, IP addresses should also be mentioned as a candidate local scope identifier, especially ULIDs. > Additionally, the resolver implementation has=20 > to be careful > to return the HITs only when the application requests AF_ANY=20 > or AF_INET6 > type of addresses.=20 I'm not familiar with the AF_ANY family and doubt that many legacy apps use it presently. Do you mean AF_UNSPEC? > A HIP enabled resolver is expected to=20 > return first the > HITs and only after that a list of IPv6 addresses, unless the=20 > AI_HIP flag > is set, as descibed in more detail in section <3.5>. >=20 I am not sure about requiring this particular behavior (vs. just returning a HIT and no other IP addresses). =20 > Suggest adding new section 3.4: Referral issues I am not sure I want to go so deeply in the direction you are asking. I think that referrals are already adequately discussed, but perhaps could be enhanced by a reference to shim6 draft on referrals (you mentioned as [C] below)? Perhaps also mention in 3.3 that the use of HITs in referrals may be advantageous to LSIs in that HIP-aware hosts may be able to resolve them in a referral situation. >=20 > A referral is the case when three or more instances of an application > interacts and the first instance communicates with the second=20 > instance, > and then communicates with the third instances and wishes to tell the > third instance how to contact the second instance [B]. In order to > maximize backwards compatibility with legacy applications, it=20 > is important > to consider the type of referrals that applications use. However, > maximizing backwards compatibility may have some negative impacts that > need to be considered. In this section, we consider four types of > referrals: end-point identifiers (HITs), end-point locators=20 > (IP addresses) > and middlebox locators (rendezvous). >=20 > Using HITs as referrals may not work with legacy hosts that=20 > are not HIP > capable as the HITs are not routable. Having routable HITs requires > additional infrastructure, such as overlays [C].=20 It is not just routability, it is also possibly resolution (i.e., early- vs. late-binding of HIT to IP address). > In addition,=20 > resolving > HITs to IP addresses in HIP aware applications=20 If the application is HIP aware, why does it (vs. the stack) need to do resolution? Do HIP-aware apps in your view still use connect(AF_INET6)? >requires also extra > infrastructure such as DHTs because HITs contain no hierarchical > information, which is really required by DNS. A benefit of=20 > using HITs at > the application layer is that they have a longer expected=20 > lifetime than IP > addresses in mobile environments. However, there may be=20 > middleboxes, such > as NATs between the end-points. As a HIT denotes an end-point=20 > rather than > "middle-point", HITs might be more useful than locators with NATted > environments, especially when end-points are mobile and when both > communicating end-points are behind NATs. >=20 > On the other hand, the use of end-point IP addresses as=20 > referrals has the > quite the opposite benefits and drawbacks to HITs. One=20 > benefit of using > end-point IP addresses as referrals is that they are=20 > backwards compatible > even with legacy hosts that are not HIP capable. In addition,=20 > they do not > require any new infrastructure. As a drawback, the expected=20 > lifetime of IP > addresses in mobile environments is lower than HITs. Another=20 > drawback is > that it may be more difficult to disambiquite whether a given=20 > IP address > belongs to the end-point host or e.g. a NAT middle-box. >=20 > Using rendezvous IP addresses as referrals does not work with=20 > legacy hosts > that are not HIP capable. In addition, the rendezvous servers=20 > themselves > are required as an additional infrastructure. As a benefit,=20 > the expected > lifetime of this type of referrals is also longer than for end-point > addresses in mobile environments. As a second benefit, this=20 > case might be > useful for establishing opportunistic HIP connection between=20 > HIP capable > hosts assuming that the rendezvous server has a sufficient supply of > locators (one dedicated locator per one responder). When a single > rendezvous address is dedicated for a single responder, using=20 > rendezvous > addresses as referrals may be less ambigious than when using end-point > addresses, but more ambiguous than when using HITs. > As stated above, I am not sure I'd like to digress so much on the topic of referrals. =20 > New section "3.5 Enforcing the use of HIP in legacy applications" >=20 > In general, legacy applications are expected to be HIP unaware. In > practice, this means that the source code of the actual application > remains unmodified. However, there might be cases when the=20 > use of HIP is > being enforced by either very minimal changes to the=20 > application source > code or to the underlying, dynamically loadable resolver=20 > libraries. The > motivation for doing this is to force the application to establish > connections using HIP, or to not to establish them at all [A]. >=20 I think it is worthwhile to mention somewhere that a dynamically loaded HIP-aware resolver is one way to control the granularity of using HIP on a system; I will do so in the next revision. I don't think a new section is necessarily needed. > When the application source code can be modified, AI_HIP flag=20 > can set to > getaddrinfo() resolver call.=20 Modifying application code is out of scope for this draft. > This way, the application either gets > LSIs/HITs or nothing at all. Alternatively, the resolver=20 > library can be > configured to force the resolver to enforce system specific=20 > behaviour when > the source code of the application cannot be modified. In=20 > this case, the > resolver can return either LSIs/HITs or nothing at all. >=20 > [A] Applying a cryptographic namespace to applications > http://portal.acm.org/ft_gateway.cfm?id=3D1080786&type=3Dpdf&coll=3D > portal&dl=3DACM&CFID=3D76024067&CFTOKEN=3D9663775 > [B]=20 > http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt > [C]=20 > http://www.ambient-networks.org/docs/Host_Identity_Indirection _Infrastructure_Hi3.pdf >=20 Thanks, Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu May 18 06:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfIB-0007RA-85; Thu, 18 May 2006 05:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfIA-0007R5-0X for hipsec@ietf.org; Thu, 18 May 2006 05:59:38 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgfI7-0004LN-N1 for hipsec@ietf.org; Thu, 18 May 2006 05:59:37 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 149A632E4; Thu, 18 May 2006 12:59:35 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A459C32D5; Thu, 18 May 2006 12:59:34 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id k4I9xPaN014165; Thu, 18 May 2006 12:59:30 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Thu, 18 May 2006 12:59:25 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] HIP ESP draft In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F1F8@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2F1F8@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 16 May 2006, Henderson, Thomas R wrote: >> -----Original Message----- >> From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] >> Sent: Thursday, May 04, 2006 1:43 AM >> To: HIP >> Subject: [Hipsec] HIP ESP draft >> >> Folks, >> >> I made two modifications to the ESP draft based on the >> security analysis. >> >> >> - The ESP Sequence Number is now a 64-bit value >> >> o 3.3.6 Sequence Number section is modified >> o 5.1.2 ESP_TRANSFORM packet description is modified >> >> The ESP_TRANSFORM contains at the moment a 16-bit reserved field. >> It is possible now to start Suites immediately after the length >> field unless we want to keep the reserved field for some >> possible future >> versions of the protocol. > > Unless someone thinks of an anticipated need, I would suggest to remove > the reserved field here. After some offline discussion, I believe the reserved field is needed for further extensions. -- 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 May 18 08:16:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghPv-0004di-3t; Thu, 18 May 2006 08:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghPu-0004dd-7J for hipsec@ietf.org; Thu, 18 May 2006 08:15:46 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FghPs-0006Ui-U3 for hipsec@ietf.org; Thu, 18 May 2006 08:15:46 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 36D28212C5F; Thu, 18 May 2006 15:15:44 +0300 (EEST) Received: from [193.234.219.125] (n125.nomadiclab.com [193.234.219.125]) by n2.nomadiclab.com (Postfix) with ESMTP id C62A3212C5D; Thu, 18 May 2006 15:15:43 +0300 (EEST) Message-ID: <446C6566.1020900@nomadiclab.com> Date: Thu, 18 May 2006 15:15:34 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: HIP Subject: Re: [Hipsec] HIP Base draft References: <77F357662F8BFA4CA7074B0410171B6D01A2F1F1@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F1F1@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R wrote: > Responding now to the issues below. > Tom, thanks for the comments. I have made some changes to the base draft and new pre-version with date 180506 is available at http://hip4inter.net/drafts.php /Petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu May 18 08:50:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fghxb-0007ns-8A; Thu, 18 May 2006 08:50:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghxZ-0007nY-Sh for hipsec@ietf.org; Thu, 18 May 2006 08:50:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FghxZ-0007v0-RE for hipsec@ietf.org; Thu, 18 May 2006 08:50:33 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fghl1-0002Oq-Lp for hipsec@ietf.org; Thu, 18 May 2006 08:37:41 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5C35131AE; Thu, 18 May 2006 15:37:34 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id C671730BA; Thu, 18 May 2006 15:37:33 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id k4ICbSe8019438; Thu, 18 May 2006 15:37:33 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Thu, 18 May 2006 15:37:28 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F20C@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2F20C@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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: , Errors-To: hipsec-bounces@lists.ietf.org On Wed, 17 May 2006, Henderson, Thomas R wrote: >> Additionally, the resolver implementation has >> to be careful >> to return the HITs only when the application requests AF_ANY >> or AF_INET6 >> type of addresses. > > I'm not familiar with the AF_ANY family and doubt that many legacy apps > use it presently. Do you mean AF_UNSPEC? Yes. >> Suggest adding new section 3.4: Referral issues > > I am not sure I want to go so deeply in the direction you are asking. I > think that referrals are already adequately discussed, but perhaps could > be enhanced by a reference to shim6 draft on referrals (you mentioned as > [C] below)? > > Perhaps also mention in 3.3 that the use of HITs in referrals may be > advantageous to LSIs in that HIP-aware hosts may be able to resolve them > in a referral situation. Ok. >> In addition, resolving HITs to IP addresses in HIP aware applications > > If the application is HIP aware, why does it (vs. the stack) need to do > resolution? Do HIP-aware apps in your view still use connect(AF_INET6)? In addition, resolving HITs to IP addresses in HIP aware applications requires also extra infrastructure such as DHTs because HITs contain no hierarchical information, which is really required by DNS. -> In addition, resolving HIT referrals to to routable IP addresses requires also extra infrastructure such as DHTs because HITs contain no hierarchical information, which is really required by DNS. > As stated above, I am not sure I'd like to digress so much on the topic > of referrals. It is a concern especially in legacy applications based on HITs and non-routable LSIs because they have no idea how to deal with the non-routability issues. Basically, applications running into non-routable HIT or LSI referrals will just fail with mysterious error messages. At least I believe that the non-routable referrals are the main problem of the legacy API. The text I proposed just described the pros and cons, and does not make any strong recommendations. I though this is was requested by in the earlier email thread. >> New section "3.5 Enforcing the use of HIP in legacy applications" >> >> In general, legacy applications are expected to be HIP unaware. In >> practice, this means that the source code of the actual application >> remains unmodified. However, there might be cases when the >> use of HIP is >> being enforced by either very minimal changes to the >> application source >> code or to the underlying, dynamically loadable resolver >> libraries. The >> motivation for doing this is to force the application to establish >> connections using HIP, or to not to establish them at all [A]. > > I think it is worthwhile to mention somewhere that a dynamically loaded > HIP-aware resolver is one way to control the granularity of using HIP on > a system; I will do so in the next revision. I don't think a new > section is necessarily needed. Fine. > >> When the application source code can be modified, AI_HIP flag >> can set to >> getaddrinfo() resolver call. > > Modifying application code is out of scope for this draft. Fine. Cheers, -- 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 Fri May 19 03:00:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyyB-0006sy-Ul; Fri, 19 May 2006 03:00:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgyy9-0006m2-Kl for hipsec@ietf.org; Fri, 19 May 2006 03:00:17 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgyy9-0000M2-By for hipsec@ietf.org; Fri, 19 May 2006 03:00:17 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id CAA24777; Fri, 19 May 2006 02:00:02 -0500 (CDT) 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 k4J701G10002; Fri, 19 May 2006 02:00:01 -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.1830); Fri, 19 May 2006 00:00:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft Date: Fri, 19 May 2006 00:00:01 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F22C@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft Thread-Index: AcZ6d/rdqztbmUXXRxumT7vO2BvW/gAlufRQ From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 19 May 2006 07:00:01.0458 (UTC) FILETIME=[D9281120:01C67B11] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 >=20 > >> In addition, resolving HITs to IP addresses in HIP aware=20 > applications > > > > If the application is HIP aware, why does it (vs. the=20 > stack) need to do > > resolution? Do HIP-aware apps in your view still use=20 > connect(AF_INET6)? >=20 > In addition, resolving HITs to IP addresses in HIP aware applications=20 > requires also extra infrastructure such as DHTs because HITs=20 > contain no=20 > hierarchical information, which is really required by DNS. >=20 > -> >=20 > In addition, resolving HIT referrals to to routable IP=20 > addresses requires=20 > also extra infrastructure such as DHTs because HITs contain no=20 > hierarchical information, which is really required by DNS. >=20 > > As stated above, I am not sure I'd like to digress so much=20 > on the topic > > of referrals. >=20 > It is a concern especially in legacy applications based on HITs and=20 > non-routable LSIs because they have no idea how to deal with the=20 > non-routability issues. Basically, applications running into=20 > non-routable=20 > HIT or LSI referrals will just fail with mysterious error=20 > messages. At=20 > least I believe that the non-routable referrals are the main=20 > problem of=20 > the legacy API. >=20 > The text I proposed just described the pros and cons, and=20 > does not make=20 > any strong recommendations. I though this is was requested by in the=20 > earlier email thread. >=20 I think we may disagree on the emphasis required for this topic, and I guess I don't agree with everything implied in the text that you proposed about how it would all work (or at least the need to mention those things such as overlay routing, NATted environments, and rendezvous server addresses). The draft already says: Since the LSI or HIT is non-routable, a couple of potential hazards arise, in the case of referrals, callbacks, and long-lived application associations. First, applications that perform referrals may pass the LSI to another system that has no system context to resolve the LSI back to a host identity or an IP address. Note that these are the same type of applications that will likely break if used over certain types of NATs. I actually think that the odds of a referral occuring for HIP are lower than that of shim6 because shim6 uses delayed context establishment, while HIP requires the use case that a third party gets the HIT or LSI somehow while not using HIP (which is presumably in use by the first two parties). I think that application caching is bound to be a more prevalent problem. I also don't know how often the referral problem happens in practice; we haven't observed it when using LSIs, and the OCALA project (UC Berkeley project also using LSIs) has not reported such problems. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 19 08:36:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh4CY-0007yq-TN; Fri, 19 May 2006 08:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh4CX-0007yh-Ja for hipsec@ietf.org; Fri, 19 May 2006 08:35:29 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh4CU-0004CD-8M for hipsec@ietf.org; Fri, 19 May 2006 08:35:29 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7CA15313C; Fri, 19 May 2006 15:35:23 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id EED013133; Fri, 19 May 2006 15:35:22 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id k4JCZLGV023921; Fri, 19 May 2006 15:35:22 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Fri, 19 May 2006 15:35:21 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F22C@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2F22C@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 19 May 2006, Henderson, Thomas R wrote: >> It is a concern especially in legacy applications based on HITs and >> non-routable LSIs because they have no idea how to deal with the >> non-routability issues. Basically, applications running into >> non-routable HIT or LSI referrals will just fail with mysterious error >> messages. At least I believe that the non-routable referrals are the >> main problem of the legacy API. >> >> The text I proposed just described the pros and cons, and does not make >> any strong recommendations. I though this is was requested by in the >> earlier email thread. >> > I think we may disagree on the emphasis required for this topic, and I > guess I don't agree with everything implied in the text that you > proposed about how it would all work (or at least the need to mention > those things such as overlay routing, NATted environments, and > rendezvous server addresses). The draft already says: > > Since the LSI or HIT is non-routable, a couple of potential hazards > arise, in the case of referrals, callbacks, and long-lived > application associations. First, applications that perform referrals > may pass the LSI to another system that has no system context to > resolve the LSI back to a host identity or an IP address. Note that > these are the same type of applications that will likely break if > used over certain types of NATs. > > I actually think that the odds of a referral occuring for HIP are lower > than that of shim6 because shim6 uses delayed context establishment, > while HIP requires the use case that a third party gets the HIT or LSI > somehow while not using HIP (which is presumably in use by the first two > parties). I think that application caching is bound to be a more > prevalent problem. I also don't know how often the referral problem > happens in practice; we haven't observed it when using LSIs, and the > OCALA project (UC Berkeley project also using LSIs) has not reported > such problems. Ok, fine. -- 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 Mon May 22 06:23:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi7Z8-0007kP-QT; Mon, 22 May 2006 06:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhD3S-00082x-NN; Fri, 19 May 2006 18:02:42 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhD3O-0001U4-AR; Fri, 19 May 2006 18:02:42 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4JM2bB0026703; Fri, 19 May 2006 15:02:37 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4JM2bbv026702; Fri, 19 May 2006 15:02:37 -0700 Date: Fri, 19 May 2006 15:02:37 -0700 Message-Id: <200605192202.k4JM2bbv026702@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-Mailman-Approved-At: Mon, 22 May 2006 06:23:10 -0400 Cc: hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 4423 on Host Identity Protocol (HIP) Architecture X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4423 Title: Host Identity Protocol (HIP) Architecture Author: R. Moskowitz, P. Nikander Status: Informational Date: May 2006 Mailbox: rgm@icsalabs.com, pekka.nikander@nomadiclab.com Pages: 24 Characters: 61049 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-hip-arch-03.txt URL: http://www.rfc-editor.org/rfc/rfc4423.txt 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 (HIP), 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. This memo provides information for the Internet community. This document is a product of the Host Identity Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 22 07:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8vI-00088Z-Tm; Mon, 22 May 2006 07:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8vH-00088S-GV for hipsec@ietf.org; Mon, 22 May 2006 07:50:07 -0400 Received: from z9m9z.htt-consult.com ([65.84.78.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi8vC-00051q-Tv for hipsec@ietf.org; Mon, 22 May 2006 07:50:07 -0400 Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [127.0.0.1]) by z9m9z.htt-consult.com (8.13.1/8.13.1) with ESMTP id k4MBdX1P021284 for ; Mon, 22 May 2006 07:39:33 -0400 Received: from z9m9z.htt-consult.com (root@localhost) by z9m9z.htt-consult.com (8.13.1/8.13.1/Submit) with ESMTP id k4MBdVtM021283 for ; Mon, 22 May 2006 07:39:33 -0400 Received: from nc4010.htt-consult.com (209.78.84.65.client.htt-consult.com 65.84.78.209) by z9m9z.htt-consult.com (Scalix SMTP Relay 10.0.0.175) via ESMTP; Mon, 22 May 2006 07:39:31 -0400 (EDT) Date: Mon, 22 May 2006 07:48:12 -0400 From: "Robert Moskowitz" To: hipsec@ietf.org Message-ID: <7.0.1.0.2.20060522074643.04c2d5b0@htt-consult.com> In-Reply-To: <200605192202.k4JM2bbv026702@nit.isi.edu> References: <200605192202.k4JM2bbv026702@nit.isi.edu> Subject: Congrads - Re: [Hipsec] RFC 4423 on Host Identity Protocol (HIP) Architecture x-scalix-Hops: 1 X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org At 06:02 PM 5/19/2006, rfc-editor@rfc-editor.org wrote: >A new Request for Comments is now available in online RFC libraries. > > > RFC 4423 > > Title: Host Identity Protocol (HIP) Architecture > Author: R. Moskowitz, P. Nikander Congrads to all of you that have put in the effort to get HIP this far. Illegitimi non Carborundum _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec