From hipsec-bounces@lists.ietf.org Thu Jan 05 07:20:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuU6n-0005y0-Jn; Thu, 05 Jan 2006 07:20:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuU6l-0005xv-Id for hipsec@megatron.ietf.org; Thu, 05 Jan 2006 07:20:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05673 for ; Thu, 5 Jan 2006 07:19:27 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuUCO-0007zf-QE for hipsec@ietf.org; Thu, 05 Jan 2006 07:26:36 -0500 Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id BC869212C52; Thu, 5 Jan 2006 14:20:13 +0200 (EET) From: Jan Mikael Melen To: "HIP" , Julien Laganier , Lars Eggert Date: Thu, 5 Jan 2006 14:20:13 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601051420.15110.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Question about RVS_HMAC X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, The draft-ietf-hip-rvs-04 defines that one should add an RVS_HMAC after the FROM parameter when forwarding the I1, but if a node has multiple RVS servers how can the client determine the RVS server that created the RVS_HMAC? In the forwarded I1 packet there is nothing that would reveal the identity of the RVS server which forwarded the I1? Has anyone else implemented this kind of scenario and if yes how have you solved the problem? Are you searching the RVS using the source IP address of the packet (and how do you determine the IP address if the client is behind NAT)? Maybe I've just missed some important piece of information as I read the draft. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jan 09 10:33:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evz1z-0006Sl-5R; Mon, 09 Jan 2006 10:33:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evz1x-0006Sd-Iv for hipsec@megatron.ietf.org; Mon, 09 Jan 2006 10:33:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22138 for ; Mon, 9 Jan 2006 10:32:39 -0500 (EST) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evz8T-0008EQ-Qz for hipsec@ietf.org; Mon, 09 Jan 2006 10:40:42 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 9F1F22DC6; Mon, 9 Jan 2006 17:33:44 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.0-niksula20040914 (2005-09-13) on twilight.cs.hut.fi X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1B3112D92; Mon, 9 Jan 2006 17:33:44 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k09FXdl15493; Mon, 9 Jan 2006 17:33:39 +0200 (EET) Date: Mon, 9 Jan 2006 17:33:39 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jan Mikael Melen Subject: Re: [Hipsec] Question about RVS_HMAC In-Reply-To: <200601051420.15110.Jan.Melen@nomadiclab.com> Message-ID: References: <200601051420.15110.Jan.Melen@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Lars Eggert , HIP , Julien Laganier X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Thu, 5 Jan 2006, Jan Mikael Melen wrote: > The draft-ietf-hip-rvs-04 defines that one should add an RVS_HMAC after > the FROM parameter when forwarding the I1, but if a node has multiple > RVS servers how can the client determine the RVS server that created the > RVS_HMAC? > > In the forwarded I1 packet there is nothing that would reveal the > identity of the RVS server which forwarded the I1? Has anyone else > implemented this kind of scenario and if yes how have you solved the > problem? Are you searching the RVS using the source IP address of the > packet (and how do you determine the IP address if the client is behind > NAT)? > > Maybe I've just missed some important piece of information as I read the > draft. I think you are right. In current approach, only a single RVS has been considered. The responder needs to verify the HMAC in the I1 against all of the integrity keys of its rendezvous servers. Seems like the HIT of the RVS needs to be include in the I1 somehow. I had also some other thoughts when reading the draft: * Terminology: I think the term "client" should be always referred as the "rendezvous client" or just "responder". At least for me, it was slightly confusing that the rendezvous _client_ means responder (usually the "client" is assumed to be the initiator). Maybe preferring the word "responder" instead of "client" could clear out some of confusion (especially in the last two paragraphs of 4.3.2). * The HIT should be added also in the case of cascading rendezvous servers, not only parallel. (Slightly off-the topic: how do the cascades work with the DNS records?) * I don't know if it has been proposed already but could LOCATOR be embedded inside the FROM or VIA_RVS parameters. Or reused in another way to avoid redundancy? * There is a mismatch in the MAY/MUST statements of two sections: 4.3.2. For debugging purposes, it MAY include a subset of the IP addresses of its RVSs [i.e VIA_RVS parameters] in some of these packets. 4.3.3. When a responder replies to an I1 relayed via an RVS, it MUST append to the regular R1 header a VIA_RVS parameter containing the IP addresses of the traversed RVS's. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 10 08:44:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwJnT-0007G8-EB; Tue, 10 Jan 2006 08:44:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwJnR-0007G3-BZ for hipsec@megatron.ietf.org; Tue, 10 Jan 2006 08:44:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02850 for ; Tue, 10 Jan 2006 08:43:01 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwJu8-0001MZ-LO for hipsec@ietf.org; Tue, 10 Jan 2006 08:51:17 -0500 Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id 054DA212C52; Tue, 10 Jan 2006 15:43:54 +0200 (EET) From: Jan Mikael Melen To: Miika Komu Subject: Re: [Hipsec] Question about RVS_HMAC Date: Tue, 10 Jan 2006 15:44:09 +0200 User-Agent: KMail/1.8.2 References: <200601051420.15110.Jan.Melen@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: <200601101544.12392.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Lars Eggert , HIP , Julien Laganier X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, On Monday 09 January 2006 17:33, Miika Komu wrote: > > I think you are right. In current approach, only a single RVS has been > considered. The responder needs to verify the HMAC in the I1 against all > of the integrity keys of its rendezvous servers. Seems like the HIT of the > RVS needs to be include in the I1 somehow. Would be okay to include the whole HI of the rendezvous server then we wouldn't have to define a new TLV only new TLV type number for RVS_HI. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jan 16 05:57:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyS3c-0007cQ-F8; Mon, 16 Jan 2006 05:57:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyS3Z-0007cI-KS for hipsec@megatron.ietf.org; Mon, 16 Jan 2006 05:57:51 -0500 Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02798 for ; Mon, 16 Jan 2006 05:56:20 -0500 (EST) Received: from [192.168.1.105] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 43C501220055E867; Mon, 16 Jan 2006 11:57:13 +0100 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] Question about RVS_HMAC Date: Mon, 16 Jan 2006 11:56:54 +0100 User-Agent: KMail/1.8.2 References: <200601051420.15110.Jan.Melen@nomadiclab.com> In-Reply-To: <200601051420.15110.Jan.Melen@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601161156.55333.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: Lars Eggert , HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi Jan, On Thursday 05 January 2006 13:20, Jan Mikael Melen wrote: > Hi, > > The draft-ietf-hip-rvs-04 defines that one should add an RVS_HMAC > after the FROM parameter when forwarding the I1, but if a node has > multiple RVS servers how can the client determine the RVS server > that created the RVS_HMAC? > > In the forwarded I1 packet there is nothing that would reveal the > identity of the RVS server which forwarded the I1? Has anyone else > implemented this kind of scenario and if yes how have you solved > the problem? Are you searching the RVS using the source IP address > of the packet (and how do you determine the IP address if the > client is behind NAT)? I did not implement the RVS support, but the source IP address of the I1 can be used as an index to the right RVS registration and key. It seems that there's no issue if the client is behind a NAT because only the client IP address would be translated, not the RVS one. What does other people think? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jan 16 05:59:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyS4k-0007ot-Cz; Mon, 16 Jan 2006 05:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyS4i-0007oo-MV for hipsec@megatron.ietf.org; Mon, 16 Jan 2006 05:59:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02900 for ; Mon, 16 Jan 2006 05:57:36 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EySCN-00040C-QY for hipsec@ietf.org; Mon, 16 Jan 2006 06:07:11 -0500 Received: from [192.168.1.105] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 43C501220055E867; Mon, 16 Jan 2006 11:57:13 +0100 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] Question about RVS_HMAC Date: Mon, 16 Jan 2006 11:56:54 +0100 User-Agent: KMail/1.8.2 References: <200601051420.15110.Jan.Melen@nomadiclab.com> In-Reply-To: <200601051420.15110.Jan.Melen@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601161156.55333.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Lars Eggert , HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi Jan, On Thursday 05 January 2006 13:20, Jan Mikael Melen wrote: > Hi, > > The draft-ietf-hip-rvs-04 defines that one should add an RVS_HMAC > after the FROM parameter when forwarding the I1, but if a node has > multiple RVS servers how can the client determine the RVS server > that created the RVS_HMAC? > > In the forwarded I1 packet there is nothing that would reveal the > identity of the RVS server which forwarded the I1? Has anyone else > implemented this kind of scenario and if yes how have you solved > the problem? Are you searching the RVS using the source IP address > of the packet (and how do you determine the IP address if the > client is behind NAT)? I did not implement the RVS support, but the source IP address of the I1 can be used as an index to the right RVS registration and key. It seems that there's no issue if the client is behind a NAT because only the client IP address would be translated, not the RVS one. What does other people think? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jan 16 06:16:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySLs-0003dK-GZ; Mon, 16 Jan 2006 06:16:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySLq-0003dC-HD for hipsec@megatron.ietf.org; Mon, 16 Jan 2006 06:16:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04021 for ; Mon, 16 Jan 2006 06:15:18 -0500 (EST) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EySTj-0004V3-Uc for hipsec@ietf.org; Mon, 16 Jan 2006 06:24:53 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id EE5922EA9; Mon, 16 Jan 2006 13:16:28 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.0-niksula20040914 (2005-09-13) on twilight.cs.hut.fi X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 93A2C2E9E; Mon, 16 Jan 2006 13:16:28 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k0GBGQC14520; Mon, 16 Jan 2006 13:16:26 +0200 (EET) Date: Mon, 16 Jan 2006 13:16:25 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: [Hipsec] Question about RVS_HMAC In-Reply-To: <200601161156.55333.julien.IETF@laposte.net> Message-ID: References: <200601051420.15110.Jan.Melen@nomadiclab.com> <200601161156.55333.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Lars Eggert , HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Mon, 16 Jan 2006, Julien Laganier wrote: > Hi Jan, > > On Thursday 05 January 2006 13:20, Jan Mikael Melen wrote: > > Hi, > > > > The draft-ietf-hip-rvs-04 defines that one should add an RVS_HMAC > > after the FROM parameter when forwarding the I1, but if a node has > > multiple RVS servers how can the client determine the RVS server > > that created the RVS_HMAC? > > > > In the forwarded I1 packet there is nothing that would reveal the > > identity of the RVS server which forwarded the I1? Has anyone else > > implemented this kind of scenario and if yes how have you solved > > the problem? Are you searching the RVS using the source IP address > > of the packet (and how do you determine the IP address if the > > client is behind NAT)? > > I did not implement the RVS support, but the source IP address of the > I1 can be used as an index to the right RVS registration and key. It > seems that there's no issue if the client is behind a NAT because > only the client IP address would be translated, not the RVS one. > > What does other people think? Maybe we can later have also the server behind the NAT. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 17 04:31:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EynBx-0004OG-6m; Tue, 17 Jan 2006 04:31:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EynBu-0004OA-S7 for hipsec@megatron.ietf.org; Tue, 17 Jan 2006 04:31:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29758 for ; Tue, 17 Jan 2006 04:30:24 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EynJw-0006Ge-TR for hipsec@ietf.org; Tue, 17 Jan 2006 04:40:11 -0500 Received: from [192.168.1.251] (87.78.71.21) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 43C538AA005C1C27; Tue, 17 Jan 2006 10:30:43 +0100 From: Julien Laganier To: Miika Komu , HIP Subject: Re: [Hipsec] Question about RVS_HMAC Date: Tue, 17 Jan 2006 10:30:57 +0100 User-Agent: KMail/1.8.2 References: <200601051420.15110.Jan.Melen@nomadiclab.com> <200601161156.55333.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: <200601171030.57856.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Lars Eggert X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Monday 16 January 2006 12:16, Miika Komu wrote: > On Mon, 16 Jan 2006, Julien Laganier wrote: > > > > I did not implement the RVS support, but the source IP address of > > the I1 can be used as an index to the right RVS registration and > > key. It seems that there's no issue if the client is behind a NAT > > because only the client IP address would be translated, not the > > RVS one. > > > > What does other people think? > > Maybe we can later have also the server behind the NAT. Well, if the RVS is behind a NAT, a second RVS would be required in front of the NAT to make packet pass through the NAT up to the RVS behind it. In that case we would end up with two cascaded RVS, and this scenario was ruled out by the WG before -01 was issued. IMHO we should not try to add support for this scenario now, and rather publish the draft ASAP as an EXPERIMENTAL RFC, and start experimentation. If later on it appears that there is interest in supporting such scenarios, we can still revise the RFC. Other opinions? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 17 04:41:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EynLb-0006o0-Sx; Tue, 17 Jan 2006 04:41:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EynLZ-0006nu-Qn for hipsec@megatron.ietf.org; Tue, 17 Jan 2006 04:41:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00239 for ; Tue, 17 Jan 2006 04:40:25 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EynTf-0006ZB-2J for hipsec@ietf.org; Tue, 17 Jan 2006 04:50:12 -0500 Received: from 11.1.168.192.in-addr.arpa (xdsl-87-78-71-21.netcologne.de [87.78.71.21]) by kyoto.netlab.nec.de (Postfix) with ESMTP id BCB1C1BAC9E; Tue, 17 Jan 2006 10:41:35 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by 11.1.168.192.in-addr.arpa (Postfix) with ESMTP id 327AF6499A8; Tue, 17 Jan 2006 10:41:26 +0100 (CET) In-Reply-To: <200601171030.57856.julien.IETF@laposte.net> References: <200601051420.15110.Jan.Melen@nomadiclab.com> <200601161156.55333.julien.IETF@laposte.net> <200601171030.57856.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <8C8FD57C-CD75-4515-992E-32129D414FF4@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] Question about RVS_HMAC Date: Tue, 17 Jan 2006 10:41:20 +0100 To: Julien Laganier X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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: , Content-Type: multipart/mixed; boundary="===============1113869970==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============1113869970== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-269892899; protocol="application/pkcs7-signature" --Apple-Mail-13-269892899 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 17, 2006, at 10:30, Julien Laganier wrote: > IMHO we should not try to add support for this scenario now, and > rather publish the draft ASAP as an EXPERIMENTAL RFC, and start > experimentation. If later on it appears that there is interest in > supporting such scenarios, we can still revise the RFC. > > Other opinions? I agree with you. We're talking about corner cases here that the rest of HIP doesn't support now - why is it important *at this time* that this experimental extension support it? (I'm fine with putting a statement into the current version that says that we're aware of the issue, if people would like that.) Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-13-269892899 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTE3MDk0MTIyWjAjBgkqhkiG9w0BCQQxFgQUO+q5MJcfgHRrOQGmY71N DyMLnAgwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAJvgffyuHCL479/s0U0ki9CqQNv97K+f/oj5FhBnjS6LweLyhEIQSOOEmSC3tSA67Q6JjZ9K lWrF2b+zYNyD1F7RLG47KjuheiKCsHxNqfVR0UJGqv5/R/bFI8L/qTLBEarIZV530EEFcHLpS3mY JcbyPrJuSrgVkI8i+SJ1Qy1ZCKzAggNHAE98Fw0eSM9Oa8mwlM9H+FFMIUGbmcjvCTgXQmQAi3oQ QgB4KulTcqqdIed2IlcrO7AMhwvoI/0lXxjQGKerjNzFSAsovQycoVnL6siJ3NVvjA9tdux+jcgo dg9khnQ3LSJlRQALuqLVIdOBLv/HsD6kn1qESvO9KX0AAAAAAAA= --Apple-Mail-13-269892899-- --===============1113869970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1113869970==-- From hipsec-bounces@lists.ietf.org Tue Jan 17 05:34:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyoAa-0007WR-TV; Tue, 17 Jan 2006 05:34:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyoAZ-0007WM-Cf for hipsec@megatron.ietf.org; Tue, 17 Jan 2006 05:34:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03306 for ; Tue, 17 Jan 2006 05:33:07 -0500 (EST) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyoId-00008b-9h for hipsec@ietf.org; Tue, 17 Jan 2006 05:42:54 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A56F52EAA; Tue, 17 Jan 2006 12:34:18 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.0-niksula20040914 (2005-09-13) on twilight.cs.hut.fi X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 529E52D91; Tue, 17 Jan 2006 12:34:18 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k0HAYFk21903; Tue, 17 Jan 2006 12:34:15 +0200 (EET) Date: Tue, 17 Jan 2006 12:34:15 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Lars Eggert Subject: Re: [Hipsec] Question about RVS_HMAC In-Reply-To: <8C8FD57C-CD75-4515-992E-32129D414FF4@netlab.nec.de> Message-ID: References: <200601051420.15110.Jan.Melen@nomadiclab.com> <200601161156.55333.julien.IETF@laposte.net> <200601171030.57856.julien.IETF@laposte.net> <8C8FD57C-CD75-4515-992E-32129D414FF4@netlab.nec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: HIP , Julien Laganier X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Tue, 17 Jan 2006, Lars Eggert wrote: > On Jan 17, 2006, at 10:30, Julien Laganier wrote: > > IMHO we should not try to add support for this scenario now, and > > rather publish the draft ASAP as an EXPERIMENTAL RFC, and start > > experimentation. If later on it appears that there is interest in > > supporting such scenarios, we can still revise the RFC. > > > > Other opinions? > > I agree with you. We're talking about corner cases here that the rest > of HIP doesn't support now - why is it important *at this time* that > this experimental extension support it? > > (I'm fine with putting a statement into the current version that says > that we're aware of the issue, if people would like that.) Fine by me. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 17 11:27:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eytg5-0007r9-K6; Tue, 17 Jan 2006 11:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eytg2-0007pl-V6 for hipsec@megatron.ietf.org; Tue, 17 Jan 2006 11:27:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28423 for ; Tue, 17 Jan 2006 11:25:58 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyto8-0006N5-Bv for hipsec@ietf.org; Tue, 17 Jan 2006 11:35:48 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA03051 for ; Tue, 17 Jan 2006 10:26:59 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k0HGQxW01425 for ; Tue, 17 Jan 2006 08:26:59 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jan 2006 08:26:52 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jan 2006 08:26:52 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E910@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: proposed HIP base and ESP draft changes (UPDATE handling) Thread-Index: AcYbgtKizPauwdPmS32dT4h8IdUSGQ== From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 17 Jan 2006 16:26:52.0267 (UTC) FILETIME=[D2C82BB0:01C61B82] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hipsec] proposed HIP base and ESP draft changes (UPDATE handling) X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org In the course of working on the next version of the mobility draft, I reviewed the material regarding UPDATE message in the current base and ESP drafts and decided that it was underspecified. In particular, I found the following problems: i) the current draft allows for multiple UPDATE messages to be outstanding (unacknowledged), but doesn't say how such messages must be processed if they are received out of order (processed out of order, resequenced and processed in order, etc.). In fact, the current draft permits multiple UPDATEs to be sent, but the receiver processing text in Section 6.12.1 does not allow for any reordering in the network, and such handling is undefined. There were a few options discussed, including changing the UPDATE protocol to be more like go-back-N ARQ, or adding new selective "NACK" parameters or some new parameter that cancels an outstanding UPDATE if needed, but in the end, I opted to just clarify that it is the responsibility of the sender to only send multiple outstanding UPDATEs under the assumption that they may be processed in any arbitrary order-- if the ordering matters to the sender, then it needs to wait for an acknowledgement of the relevant UPDATE(s). If needed in the future, we can add a more sophisticated mechanism, but it doesn't seem necessary right now for the primary uses of UPDATE. ii) related to this, there was clarification added that the receiver may define a receive window for UPDATE sequence numbers, rejecting those that seem too far out of bounds based on the current value of the peer's Update ID. Likewise, it was clarified that circular sequence number processing was performed on the Update ID sequence space. iii) the draft was ambiguous as to the processing order if an UPDATE packet had both a SEQ and an ACK parameter. The proposed change is to specify that the ACK is first processed, then the new material in the UPDATE (SEQ plus whatever parameters are included). iv) finally, there were a few clarifications also added, and typos fixed. One minor technical point that affects interoperability is to change the first sent UPDATE to be numbered zero instead of one, according to the convention of positive integers in a circular sequence space starting with the number zero. Before taking this proposal to the list, I discussed these proposed changes with the draft authors and some implementors (Jan Melen, Miika Komu, Jeff Ahrenholz). I'm asking the list and the chairs whether these changes are acceptable. Tom p.s. it is my understanding that the base draft is still awaiting resolution of the KHI issue, and also revision of Appendix C. Base draft proposed changes: ---------------------------- i) Context diff against current base draft: http://hipserver.mct.phantomworks.org/ietf/drafts/draft-ietf-hip-base-04 .diff ii) Diff of whole document in HTML (generated by Petri): http://www.hip4inter.net/documentation/drafts/diff_04_05pre170106.html iii) Preview of -05:=20 http://www.hip4inter.net/documentation/drafts/draft-ietf-hip-base-05-pre 170106.txt iv) Preview of -05 (XML): http://www.hip4inter.net/documentation/drafts/draft-ietf-hip-base-05-pre 170106.xml ESP draft proposed changes: --------------------------- i) Context diff against current ESP draft: http://hipserver.mct.phantomworks.org/ietf/drafts/draft-ietf-hip-esp-01. diff ii) Diff of whole document in HTML (generated by Petri): http://www.hip4inter.net/documentation/drafts/diff_esp_01_02pre170106.ht ml iii) Preview of -02: http://www.hip4inter.net/documentation/drafts/draft-ietf-hip-esp-02-pre1 70106.txt iv) Preview of -02 (XML): http://www.hip4inter.net/documentation/drafts/draft-ietf-hip-esp-02-pre1 70106.xml _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jan 18 02:23:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez7en-0002hP-W3; Wed, 18 Jan 2006 02:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez7ek-0002gH-MW for hipsec@megatron.ietf.org; Wed, 18 Jan 2006 02:23:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12653 for ; Wed, 18 Jan 2006 02:21:32 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez7n0-0005ZI-OO for hipsec@ietf.org; Wed, 18 Jan 2006 02:31:32 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BAF65212C3D; Wed, 18 Jan 2006 09:22:27 +0200 (EET) Message-ID: <43CDECB6.7000906@nomadiclab.com> Date: Wed, 18 Jan 2006 09:22:30 +0200 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] proposed HIP base and ESP draft changes (UPDATE handling) References: <77F357662F8BFA4CA7074B0410171B6DC9E910@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E910@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R wrote: > Base draft proposed changes: > ---------------------------- > i) Context diff against current base draft: > http://hipserver.mct.phantomworks.org/ietf/drafts/draft-ietf-hip-base-04 > .diff > > ii) Diff of whole document in HTML (generated by Petri): > http://www.hip4inter.net/documentation/drafts/diff_04_05pre170106.html > > iii) Preview of -05: > http://www.hip4inter.net/documentation/drafts/draft-ietf-hip-base-05-pre > 170106.txt Note: Appendix C, Example Checksums for HIP packets The I1 packet is now fixed in C.1., but the C.3. is original and will be fixed before submission. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jan 19 05:15:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzWox-0006q1-RL; Thu, 19 Jan 2006 05:15:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzWov-0006pZ-N5 for hipsec@megatron.ietf.org; Thu, 19 Jan 2006 05:15:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08186 for ; Thu, 19 Jan 2006 05:13:41 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzWxL-0000wM-JY for hipsec@ietf.org; Thu, 19 Jan 2006 05:23:57 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E66AA212C59; Thu, 19 Jan 2006 12:14:36 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A3A62212C54; Thu, 19 Jan 2006 12:14:36 +0200 (EET) In-Reply-To: References: <200601051420.15110.Jan.Melen@nomadiclab.com> <200601161156.55333.julien.IETF@laposte.net> <200601171030.57856.julien.IETF@laposte.net> <8C8FD57C-CD75-4515-992E-32129D414FF4@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <72E43249-0DCB-4106-8787-A3F54C3529AE@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Question about RVS_HMAC Date: Thu, 19 Jan 2006 12:14:33 +0200 To: Lars Eggert , Miika Komu , Julien Laganier X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Jan 17, 2006, at 10:30, Julien Laganier wrote: >>> IMHO we should not try to add support for this scenario now, and >>> rather publish the draft ASAP as an EXPERIMENTAL RFC, and start >>> experimentation. If later on it appears that there is interest in >>> supporting such scenarios, we can still revise the RFC. >>> >>> Other opinions? On Tue, 17 Jan 2006, Lars Eggert wrote: >> I agree with you. We're talking about corner cases here that the rest >> of HIP doesn't support now - why is it important *at this time* that >> this experimental extension support it? >> >> (I'm fine with putting a statement into the current version that says >> that we're aware of the issue, if people would like that.) On Jan 17, 2006, at 12:34, Miika Komu wrote: > Fine by me. Works for me, too. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jan 19 05:22:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzWw2-0000ni-I2; Thu, 19 Jan 2006 05:22:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzWw1-0000mr-J4 for hipsec@megatron.ietf.org; Thu, 19 Jan 2006 05:22:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08882 for ; Thu, 19 Jan 2006 05:21:02 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzX4W-0001ET-J7 for hipsec@ietf.org; Thu, 19 Jan 2006 05:31:17 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 25C68212C59; Thu, 19 Jan 2006 12:22:19 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DBEE4212C54; Thu, 19 Jan 2006 12:22:18 +0200 (EET) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E910@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6DC9E910@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] proposed HIP base and ESP draft changes (UPDATE handling) Date: Thu, 19 Jan 2006 12:22:16 +0200 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Before taking this proposal to the list, I discussed these proposed > changes with the draft authors and some implementors (Jan Melen, Miika > Komu, Jeff Ahrenholz). I'm asking the list and the chairs whether > these > changes are acceptable. Thanks for this good work, Tom! > p.s. it is my understanding that the base draft is still awaiting > resolution of the KHI issue, and also revision of Appendix C. As far as I know, KHI is not currently making any progress. I ran (temporarily) out of steam, and it seems that no-one else has picked it up. I'll send private mail to the ADs and relevant WG chairs to see if we can make any progress. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 31 03:15:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3qg6-0007vz-Vn; Tue, 31 Jan 2006 03:15:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3qg6-0007vE-4F for hipsec@megatron.ietf.org; Tue, 31 Jan 2006 03:15:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23990 for ; Tue, 31 Jan 2006 03:13:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3qqV-0001PV-NO for hipsec@ietf.org; Tue, 31 Jan 2006 03:26:41 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by mx2.foretec.com with esmtp (Exim 4.24) id 1F3qo5-0002zY-9h for hipsec@ietf.org; Tue, 31 Jan 2006 03:24:09 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 791A3212C4C for ; Tue, 31 Jan 2006 10:09:46 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 31E53212C47 for ; Tue, 31 Jan 2006 10:09:46 +0200 (EET) Message-ID: <43DF1B4A.9080101@nomadiclab.com> Date: Tue, 31 Jan 2006 10:09:46 +0200 From: Petri Jokela User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Base draft, new pre-version X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, I uploaded a new pre-version of the base draft to hip4inter.net. "Appendix C. Example Checksums for HIP Packets" is now fixed. I just noticed that today is 31st and not 30th, but I'm not going to recompile those docs :-) Version: draft-ietf-hip-base-05-pre300106 http://hip4inter.net/drafts.php BR, Petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec