From ticsa-info-admin@honor.trusecure.com Tue Jun 1 05:55:25 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11083 for ; Tue, 1 Jun 2004 05:55:25 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D87A77326 for ; Tue, 1 Jun 2004 05:00:32 -0400 (EDT) Date: Tue, 01 Jun 2004 05:00:32 -0400 Message-ID: <20040601090032.5891.95433.Mailman@honor> Subject: honor.trusecure.com mailing list memberships reminder From: probertson@trusecure.com To: hip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: ticsa-info-admin@honor.trusecure.com Errors-To: ticsa-info-admin@honor.trusecure.com X-BeenThere: ticsa-info@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk This is a reminder, sent out once a month, about your honor.trusecure.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, hipsec-request@honor.trusecure.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to probertson@trusecure.com. Thanks! Passwords for hip-archive@lists.ietf.org: List Password // URL ---- -------- hipsec@honor.trusecure.com fewefo http://honor.trusecure.com/mailman/options/hipsec/hip-archive%40lists.ietf.org From hipsec-admin@honor.trusecure.com Tue Jun 1 09:46:56 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00554 for ; Tue, 1 Jun 2004 09:46:56 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 98A207315; Tue, 1 Jun 2004 08:52:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by honor.icsalabs.com (Postfix) with ESMTP id 89501730B for ; Tue, 1 Jun 2004 08:51:45 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-4.hut.fi (8.12.10/8.12.10) with ESMTP id i51Dk6iE005164 for ; Tue, 1 Jun 2004 16:46:07 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-4.hut.fi) Subject: [Hipsec] Some mm-02-pre1 comments Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 1 Jun 2004 16:46:06 +0300 (EEST) Date: Tue, 1 Jun 2004 16:46:06 +0300 (EEST) In section 7.1 "REA parameter" of draft mm-02-pre1, the description of P-bit value in the REA TLV does not clearly indicate that the P-bit value is to be interpreted as a truth value (one might hastily think that it is a fixed value). Similarly as in the base draft's section 6.2.13 NES the description of R-bit value: "One if the NES is a reply to another UPDATE, otherwise zero.". So, the description of P-bit could be changed to: "Preferred address. One if the first address in this REA is the new preferred address, otherwise zero." Assuming that I understood right that the P-bit is a truth value, I noticed some issues in the mm-02-pre1. Looks like some sections implicitly assume that at least some REA TLV in the received packet contains always P-bit with value of 1. For example, section 6.1 "Initiating the protocol in UPDATE" says that "The Peer host replies to this with a reply UPDATE packet, sent to the new preferred address". The error here is that which address should we choose if the P-bit is not set in the REA in the received initial UPDATE packet ? The one we got during the base exchange (but that's not a "new" address) ? Same assumption is found in section 6.2. Another note: what should we do if there are multiple REA TLVs in the packet and there are more than one set P-bit ? Drop the packet as erroneous ? Third note: section 8.2 "Handling received REAs" bullet point 2 says: "For each address listed in the REA parameter, check that the address is a legal unicast or anycast address. That is, the addres MUST NOT be a broadcast or multicast address." There are no more comments on what to do if there are these erroneous addresses in the REA. For example, whether to drop the packet or not. Maybe in the same bullet point there should also read "If the REA parameter contains broadcast or multicast addresses, these addresses MUST be ignored". Packet processing can be continued anyway, because this does not seem to be a fatal situation. Then there is a typo "addres" in the same bullet point. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 1 17:10:55 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24969 for ; Tue, 1 Jun 2004 17:10:54 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 3714D7336; Tue, 1 Jun 2004 16:16:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by honor.icsalabs.com (Postfix) with ESMTP id 0371E7308 for ; Tue, 1 Jun 2004 16:15:53 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i51LAELc005802 for ; Tue, 1 Jun 2004 16:10:14 -0500 (CDT) Received: from ericsson.com (rvi2-92-135.sw.ericsson.se [153.88.92.135]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB8FPCQ; Tue, 1 Jun 2004 16:09:56 -0500 Message-ID: <40BCF0B5.6080504@ericsson.com> X-Sybari-Trust: ac1dfd7d 08d63d2e 74a7d05a 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Charter page Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 02 Jun 2004 00:10:13 +0300 Date: Wed, 02 Jun 2004 00:10:13 +0300 Content-Transfer-Encoding: 7bit Folks, FYI: the official charter page at www.ietf.org has now a link to our supplemental web page. http://www.ietf.org/html.charters/hip-charter.html This will help newcomers figure out what is going on in the WG more easily. Regards, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 2 23:33:08 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15901 for ; Wed, 2 Jun 2004 23:33:08 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B8EA172E6; Wed, 2 Jun 2004 22:38:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id CD04072E2 for ; Wed, 2 Jun 2004 22:37:27 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id UAA18322; Wed, 2 Jun 2004 20:31:57 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i533Vuj18229; Wed, 2 Jun 2004 20:31:57 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 2 Jun 2004 20:31:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Some mm-02-pre1 comments Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060698@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Some mm-02-pre1 comments Thread-Index: AcRH3tdwGNu1KOyDTE6IHU+6qFmOqwBOfpxA From: "Henderson, Thomas R" To: "Mika Kousa" , X-OriginalArrivalTime: 03 Jun 2004 03:31:56.0358 (UTC) FILETIME=[5219BE60:01C4491B] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 2 Jun 2004 20:31:55 -0700 Date: Wed, 2 Jun 2004 20:31:55 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi] > Sent: Tuesday, June 01, 2004 6:46 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Some mm-02-pre1 comments >=20 >=20 > In section 7.1 "REA parameter" of draft mm-02-pre1, the description of > P-bit value in the REA TLV does not clearly indicate that the=20 > P-bit value > is to be interpreted as a truth value (one might hastily=20 > think that it is > a fixed value).=20 Agreed, this needs to be fixed. > Similarly as in the base draft's section=20 > 6.2.13 NES the > description of R-bit value: "One if the NES is a reply to=20 > another UPDATE, > otherwise zero.". This may be no longer relevant in the next draft. > Assuming that I understood right that the P-bit is a truth value, I > noticed some issues in the mm-02-pre1. Looks like some=20 > sections implicitly > assume that at least some REA TLV in the received packet=20 > contains always > P-bit with value of 1. For example, section 6.1 "Initiating=20 > the protocol > in UPDATE" says that "The Peer host replies to this with a=20 > reply UPDATE > packet, sent to the new preferred address". The error here is=20 > that which > address should we choose if the P-bit is not set in the REA in the > received initial UPDATE packet ? The one we got during the=20 > base exchange > (but that's not a "new" address) ? Same assumption is found in section > 6.2. Agreed, this could be reworded "the preferred address" in case the preferred address is not new. And base exchange address could be first preferred address. >=20 >=20 > Another note: what should we do if there are multiple REA TLVs in the > packet and there are more than one set P-bit ? Drop the packet as > erroneous ? > This might be candidate for NOTIFY. Or else each processed REA (processed in order) could overwrite the preferred address. >=20 > Third note: section 8.2 "Handling received REAs" bullet point=20 > 2 says: "For > each address listed in the REA parameter, check that the address is a > legal unicast or anycast address. That is, the addres MUST NOT be a > broadcast or multicast address." There are no more comments=20 > on what to do > if there are these erroneous addresses in the REA. For=20 > example, whether to > drop the packet or not. Maybe in the same bullet point there=20 > should also > read "If the REA parameter contains broadcast or multicast addresses, > these addresses MUST be ignored". Packet processing can be continued > anyway, because this does not seem to be a fatal situation. >=20 >=20 > Then there is a typo "addres" in the same bullet point. these points are noted-- thanks. Tom =20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jun 4 18:03:17 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18722 for ; Fri, 4 Jun 2004 18:03:17 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 442EC731A; Fri, 4 Jun 2004 17:08:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by honor.icsalabs.com (Postfix) with ESMTP id 50D0172E8 for ; Fri, 4 Jun 2004 17:07:46 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i54M2SNf009443 for ; Fri, 4 Jun 2004 15:02:29 -0700 (PDT) Received: from blixten (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i54M2QQ15711; Sat, 5 Jun 2004 00:02:26 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark To: hipsec@honor.trusecure.com Cc: erik.nordmark@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [Hipsec] Recovery from state loss Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 4 Jun 2004 15:02:23 -0700 (PDT) Date: Fri, 4 Jun 2004 15:02:23 -0700 (PDT) I'm reading the HIP spec (hip-09.txt) and I'm trying to figure out the assumptions underlying the recovery from state loss (using the birthday stuff). The document talks about this being used when one host has crashed and lost all state. But won't hosts end up discarding the ESP SA after some time of non-use? In fact, section 11 seems to recommend that the ESP SA be discarded after 15 minutes. Since both ends don't seem to not coordinate discarding this state, does it mean that the birthday counter need to be incremented each time an SA is discarded? Erik _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun Jun 6 20:15:32 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27304 for ; Sun, 6 Jun 2004 20:15:32 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 167D572EA; Sun, 6 Jun 2004 19:20:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id AB68672E2 for ; Sun, 6 Jun 2004 19:19:54 -0400 (EDT) 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 TAA26050; Sun, 6 Jun 2004 19:14:49 -0500 (CDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i570En002512; Sun, 6 Jun 2004 19:14:49 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Sun, 6 Jun 2004 17:14:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Recovery from state loss Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040606A5@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Recovery from state loss Thread-Index: AcRKf7ikAXlbIe1+QdCn8pYFeEGGrgBooHWw From: "Henderson, Thomas R" To: "Erik Nordmark" Cc: X-OriginalArrivalTime: 07 Jun 2004 00:14:48.0640 (UTC) FILETIME=[71E23400:01C44C24] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 6 Jun 2004 17:14:48 -0700 Date: Sun, 6 Jun 2004 17:14:48 -0700 Content-Transfer-Encoding: quoted-printable Erik, responses inline below. > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]=20 > Sent: Friday, June 04, 2004 3:02 PM > To: hipsec@honor.trusecure.com > Cc: erik.nordmark@sun.com > Subject: [Hipsec] Recovery from state loss >=20 >=20 >=20 > I'm reading the HIP spec (hip-09.txt) and I'm trying to figure out=20 > the assumptions underlying the recovery from state loss=20 > (using the birthday=20 > stuff). The birthday text has changed since -09 draft. Please see section 4.1.3 of the latest working copy: http://hip4inter.net/documentation/drafts/draft-moskowitz-hip-10-pre3.txt= In particular, there is now a "R1 generation counter" instead of=20 a birthday count. The thread of this discussion can be found starting=20 here: http://honor.trusecure.com/pipermail/hipsec/2004-April/000704.html and continuing through May. >=20 > The document talks about this being used when one host has crashed > and lost all state. > But won't hosts end up discarding the ESP SA after some time of > non-use? > In fact, section 11 seems to recommend that the ESP SA be=20 > discarded after > 15 minutes. I believe that is the case, but I think the motivation for the reboot procedures was to avoid having to wait for things to time out. I do not know the origin of the recommended 15 minutes. =20 > Since both ends don't seem to not coordinate discarding this=20 > state, does > it mean that the birthday counter need to be incremented each time > an SA is discarded? >=20 Previously, this was the implication, when birthday count was in use. =20 Presently, the way that it should work is as follows: suppose=20 host A and B have an association and B reboots. B starts up some application that wants again to have a HIP association with A. B will send A the I1 packet, and will receive an R1 (A will send R1 even when it is in ESTABLISHED state). B will then send an I2. Now A, in state ESTABLISHED, will process a I2 and if successful, will drop the existing SAs that it thinks it has with B in favor of the new ones. Both sides will then be back in sync after A sends the R2. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 7 02:04:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15954 for ; Mon, 7 Jun 2004 02:04:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6FC5872EA; Mon, 7 Jun 2004 01:09:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id 724EF72E2 for ; Mon, 7 Jun 2004 01:08:09 -0400 (EDT) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id BFACE8; Mon, 7 Jun 2004 09:03:05 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040606A5@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040606A5@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <590731D8-B848-11D8-9C1B-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: , "Erik Nordmark" From: Pekka Nikander Subject: Re: [Hipsec] Recovery from state loss To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 7 Jun 2004 09:03:07 +0300 Date: Mon, 7 Jun 2004 09:03:07 +0300 Content-Transfer-Encoding: 7bit >> But won't hosts end up discarding the ESP SA after some time of >> non-use? In fact, section 11 seems to recommend that the >> ESP SA be discarded after 15 minutes. > > I believe that is the case, but I think the motivation for the > reboot procedures was to avoid having to wait for things to time > out. I do not know the origin of the recommended 15 minutes. The 15 minutes recommendation was there when I inherited the documents from Bob M. I don't know its origin, either. As a (perhaps-educated) guess, I think that it is more or less arbitrary, based on no real analysis. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 7 02:23:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25372 for ; Mon, 7 Jun 2004 02:23:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id BF84872F2; Mon, 7 Jun 2004 01:28:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 0941172E2 for ; Mon, 7 Jun 2004 01:27:38 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i576KpMf021594; Mon, 7 Jun 2004 00:20:52 -0600 (MDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i576MUQ05766; Mon, 7 Jun 2004 08:22:30 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [Hipsec] Recovery from state loss To: "Henderson, Thomas R" Cc: Erik Nordmark , hipsec@honor.trusecure.com In-Reply-To: "Your message with ID" <6938661A6EDA8A4EA8D1419BCE46F24C040606A5@xch-nw-27.nw.nos.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 6 Jun 2004 23:22:27 -0700 (PDT) Date: Sun, 6 Jun 2004 23:22:27 -0700 (PDT) > The birthday text has changed since -09 draft. Please see section 4.1.3 > of the latest working copy: > http://hip4inter.net/documentation/drafts/draft-moskowitz-hip-10-pre3.txt > > In particular, there is now a "R1 generation counter" instead of > a birthday count. The thread of this discussion can be found starting > here: > http://honor.trusecure.com/pipermail/hipsec/2004-April/000704.html > and continuing through May. Thanks for the pointers. But I'm still concerned. The above email makes this assumption, which I don't see discussed in the archive: Case iii) Data will be sent on an SPI that will be unknown to the peer. In this case, either the peer will drop it silently or send the HIP NOTIFY-- in either case, the local host will eventually kill off its local HIP state, start over, and we are back to case i). Given that either end can (per section 8.9) drop a HIP association whenever it wants, isn't it likely that case iii (and case ii as well, but that one is resolved in a more predictable manner) happen quite frequently? I haven't found anything in the document that describes what makes the local host eventually kill off its local HIP state (it is just happily sending ESP packets; perhaps receiving some ICMP parameter problem) hence it has no HIP timer running. So what limits how long time case iii) stays around? Is the intent that the document actually recommend some behavior when receiving ICMP pameter problem pointing at the SPI field? An alternative would be to try to coordinate when the two peers drop their HIP association state somehow. Erik _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 7 02:38:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26171 for ; Mon, 7 Jun 2004 02:38:30 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 3A0A572F4; Mon, 7 Jun 2004 01:43:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id 889C072E2 for ; Mon, 7 Jun 2004 01:42:20 -0400 (EDT) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 6F5098; Mon, 7 Jun 2004 09:37:19 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20DC2BAB-B84D-11D8-9C1B-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Henderson, Thomas R" , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Recovery from state loss To: Erik Nordmark X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 7 Jun 2004 09:37:21 +0300 Date: Mon, 7 Jun 2004 09:37:21 +0300 Content-Transfer-Encoding: 7bit > Thanks for the pointers. But I'm still concerned. The above > email makes this assumption, which I don't see discussed in the > archive: > Case iii) > Data will be sent on an SPI that will be unknown > to the peer. In this case, either the peer will > drop it silently or send the HIP NOTIFY-- in either > case, the local host will eventually kill off its > local HIP state, start over, and we are back to > case i). > > Given that either end can (per section 8.9) drop a HIP association > whenever it wants, isn't it likely that case iii (and case ii as well, > but that one is resolved in a more predictable manner) happen quite > frequently? There was some discussion that in iii) the recipient should send an ICMP Parameter Problem, the Pointer pointing to the SPI value. I don't know if this ended up in the actual text; I vaguely remember that I prepared a write up, but maybe I forgot to send it. (Apparently it did, based on what you write below. My memory is just failing these days.) > I haven't found anything in the document that describes what makes the > local > host eventually kill off its local HIP state (it is just happily > sending ESP > packets; perhaps receiving some ICMP parameter problem) hence it has > no HIP > timer running. Yes, this is probably missing. > So what limits how long time case iii) stays around? I think some text should be added on how to react to received ICMP Parameter Problem messages. Unfortunately I don't have time to write up anything now. > Is the intent that the document actually recommend some behavior > when receiving ICMP pameter problem pointing at the SPI field? Yes, that was my intention, but apparently I failed to do so. Anyone, please? A reasonable thing would be to start establishing a new HIP assoc, by sending I1, but _not_ to drop the existing SAs yet. Maybe rate limit them or something, but not drop, as the ICMP Parameter Problem may be forged. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 7 04:04:30 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00089 for ; Mon, 7 Jun 2004 04:04:30 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 594A272EA; Mon, 7 Jun 2004 03:09:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id EBAE272E2 for ; Mon, 7 Jun 2004 03:08:04 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id 885EC212FEE for ; Mon, 7 Jun 2004 11:03:01 +0300 (EEST) Message-ID: <40C42005.90403@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Base draft: 10-pre4 version available Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 07 Jun 2004 10:57:57 +0300 Date: Mon, 07 Jun 2004 10:57:57 +0300 Content-Transfer-Encoding: 7bit The pre4 version of the HIP base draft is now available at: http://hip4inter.net/drafts.php Changes from pre3-version relate to update/rekeying based on Tom's contribution. /petri _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 7 04:13:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00529 for ; Mon, 7 Jun 2004 04:13:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B586072F3; Mon, 7 Jun 2004 03:18:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from ftp.ccrle.nec.de (ftp.netlab.nec.de [195.37.70.21]) by honor.icsalabs.com (Postfix) with ESMTP id 430B972E2 for ; Mon, 7 Jun 2004 03:17:10 -0400 (EDT) Received: from [212.17.149.136] (unknown [212.17.149.136]) by ftp.ccrle.nec.de (Postfix) with ESMTP id C5196F674; Mon, 7 Jun 2004 10:17:18 +0200 (CEST) Message-ID: <40C4234C.5040800@netlab.nec.de> From: Lars Eggert Organization: NEC Network Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier Cc: hipsec@honor.trusecure.com, Gonzalo Camarillo , David Ward , "Pekka Nikander (JO/LMF)" , "Petri Jokela (JO/LMF)" Subject: Re: [Hipsec] Milestone status References: <407E5FA9.8020702@ericsson.com> <200405141337.18522.julien.laganier@sun.com> In-Reply-To: <200405141337.18522.julien.laganier@sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030108010807020309070808" Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 07 Jun 2004 10:11:56 +0200 Date: Mon, 07 Jun 2004 10:11:56 +0200 This is a cryptographically signed message in MIME format. --------------ms030108010807020309070808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Julien Laganier wrote: > > A pre-version of the rendezvous draft is (finally ;) available at: > > > > > We would greatly appreciate any comments related to that draft. I have not seen any discussion on this on the list yet. We'd really like to receive some initial feedback before the cutoff for San Diego. Lars -- Lars Eggert NEC Network Laboratories --------------ms030108010807020309070808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwxgMjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI1MDkzMzI1WhcNMDUwNTI1MDkzMzI1 WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOZzwtMq7PdeyIu/+Y0supueRB5zrYv3wbuEIhJqWdQegir1A/sM73oOkARiBoJP li4uVUxjvjCwmH6eRn5B3hszqmgIW0xTqk2NdHib5mwqiyxak7A5gOHIgZL1mD6WnkQOVsKk 6So06ByTWVt32O6CL6xu10+Z+J1qS7wKjJdyiftXZGIOt14rItxxTBwLTZQqcYs5T18xaISe T174hzikrH5JrdkdURj4JuBoZOXf50auOKzwCuRc9V7JLUollqCuDILlcBXr3rkg6hcLjpfw 2QqZqiHGLZ2U9fPiHOEp9+6W8sFpjZnP4rMUlw7EX9XfzWtXxu7R5mGHPwAbGfECAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIp1bjSXy5QewXYYfLk0 2yVNpYvXutNp3Tpk58FiDuImzGqlY7G28u8HTc22xMD3cw4Rd6AAK+7TUywmlqkqnjCH/j6z tLu8AC4bOPxkiO2UFmYt9nnoxSgXA0XoUB2q4wzUUStA5V0NEaSbNyA2FrUF4hBrUZ7qEtry KV2TRNSCMIIDLjCCApegAwIBAgIDDGAyMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA1MjUwOTMzMjVaFw0wNTA1 MjUwOTMzMjVaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA5nPC0yrs917Ii7/5jSy6m55EHnOti/fBu4QiEmpZ1B6CKvUD+wzv eg6QBGIGgk+WLi5VTGO+MLCYfp5GfkHeGzOqaAhbTFOqTY10eJvmbCqLLFqTsDmA4ciBkvWY PpaeRA5WwqTpKjToHJNZW3fY7oIvrG7XT5n4nWpLvAqMl3KJ+1dkYg63Xisi3HFMHAtNlCpx izlPXzFohJ5PXviHOKSsfkmt2R1RGPgm4Ghk5d/nRq44rPAK5Fz1XsktSiWWoK4MguVwFeve uSDqFwuOl/DZCpmqIcYtnZT18+Ic4Sn37pbywWmNmc/isxSXDsRf1d/Na1fG7tHmYYc/ABsZ 8QIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAinVuNJfL lB7Bdhh8uTTbJU2li9e602ndOmTnwWIO4ibMaqVjsbby7wdNzbbEwPdzDhF3oAAr7tNTLCaW qSqeMIf+PrO0u7wALhs4/GSI7ZQWZi32eejFKBcDRehQHarjDNRRK0DlXQ0RpJs3IDYWtQXi EGtRnuoS2vIpXZNE1IIwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxgMjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDA2MDcwODExNTZaMCMGCSqGSIb3DQEJBDEWBBQ7Xt050ujW/O8C83j6noNqdS4TyzBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDGAyMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxg MjANBgkqhkiG9w0BAQEFAASCAQCrG3Eb9hWUtkqLOol7i0ZMprtlS4cDZc9VzrMutLyDUBXv LOYhPU8RqLX91jTm3NyHrvRsDuzQJCn3giZDhPettgaAg69EsnbfIdQ3ZQwnrLJdaSaZA3YV lFudIhGyMO/QGT32OvJsEjHb5isJc8R/rRbpcgnN6V+17HyL5zY8f80LatdrKRREmr8nm0wZ LBFs+bdb65eRlr76SbrWuBdUbKzdFmM3webXBEmuzqrYAuiSbvuR95zx/dhLxzSvxefujRgk y3aBraJp49cJOYdr4xDPCBDweYZuTQPTyx26irLc1XWXe+U7vIGbqjfSMGcuhTUHuWnUFcc3 LUDFutRxAAAAAAAA --------------ms030108010807020309070808-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 7 05:26:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03505 for ; Mon, 7 Jun 2004 05:26:30 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8F36C72F9; Mon, 7 Jun 2004 04:31:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id E398B72F3 for ; Mon, 7 Jun 2004 04:30:05 -0400 (EDT) Received: from iki.fi (fortytwo.hiit.fi [212.68.5.83]) by pegasus.hiit.fi (Postfix) with ESMTP id 7F49D220003 for ; Mon, 7 Jun 2004 12:25:03 +0300 (EEST) Message-ID: <40C4346F.3010900@iki.fi> From: Kristian Slavov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 Debian/1.6-1.he-1 X-Accept-Language: en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Milestone status References: <407E5FA9.8020702@ericsson.com> <200405141337.18522.julien.laganier@sun.com> <40C4234C.5040800@netlab.nec.de> In-Reply-To: <40C4234C.5040800@netlab.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 07 Jun 2004 12:25:03 +0300 Date: Mon, 07 Jun 2004 12:25:03 +0300 Content-Transfer-Encoding: 7bit Lars Eggert wrote: > Hi, > >> >> A pre-version of the rendezvous draft is (finally ;) available at: >> >> >> >> >> > > I have not seen any discussion on this on the list yet. We'd really like > to receive some initial feedback before the cutoff for San Diego. My plan is to implement few of the mentioned rendezvous mechanisms before the IETF meeting. I will try to give some feedback as the work progresses. The other HUT/HIIT hippies could probably do a private demo at the meeting (I will not attend). Question: Section 7.4: Assuming that the Responder will not create state before receiving I2, then why the Initiator sends the EREP1 and EREP2 in I2? The respnoder has no means to verify that the response matches the request. The only entity that can verify the responses is the RVS, but it is not contacted anymore. -- Kristian Slavov, Researcher Helsinki Institute for Information Technology Gsm: +358-40-7220960 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 7 05:54:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04651 for ; Mon, 7 Jun 2004 05:54:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5969F7302; Mon, 7 Jun 2004 04:59:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id D79C972F3 for ; Mon, 7 Jun 2004 04:58:36 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i579ptMf024099 for ; Mon, 7 Jun 2004 03:51:56 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HYX000DBNHCZM@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 07 Jun 2004 03:53:36 -0600 (MDT) Received: from [192.168.1.230] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HYX0086ZNHA4E@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 07 Jun 2004 03:53:36 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Milestone status In-reply-to: <40C4346F.3010900@iki.fi> To: hipsec@honor.trusecure.com Cc: Kristian Slavov , Lars Eggert Message-id: <200406071153.41593.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <407E5FA9.8020702@ericsson.com> <40C4234C.5040800@netlab.nec.de> <40C4346F.3010900@iki.fi> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 07 Jun 2004 11:53:41 +0200 Date: Mon, 07 Jun 2004 11:53:41 +0200 Content-Transfer-Encoding: 7BIT On Monday 07 June 2004 11:25, Kristian Slavov wrote: > > Question: > Section 7.4: Assuming that the Responder will not create state > before receiving I2, then why the Initiator sends the EREP1 and > EREP2 in I2? > > The respnoder has no means to verify that the response > matches the request. The only entity that can verify the responses > is the RVS, but it is not contacted anymore. Hi Kristian, When the initiator gets an R1 w/ EREQ, it answers blindly with an I2 w/EREP, because there's no way by which an initiator can distinguish between EREQ added by a Responder or a RVS. If this EREQ was added by the Responder, then this responder will get the corresponding subsequent EREP validating I2; it's fine.... If this EREQ was added by the RVS and the I2 doesn't pass via the RVS, then this EREP is useless, but the Initiator doesn't know that.... Hope I'm answering the good question ;) --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 7 11:10:36 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22605 for ; Mon, 7 Jun 2004 11:10:35 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 3C59B72F3; Mon, 7 Jun 2004 10:15:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id D994572E8 for ; Mon, 7 Jun 2004 10:14:43 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA12655; Mon, 7 Jun 2004 08:09:32 -0700 (PDT) Received: from xch-nw-23p.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i57F9Wj13537; Mon, 7 Jun 2004 08:09:32 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nw-23p.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Jun 2004 08:09:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Recovery from state loss Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040606A9@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Recovery from state loss Thread-Index: AcRMWeNk5lBqjwhqQBGpDi9nvbma9AARYRzA From: "Henderson, Thomas R" To: "Pekka Nikander" , "Erik Nordmark" Cc: X-OriginalArrivalTime: 07 Jun 2004 15:09:30.0120 (UTC) FILETIME=[6E8A0080:01C44CA1] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 7 Jun 2004 08:09:29 -0700 Date: Mon, 7 Jun 2004 08:09:29 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Sunday, June 06, 2004 11:37 PM > To: Erik Nordmark > Cc: Henderson, Thomas R; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Recovery from state loss >=20 >=20 > > Thanks for the pointers. But I'm still concerned. The above > > email makes this assumption, which I don't see discussed in the=20 > > archive: > > Case iii) > > Data will be sent on an SPI that will be unknown > > to the peer. In this case, either the peer will > > drop it silently or send the HIP NOTIFY-- in either > > case, the local host will eventually kill off its > > local HIP state, start over, and we are back to > > case i). > > > > Given that either end can (per section 8.9) drop a HIP association > > whenever it wants, isn't it likely that case iii (and case=20 > ii as well, > > but that one is resolved in a more predictable manner) happen quite=20 > > frequently? >=20 > There was some discussion that in iii) the recipient should > send an ICMP Parameter Problem, the Pointer pointing to the > SPI value. I don't know if this ended up in the actual > text; I vaguely remember that I prepared a write up, but > maybe I forgot to send it. (Apparently it did, based on > what you write below. My memory is just failing these days.) Here is the text that is in the current draft that Petri sent around this morning (from Section 5.3). If a system receives an ESP packet for an unknown SPI, it is possible that it has lost the state and its peer has not. It MAY send an ICMP packet with the Parameter Problem type, the Pointer pointing to the SPI value within the ESP header. Reacting to ESP traffic with unknown SPI depends on the implementation and the environment where the implementation is used. >=20 > > I haven't found anything in the document that describes=20 > what makes the=20 > > local > > host eventually kill off its local HIP state (it is just happily=20 > > sending ESP > > packets; perhaps receiving some ICMP parameter problem)=20 > hence it has=20 > > no HIP > > timer running. >=20 > Yes, this is probably missing. This has been relegated to the "implementation dependent" category so far. =20 Another thing that is missing is the ability to explicitly disassociate or drop a HIP association, or perhaps to suspend one if one of the hosts goes off line for a while (this latter case could be part of the mobility/multi-homing work). I suggest an open issue on handling the removal of HIP state for ICMP, timeout, or other reasons. >=20 > > So what limits how long time case iii) stays around? >=20 > I think some text should be added on how to react to > received ICMP Parameter Problem messages. Unfortunately > I don't have time to write up anything now. >=20 > > Is the intent that the document actually recommend some behavior > > when receiving ICMP pameter problem pointing at the SPI field? >=20 > Yes, that was my intention, but apparently I failed to do so. > Anyone, please? A reasonable thing would be to start establishing > a new HIP assoc, by sending I1, but _not_ to drop the existing SAs > yet. Maybe rate limit them or something, but not drop, as the > ICMP Parameter Problem may be forged. >=20 How do we avoid that a spoofed ICMP Parameter Problem could trigger a re-establishment of HIP state? Perhaps the I2 needs to carry some indication that the I2 is due to receipt of a Parameter Problem, and allowing the responder to send something other than R2 to tell the initiator to keep using the existing SAs? And then once the host had detected a spoofed parameter problem, it could be more cautious about responding to them in the near future. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 8 07:10:42 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18435 for ; Tue, 8 Jun 2004 07:10:42 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8B46A7304; Tue, 8 Jun 2004 06:15:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id E5A1572F4 for ; Tue, 8 Jun 2004 06:14:20 -0400 (EDT) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id F1BED8; Tue, 8 Jun 2004 14:09:20 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040606A9@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040606A9@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4C395242-B93C-11D8-8CCC-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: , "Erik Nordmark" From: Pekka Nikander Subject: Re: [Hipsec] Recovery from state loss To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 8 Jun 2004 14:09:23 +0300 Date: Tue, 8 Jun 2004 14:09:23 +0300 Content-Transfer-Encoding: 7bit > I suggest an open issue on handling the removal of HIP state for > ICMP, timeout, or other reasons. Ok for me. I guess we need some freedom on implementations here. > How do we avoid that a spoofed ICMP Parameter Problem could trigger > a re-establishment of HIP state? Perhaps the I2 needs to carry > some indication that the I2 is due to receipt of a Parameter Problem, > and allowing the responder to send something other than R2 to tell > the initiator to keep using the existing SAs? And then once the > host had detected a spoofed parameter problem, it could be more > cautious about responding to them in the near future. Well, when you receive the R1, you can double check to see if you've received any traffic on the existing incoming SA in the meanwhile. If so, the ICMP was probably spoofed. Including something on I2 sounds like a good idea, but complicated. I would leave that for a future extension, just in the name of simplicity. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 8 12:47:42 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07505 for ; Tue, 8 Jun 2004 12:47:41 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C3DDA731D; Tue, 8 Jun 2004 11:52:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by honor.icsalabs.com (Postfix) with ESMTP id D551172E6 for ; Tue, 8 Jun 2004 11:51:44 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i58GkgLc021197; Tue, 8 Jun 2004 11:46:43 -0500 (CDT) Received: from ericsson.com (rvi2-93-145.sw.ericsson.se [153.88.93.145]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB8TYZS; Tue, 8 Jun 2004 11:46:14 -0500 Message-ID: <40C5ED6F.3040908@ericsson.com> X-Sybari-Trust: cd84a799 100f6658 c3a3caf7 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Eggert Cc: Julien Laganier , hipsec@honor.trusecure.com, David Ward , "Pekka Nikander (JO/LMF)" , "Petri Jokela (JO/LMF)" Subject: Re: [Hipsec] Milestone status References: NEC Network Labs <40C4234C.5040800@netlab.nec.de> In-Reply-To: <40C4234C.5040800@netlab.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 08 Jun 2004 19:46:39 +0300 Date: Tue, 08 Jun 2004 19:46:39 +0300 Content-Transfer-Encoding: 7bit Lars, Julien, I have noticed that your draft uses the boilerplate that keeps the IETF from creating derivative work: "This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English." Could you please explain why did you decide to do so? Thanks, Gonzalo Lars Eggert wrote: > Hi, > > Julien Laganier wrote: > >>A pre-version of the rendezvous draft is (finally ;) available at: >> >> > > xt> > > tml> > >>We would greatly appreciate any comments related to that draft. > > > I have not seen any discussion on this on the list yet. We'd really like > > to receive some initial feedback before the cutoff for San Diego. > > Lars -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 8 20:55:49 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14817 for ; Tue, 8 Jun 2004 20:55:48 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DA15372F4; Tue, 8 Jun 2004 20:00:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id A259772E0 for ; Tue, 8 Jun 2004 19:59:54 -0400 (EDT) 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 TAA14455 for ; Tue, 8 Jun 2004 19:55:02 -0500 (CDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i590t2i14583 for ; Tue, 8 Jun 2004 17:55:02 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 8 Jun 2004 17:54:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361E7B@xch-nw-09.nw.nos.boeing.com> Thread-Topic: ECHO_REQUEST and critical bit Thread-Index: AcRNvF9TP76NKmYlRv6O1ioKMvLO5w== From: "Ahrenholz, Jeffrey M" To: X-OriginalArrivalTime: 09 Jun 2004 00:54:52.0778 (UTC) FILETIME=[5FB00CA0:01C44DBC] Subject: [Hipsec] ECHO_REQUEST and critical bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 8 Jun 2004 17:54:51 -0700 Date: Tue, 8 Jun 2004 17:54:51 -0700 Content-Transfer-Encoding: quoted-printable This seems a bit minor, but I was looking at the ECHO_REQUEST and ECHO_RESPONSE and wondering why those under the signature (1022, 1024) are non-critical, while the parameters outside the signature (65281, 65283) have the critical bit set? -Jeff _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 8 21:47:43 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17751 for ; Tue, 8 Jun 2004 21:47:42 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5AC97731B; Tue, 8 Jun 2004 20:52:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by honor.icsalabs.com (Postfix) with ESMTP id 888CF72F5 for ; Tue, 8 Jun 2004 20:51:31 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i591kbNf029196; Tue, 8 Jun 2004 18:46:38 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i591kYQ09412; Wed, 9 Jun 2004 03:46:35 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [Hipsec] Recovery from state loss To: "Henderson, Thomas R" Cc: Pekka Nikander , Erik Nordmark , hipsec@honor.trusecure.com In-Reply-To: "Your message with ID" <6938661A6EDA8A4EA8D1419BCE46F24C040606A9@xch-nw-27.nw.nos.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 8 Jun 2004 18:46:31 -0700 (PDT) Date: Tue, 8 Jun 2004 18:46:31 -0700 (PDT) > Another thing that is missing is the ability to explicitly disassociate > or drop a HIP association, or perhaps to suspend one if one > of the hosts goes off line for a while (this latter case could > be part of the mobility/multi-homing work). I've been looking at doing this for the NOID draft (which has signalling similar to HIP if you ignore the security part). Basically it seems to be possible to add a CLOSE and CLOSE-ACK message plus time based rules (that the association is dropped if no packet is received on the association in X minutes) and have the result never end up with an unknown SPI due to one end dropping the association while the other end retains the association. This appears robust even if the network doesn't provide reachability in one or both directions as an endpoint tries to disassociate. Would folks be interested in a writeup on something like this? Erik _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 9 03:31:46 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00840 for ; Wed, 9 Jun 2004 03:31:46 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 751FB7325; Wed, 9 Jun 2004 02:36:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from tokyo.netlab.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by honor.icsalabs.com (Postfix) with ESMTP id 3C7317322 for ; Wed, 9 Jun 2004 02:35:50 -0400 (EDT) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 9B47E2C90D; Wed, 9 Jun 2004 09:30:56 +0200 (CEST) Received: from yamato.netlab.nec.de (jupiter.office [10.1.1.3]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with SMTP id DA554132C4F; Wed, 9 Jun 2004 09:30:54 +0200 (CEST) Received: from 10.1.1.83 (SquirrelMail authenticated user eggert) by yamato.netlab.nec.de with HTTP; Wed, 9 Jun 2004 09:30:54 +0200 (CEST) Message-ID: <3918.10.1.1.83.1086766254.squirrel@yamato.netlab.nec.de> In-Reply-To: <40C5ED6F.3040908@ericsson.com> References: NEC Network Labs <40C4234C.5040800@netlab.nec.de> <40C5ED6F.3040908@ericsson.com> Subject: Re: [Hipsec] Milestone status From: Lars.Eggert@netlab.nec.de To: "Gonzalo Camarillo" Cc: "Lars Eggert" , "Julien Laganier" , hipsec@honor.trusecure.com, "David Ward" , "Pekka Nikander" , "Petri Jokela" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 9 Jun 2004 09:30:54 +0200 (CEST) Date: Wed, 9 Jun 2004 09:30:54 +0200 (CEST) Content-Transfer-Encoding: 8bit > Lars, Julien, > > I have noticed that your draft uses the boilerplate that keeps the > IETF > from creating derivative work: > > "This document may not be modified, and derivative works of > it may not be created, except to publish it as an RFC and to > translate it into languages other than English." > > Could you please explain why did you decide to do so? This is probably left over from my initial draft submission - I always use "no derivative works" by default. I see no issue in relaxing this restriction for this particular draft. Julien? Lars _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 9 05:23:47 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04539 for ; Wed, 9 Jun 2004 05:23:46 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8AF287322; Wed, 9 Jun 2004 04:28:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id 3273C7304 for ; Wed, 9 Jun 2004 04:27:25 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i599MacP007374 for ; Wed, 9 Jun 2004 03:22:36 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZ100HA5BDNE3@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Wed, 09 Jun 2004 03:22:35 -0600 (MDT) Received: from [192.168.1.230] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HZ100FF1BDK46@mail.sun.net> for hipsec@honor.trusecure.com; Wed, 09 Jun 2004 03:22:35 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Milestone status In-reply-to: <3918.10.1.1.83.1086766254.squirrel@yamato.netlab.nec.de> To: Lars.Eggert@netlab.nec.de Cc: Gonzalo Camarillo , hipsec@honor.trusecure.com, David Ward , Pekka Nikander , Petri Jokela Message-id: <200406091122.41150.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <40C4234C.5040800@netlab.nec.de> <40C5ED6F.3040908@ericsson.com> <3918.10.1.1.83.1086766254.squirrel@yamato.netlab.nec.de> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 09 Jun 2004 11:22:40 +0200 Date: Wed, 09 Jun 2004 11:22:40 +0200 Content-Transfer-Encoding: 7BIT On Wednesday 09 June 2004 09:30, Lars.Eggert@netlab.nec.de wrote: > > Lars, Julien, > > > > I have noticed that your draft uses the boilerplate that keeps > > the IETF > > from creating derivative work: > > > > "This document may not be modified, and derivative works of > > it may not be created, except to publish it as an RFC and to > > translate it into languages other than English." > > > > Could you please explain why did you decide to do so? > > This is probably left over from my initial draft submission - I > always use "no derivative works" by default. I see no issue in > relaxing this restriction for this particular draft. Julien? Fine with me too. --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jun 11 07:46:01 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15021 for ; Fri, 11 Jun 2004 07:46:01 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B4FDB735B; Fri, 11 Jun 2004 06:50:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id D0E68734C for ; Fri, 11 Jun 2004 06:49:19 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id 6CA472130BF for ; Fri, 11 Jun 2004 14:44:43 +0300 (EEST) Message-ID: <40C999E4.2030406@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] draft-ietf-hip-base-00 submitted Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 11 Jun 2004 14:39:16 +0300 Date: Fri, 11 Jun 2004 14:39:16 +0300 Content-Transfer-Encoding: 7bit I submitted the first HIP WG version of the base draft just few minutes ago. There are not many changes to the 10-pre4 version. Changing from the old RFC2026 format to RFC3668 format generated most of the changes and I made few small corrections according to received feedback. You can find the submitted version (txt, html) and diff from 10-pre4: http://hip4inter.net/documentation/drafts/draft-ietf-hip-base-00.txt http://hip4inter.net/documentation/drafts/draft-ietf-hip-base-00.html http://hip4inter.net/documentation/drafts/diff_10pre4_00.html BR, Petri _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sat Jun 12 14:18:08 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14732 for ; Sat, 12 Jun 2004 14:18:08 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C150372F2; Sat, 12 Jun 2004 13:22:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id B83DA737F for ; Fri, 11 Jun 2004 14:46:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27955; Fri, 11 Jun 2004 15:41:48 -0400 (EDT) Message-Id: <200406111941.PAA27955@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-00.txt Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 11 Jun 2004 15:41:48 -0400 Date: Fri, 11 Jun 2004 15:41:48 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-00.txt Pages : 98 Date : 2004-6-11 This memo specifies the details of the Host Identity Protocol (HIP). The overall description of protocol and the underlying architectural thinking is available in the separate HIP architecture specification. The Host Identity Protocol is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The various forms of the Host Identity, Host Identity Tag (HIT) and Local Scope Identifier (LSI), are covered in detail. It is described how they are used to support authentication and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secured communication channel between the hosts. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many denial-of-service (DoS)attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered elsewhere. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-11142055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-11142055.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 15 11:19:25 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26533 for ; Tue, 15 Jun 2004 11:19:25 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DC1417324; Tue, 15 Jun 2004 10:23:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by honor.icsalabs.com (Postfix) with ESMTP id 97CB97318 for ; Tue, 15 Jun 2004 10:22:08 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id i5FFHxqT002046 for ; Tue, 15 Jun 2004 18:17:59 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Some mm-02-pre1 comments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 15 Jun 2004 18:17:59 +0300 (EEST) Date: Tue, 15 Jun 2004 18:17:59 +0300 (EEST) More comments: How can we inform the peer on multiple usable inbound SPIs ? After the base exchange we have one SA with inbound SPI (let's say SPI_1), associated with some IPv6 address A_1, similarly as in Figure 1 in chapter 5.1 of mm-02. Then we would like to add another network interface, so we send an UPDATE packet which contains the addresses belonging to this interface. When building this packet we create a new inbound SA with SPI_2, add a REA parameter to the packet with SPI field set to SPI_2. After adding REA we have to add the NES parameter. The New SPI field in this NES is simple, it is set to SPI_2 (right ?). But what should we put into the Old SPI field ? If we set it to SPI_1, then the SA corresponding to SPI_1 is deleted when the reply UPDATE is received, therefore resulting in a situation where we have only one inbound SA and not two separate inbound SAs as should have been the case. Also, we can't just set Old SPI to some fixed value, because 0-255 are reserved SPI values and the remaining values can not be used because the SPI should be random anyway. Third note is that I guess the Old SPI must match to some SPI which has been in use before (if not, the received UPDATE packet is erroneous and must be dropped). Do we need a new parameter (or modify NES) for indicating that the old SAs should not be deleted ? I read and re-read the draft several times but I couldn't figure out how the simultaneous SPI/address associations can be accomplished as in Figure 2 of chapter 5.1. Or have have just misunderstood something.. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 15 18:05:28 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21234 for ; Tue, 15 Jun 2004 18:05:28 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E346E7324; Tue, 15 Jun 2004 17:09:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id 0AD567318 for ; Tue, 15 Jun 2004 17:08:59 -0400 (EDT) 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 PAA10955; Tue, 15 Jun 2004 15:04:51 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i5FM4pi15757; Tue, 15 Jun 2004 15:04:51 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 15 Jun 2004 15:04:43 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Some mm-02-pre1 comments X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04521FD1@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Some mm-02-pre1 comments Thread-Index: AcRS7CXB1fFDZC3bQomJzt9lBBwfwgAODWAQ From: "Henderson, Thomas R" To: "Mika Kousa" , X-OriginalArrivalTime: 15 Jun 2004 22:04:44.0022 (UTC) FILETIME=[C3AFC160:01C45324] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 15 Jun 2004 15:04:43 -0700 Date: Tue, 15 Jun 2004 15:04:43 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi] > Sent: Tuesday, June 15, 2004 8:18 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Some mm-02-pre1 comments >=20 >=20 > Do we need a new parameter (or modify NES) for indicating=20 > that the old SAs > should not be deleted ? I read and re-read the draft several=20 > times but I > couldn't figure out how the simultaneous SPI/address=20 > associations can be > accomplished as in Figure 2 of chapter 5.1. Or have have just > misunderstood something.. mm-02-pre1 doesn't deal with that issue explicitly. I have thought about setting old SPI =3D new SPI to indicate the case for which the new SPI was not replacing anything. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 16 08:37:09 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23529 for ; Wed, 16 Jun 2004 08:37:08 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B302B7324; Wed, 16 Jun 2004 06:21:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 92A3472E8 for ; Wed, 16 Jun 2004 06:20:55 -0400 (EDT) Received: (from localhost user: 'mkomu' uid#27521 fake: STDIN (mkomu@kekkonen.cs.hut.fi)) by mail.niksula.cs.hut.fi id ; Wed, 16 Jun 2004 14:16:49 +0300 From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Cc: hipsec@honor.trusecure.com In-Reply-To: <200405191102.23309.julien.laganier@sun.com> Message-ID: References: <407E5FA9.8020702@ericsson.com> <200405191102.23309.julien.laganier@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Hipsec] DNS draft and HI-locator relationship Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 16 Jun 2004 14:16:49 +0300 (EEST) Date: Wed, 16 Jun 2004 14:16:49 +0300 (EEST) The DNS draft does not explicitly mention about the relationship between a HI and the associated locators, or perphaps I just missed it. The RR records corresponding to an FQDN are "flat" and it is impossible to associate a specific HI to a spefic locator. The ascii graphics below hopefully illustrate my point: +---- FQDN ---+----+ FQDN / / \ \ \ / \ HI1 HI2 IP1 IP2 IP3 HI1 HI2 / \ \ IP1 IP2 IP3 In the left, the "flatness" of the RRs is shown. Implicitly, each HI is associated with all of the locators. One the right, the "ideal" association tree is shown, where it is possible to associate a specific HI with only certain IP addresses. Maybe this should be mentioned in the draft explicitly? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 16 09:43:42 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25574 for ; Wed, 16 Jun 2004 09:43:42 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8D6CE7316; Wed, 16 Jun 2004 03:55:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id BE6E772E8 for ; Wed, 16 Jun 2004 03:54:22 -0400 (EDT) Received: (from localhost user: 'mkomu' uid#27521 fake: STDIN (mkomu@kekkonen.cs.hut.fi)) by mail.niksula.cs.hut.fi id ; Wed, 16 Jun 2004 11:50:05 +0300 From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Milestone status In-Reply-To: <200405191102.23309.julien.laganier@sun.com> Message-ID: References: <407E5FA9.8020702@ericsson.com> <200405191102.23309.julien.laganier@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 16 Jun 2004 11:50:05 +0300 (EEST) Date: Wed, 16 Jun 2004 11:50:05 +0300 (EEST) On Wed, 19 May 2004, Julien Laganier wrote: > Last but not least, a preliminary version of the DNS draft is > available at: > > > > > We welcome any comments on this proposal. Note that, however, as I'll > be in vacation until June, 1st, I won't be able to process comments > until then. 1 Intro - Perhaps it could be explicitly mentioned that (non-HAA) HITs and HIs without the FQDN cannot be resolved to anything for the time being. Or maybe you want to leave some space here. 3 Usage Scenarios - may prevent him -> may prevent it - A HIP responder use a Rendezvous Server -> uses - Maybe something could be said about non-HIP nodes as well, such as "Non-HIP nodes should not use the HIP RR extensions for anything else than diagnostic purposes". Or maybe this just too obvious. 4.4 Providing multiple IP addresses 5.1.4 RDATA format public key - text coming up in the next version? Other than that, good work! -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 16 09:55:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27174 for ; Wed, 16 Jun 2004 09:55:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 953827316; Wed, 16 Jun 2004 08:59:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by honor.icsalabs.com (Postfix) with ESMTP id 9690772E8 for ; Wed, 16 Jun 2004 08:58:03 -0400 (EDT) Received: from [10.1.1.112] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4FBD61BAC4D for ; Wed, 16 Jun 2004 15:53:55 +0200 (CEST) Message-ID: <40D050EE.8030109@netlab.nec.de> From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6 (Macintosh/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060904030105010400050003" Subject: [Hipsec] draft-moskowitz-hip-arch expired Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 16 Jun 2004 15:53:50 +0200 Date: Wed, 16 Jun 2004 15:53:50 +0200 This is a cryptographically signed message in MIME format. --------------ms060904030105010400050003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, just realized that draft-moskowitz-hip-arch-05 has expired. Is there an update forthcoming? Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------ms060904030105010400050003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNjE2MTM1MzUwWjAjBgkqhkiG 9w0BCQQxFgQUE9AmxNcgIJQvwaTSBEQFEZ3WiPAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA ySP0AWVawKul8Sn3XM6ET/45X9yR7wUqOESOcRim27BbeUq0jBH2HZmWXeJV3mX6KTTkpxit CCknzZWP2sVPdpv9wOaKmwblinon0oTTRoP5q/B3b+Pr7fk/xPCKrk4gBOC0vE63tKaWU7BH 9nksTF8xpUR+nIA9MpSChdarTe8gPkcoIlpayWBSoQe9YkIK8XRWG72kvfoV07QpcRZSOijP 410nl/aOEKByQMwV9N0lzOA5IEkCPWVqfnkoIpOWfn6uyg/oN01pswbuhOM144jgLCHudYeH kyWAKoMJsr7u0giOVcPpGvX6Lo2uCQ/k90oP1GCt6x75hznrT8DLyQAAAAAAAA== --------------ms060904030105010400050003-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Jun 17 08:05:40 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22645 for ; Thu, 17 Jun 2004 08:05:40 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 30D0F7327; Thu, 17 Jun 2004 07:09:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by honor.icsalabs.com (Postfix) with ESMTP id D32787321 for ; Thu, 17 Jun 2004 07:08:01 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id i5HC46Gd015216 for ; Thu, 17 Jun 2004 15:04:06 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Some mm-02-pre1 comments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 17 Jun 2004 15:04:06 +0300 (EEST) Date: Thu, 17 Jun 2004 15:04:06 +0300 (EEST) There is a conflict in parameter type values: draft-ietf-hip-base-00 specifies SPI parameter as Type 1 and mm-02-pre1 draft specifies also that REA parameter has Type 1. This should be fixed when final version of mm-02 is released. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jun 18 09:45:46 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21231 for ; Fri, 18 Jun 2004 09:45:45 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 153357350; Fri, 18 Jun 2004 08:49:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id C79D4734B for ; Fri, 18 Jun 2004 08:48:36 -0400 (EDT) Received: from iki.fi (fortytwo.hiit.fi [212.68.5.83]) by pegasus.hiit.fi (Postfix) with ESMTP id E0FBD220002 for ; Fri, 18 Jun 2004 16:44:46 +0300 (EEST) Message-ID: <40D2F1CE.7030204@iki.fi> From: Kristian Slavov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 Debian/1.6-1.he-1 X-Accept-Language: en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Comments on draft-eggert-hip-rendezvous-01pre1 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 18 Jun 2004 16:44:46 +0300 Date: Fri, 18 Jun 2004 16:44:46 +0300 Content-Transfer-Encoding: 7bit Hi, Is there a problem (for example) in 7.2.3: Once the responder receives I1 with FROM parameter from the RVS, it sends the R1 straight to the Initiator. The R1, that is sent, needs to have REA and VIA_RVS parameters added. The VIA_RVS is not covered by the signature, so it is not a problem. However, the REA parameter is. It effectively hinders us to use precreated R1s. Now a trivial DoS attack would be to send I1s with FROM field and force the responder to create a lots of R1s. The responder can have some intelligence, like checking that the I1 with FROM parameter originates from a certain IP address(es) but that is easily forged. An another question related to the soft-HA (or RVA) creation: When is the correct time to create the RVA? The HIP base draft says that the responder should transition to ESTABLISHED state no sooner than it has received ESP data for that connection or some time has passed. Currently I've solved the above issues like this: 1) When an R1 is received and is discovered to be valid, its source IPv6 address is saved to the address list of the HIP Host Association in question. The rest of the base exchange uses this new address. This way we can use the precreated R1s. 2) As soon as the I2 is deemed to be valid and the R2 created, we create the RVA. We are in R2-SENT state at that time. -- Kristian Slavov, Researcher Helsinki Institute for Information Technology Gsm: +358-40-7220960 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jun 18 09:48:44 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21497 for ; Fri, 18 Jun 2004 09:48:44 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 84E6A7350; Fri, 18 Jun 2004 08:52:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by honor.icsalabs.com (Postfix) with ESMTP id 49F43734B for ; Fri, 18 Jun 2004 08:51:49 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5IDlv623516; Fri, 18 Jun 2004 16:47:57 +0300 (EET DST) X-Scanned: Fri, 18 Jun 2004 16:47:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5IDl4Uj031115; Fri, 18 Jun 2004 16:47:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 0026Gane; Fri, 18 Jun 2004 16:47:03 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5IDl3H05455; Fri, 18 Jun 2004 16:47:03 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Jun 2004 16:46:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Milestone status Message-ID: <2D3EB51EAED985419D54AB340A9D01951FB014@esebe024.ntc.nokia.com> Thread-Topic: [Hipsec] Milestone status Thread-Index: AcRTf0u3FmH72xSGRdu2t4kN7i7ciwBuoAbQ From: To: Cc: X-OriginalArrivalTime: 18 Jun 2004 13:46:14.0791 (UTC) FILETIME=[9FA28970:01C4553A] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 18 Jun 2004 16:46:14 +0300 Date: Fri, 18 Jun 2004 16:46:14 +0300 Content-Transfer-Encoding: quoted-printable Hello Julien I also read the draft. I have one question that might have an obvious = answer, but it is not explicit in the draft. Why is it that the section 4.1 "Different types of HITs" defines the = HITs based on IPv6 addressing (i.e. to avoid the most commonly occurring = IPv6 addresses). Is it because of the transition period mentioned in 4.2 = only? Or is there some more fundamental reason? What ever the reason could be it would be nice to have mentioned it. - Hannu > -----Original Message----- > From: hipsec-admin@honor.trusecure.com > [mailto:hipsec-admin@honor.trusecure.com]On Behalf Of ext Miika Komu > Sent: 16 June, 2004 11:50 > To: Julien Laganier > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Milestone status >=20 >=20 > On Wed, 19 May 2004, Julien Laganier wrote: >=20 > > Last but not least, a preliminary version of the DNS draft is > > available at: > > > >=20 > > >=20 > > > We welcome any comments on this proposal. Note that, however, as I'll > be in vacation until June, 1st, I won't be able to process comments > until then. 1 Intro - Perhaps it could be explicitly mentioned that (non-HAA) HITs and HIs without the FQDN cannot be resolved to anything for the time being. Or maybe you want to leave some space here. 3 Usage Scenarios - may prevent him -> may prevent it - A HIP responder use a Rendezvous Server -> uses - Maybe something could be said about non-HIP nodes as well, such as "Non-HIP nodes should not use the HIP RR extensions for anything else than diagnostic purposes". Or maybe this just too obvious. 4.4 Providing multiple IP addresses 5.1.4 RDATA format public key - text coming up in the next version? Other than that, good work! --=20 Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jun 18 15:07:49 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12221 for ; Fri, 18 Jun 2004 15:07:48 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 516517350; Fri, 18 Jun 2004 14:11:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id 01A33734B for ; Fri, 18 Jun 2004 14:10:58 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BbOhi-0002tZ-00; Fri, 18 Jun 2004 15:07:10 -0400 From: Tim Shepard To: hipsec@honor.trusecure.com Cc: Jake Beal Message-Id: Subject: [Hipsec] proposal for a few small changes to puzzle mechanism Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 18 Jun 2004 15:07:10 -0400 Date: Fri, 18 Jun 2004 15:07:10 -0400 Jake Beal (CC: above) and I have been thinking about the puzzle mechanisms and how to implement a server in a way that allows it to defend itself against attack. (We are working on a paper.) We believe there are a few minor things about the way the puzzle mechanism is described in draft-ietf-hip-base-00.txt that need to be improved to allow for robust implementation of the puzzle mechanism. Use elapsed time, not number of solutions tried ----------------------------------------------- In section 4.1.1 HIP Cookie Mechanism, it says the client SHOULD give up after trying 2^(K+2) different numbers for J. Appendix C describes the probabilities for finding a solution given a number of tries. Since different clients may have widely differing processing speeds, we believe it would be better if the client should try for a given amount of time before giving up. Otherwise, allowing sufficient time for slow clients to submit solutions impedes the servers deprecation of old puzzles. Note that giving up and retrying with a new puzzle does not increase the total expected time (or cycles) spent finding a valid puzzle solution. (For example, 50 tries with one puzzle and 50 tries with another puzzle is just as likely to produce a solution as 100 tries with one puzzle.) What a client needs to know is not how many tries it should make, but rather for how long in the future will a solution to this puzzle be accepted by the server. So either the protocol should deliver a number of seconds with a puzzle to tell the client how much time it may spend trying to solve this puzzle, or a fixed amount of time (one minute?, two minutes?) should be specified in the protocol. Note that this could obviate the need for the R1 counter mechanism, and we believe that a time-remaining mechanism is simpler and more reliable than a counter mechanism. (Note that a time-remaining mechanism is significantly less demanding than the timestamp mechanism considered earlier.) Note this still will leave many options for the server. The server could continue to issue or accept the same puzzle far beyond the explicit or implicit timeout implied by delivering the puzzle in any particular R1 packet. A client that that tried to solve a puzzle and ran out of time will perform a new I1-R1 exchange, and then continue to search for a puzzle solution with whatever puzzle arrives in the new R1. The server may have reissued the same puzzle, in which case the client should make sure that it will not retry the same set of J values that failed to find a solution last time. (A little randomness here would suffice.) So if you like our proposal to use elapsed time instead of number of J values tried, we need to decide whether how long the puzzle should be valid is carried explicitly in the R1 packet or is simply written into the protocol specification (and carried implicitly by the delivery of a puzzle in an R1 packet). Appendix C should be revised (or perhaps removed?) if this proposal is adopted. Dropping I2s to shed load ------------------------- Servers need to be able to shed load. Even with the puzzle mechanism, it is possible for a server to be overwhelmed with valid I2s and some of those I2s will need to be dropped (as they overflow the queue for processing of the DH exponentiation). How the server should tune the puzzle difficulty remains an interesting research question. No matter what mechanism is used to tune the difficulty of the puzzle, we believe there will still be scenarios where the arrival rate of I2s exceeds the server's capacity to process them (e.g. flash crowds). It must not be the case that aggressive retransmission of puzzle solutions improves the chances of an attacker's puzzle solutions being serviced. Therefore the server will need to remember (with perhaps a Bloom filter) what legitimate puzzle solutions have already been submitted, so that they can be persistantly dropped. When the server sheds load by choosing to persisitantly drop the puzzle solution presented in an I2, we need a mechanism to say to the client: Your puzzle solution was recevied by the server and was valid. However, the server is suffering under some kind of overload and has chosen to shed load by rejecting your request. You may retry if you wish, however you MUST find another (different) puzzle solution for any such retries. Note that you may need to obtain a new puzzle with a new I1/R1 exchange (e.g. if there is not sufficient time left or if the puzzle and/or puzzle difficulty has been changed). It seems like a new NOTIFY parameter (e.g. SERVER_BUSY_PLEASE_RETRY) would satisfy this need. Acknowledge I2s before sending R2s? ----------------------------------- When the server's queue for processing I2s is long, and the network path has a significant drop rate, then there is no good way for the client to set the timer for retransmission of the I2 packet. If there was some way to separate the communication delay from the server's queueing and processing delay, then the client could set the retransmission timer for the I2 more appropriately. So should receipt of a valid I2 be acknowledged, perhaps optionally depending upon the anticipated delay before the server can produce an R2? If there should be this acknowledgement mechanism, should it also be done with a NOTIFY paramater? -Tim Shepard shep@alum.mit.edu Jacob Beal jakebeal@mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sat Jun 19 05:13:50 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11213 for ; Sat, 19 Jun 2004 05:13:50 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9AB2F73C8; Sat, 19 Jun 2004 04:17:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id EBA537386 for ; Sat, 19 Jun 2004 04:16:44 -0400 (EDT) Received: (from localhost user: 'mkomu' uid#27521 fake: STDIN (mkomu@kekkonen.cs.hut.fi)) by mail.niksula.cs.hut.fi id ; Sat, 19 Jun 2004 12:12:48 +0300 From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hannu.flinck@nokia.com Cc: Julien Laganier , hipsec@honor.trusecure.com Subject: RE: [Hipsec] Milestone status In-Reply-To: <2D3EB51EAED985419D54AB340A9D01951FB014@esebe024.ntc.nokia.com> Message-ID: References: <2D3EB51EAED985419D54AB340A9D01951FB014@esebe024.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sat, 19 Jun 2004 12:12:48 +0300 (EEST) Date: Sat, 19 Jun 2004 12:12:48 +0300 (EEST) On Fri, 18 Jun 2004 hannu.flinck@nokia.com wrote: > Why is it that the section 4.1 "Different types of HITs" defines the > HITs based on IPv6 addressing (i.e. to avoid the most commonly occurring > IPv6 addresses). Is it because of the transition period mentioned in 4.2 > only? One practical reason is related to the implementations. The "legacy HIP API" for the applications is a kludge because the main concern in it is to trigger HIP base exchange from the application layer. The HITs are contained in sockaddr_in6 socket address structure in an application, with the family set to AF_INET6 (at least in our implementation). The "HIP module" catches these HITs that are disguised as IPv6 addresses and can tell the difference between an IPv6 address and a HIT by the upper bits in the address. I am going to propose a cleaner alternative to this later this month. The proposal includes a new family, PF_HIP, which dimishes the need for the upper bits of HIT for comparing with IPv6 addresses. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun Jun 20 13:15:03 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16910 for ; Sun, 20 Jun 2004 13:15:03 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DC1F57303; Sun, 20 Jun 2004 12:18:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id 78D3972F3 for ; Sun, 20 Jun 2004 12:17:36 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1Bc5tJ-0007dW-00; Sun, 20 Jun 2004 13:14:01 -0400 From: Tim Shepard To: hipsec@honor.trusecure.com Cc: Jake Beal Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism In-reply-to: Your message of Fri, 18 Jun 2004 15:07:10 -0400. Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 20 Jun 2004 13:14:00 -0400 Date: Sun, 20 Jun 2004 13:14:00 -0400 > Note that this could obviate the need for the R1 counter mechanism, > and we believe that a time-remaining mechanism is simpler and more > reliable than a counter mechanism. (Note that a time-remaining > mechanism is significantly less demanding than the timestamp > mechanism considered earlier.) Well, we weren't thinking of the replay protection that the R1 counter mechanism is supposed to provide when we said that. So ignore that paragraph. Our motivation for the time-remaining mechanism is to replace the 2^(K+2) tries since there is no good way to tune for how long solutions to a given puzzle should be accepted if the clients have widely varrying processing speeds. Man in the middle attacks aimed at denial of service are difficult (impossible?) to defend against with end-to-end protocols. So I'm not sure that there is any effective mechanism for defending against a MITM attack which wants to reply old R1 packets. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 04:44:05 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22027 for ; Mon, 21 Jun 2004 04:44:05 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5D3CB72F3; Mon, 21 Jun 2004 03:47:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id 233C672F2 for ; Mon, 21 Jun 2004 03:46:39 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5L8h7il007512 for ; Mon, 21 Jun 2004 02:43:07 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZN00MJTHJV7Z@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 02:43:07 -0600 (MDT) Received: from [10.0.0.29] ([194.2.198.253]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HZN00KCPHJT3K@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 02:43:07 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Comments on draft-eggert-hip-rendezvous-01pre1 In-reply-to: <40D2F1CE.7030204@iki.fi> To: hipsec@honor.trusecure.com Cc: Kristian Slavov Message-id: <200406211042.54836.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <40D2F1CE.7030204@iki.fi> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 10:42:54 +0200 Date: Mon, 21 Jun 2004 10:42:54 +0200 Content-Transfer-Encoding: 7BIT On Friday 18 June 2004 15:44, Kristian Slavov wrote: > Hi, > > Is there a problem (for example) in 7.2.3: Once the responder > receives I1 with FROM parameter from the RVS, it sends the R1 > straight to the Initiator. The R1, that is sent, needs to have REA > and VIA_RVS parameters added. The VIA_RVS is not covered by the > signature, so it is not a problem. However, the REA parameter is. > It effectively hinders us to use precreated R1s. The REA parameter contain the _responder_'s IP addess, which is not supposed to change with each initiator attempting to associate. So we can precompute a pool of R1 per responder's IP address. > Now a trivial DoS > attack would be to send I1s with FROM field and force the responder > to create a lots of R1s. > The responder can have some intelligence, like checking that the I1 > with FROM parameter originates from a certain IP address(es) but > that is easily forged. I don't think this applies. > An another question related to the soft-HA (or RVA) creation: > When is the correct time to create the RVA? The HIP base draft says > that the responder should transition to ESTABLISHED state no sooner > than it has received ESP data for that connection or some time has > passed. While creating a RVA, I believe that the responder (i.e., the RVS) should transition to ESTABLISHED state no sooner than it has received incoming R1s to be relayed, or some time has passed. That way we are consistent with the HA state model. > Currently I've solved the above issues like this: > > 1) When an R1 is received and is discovered to be valid, its source > IPv6 address is saved to the address list of the HIP Host > Association in question. The rest of the base exchange uses this > new address. This way we can use the precreated R1s. > > 2) As soon as the I2 is deemed to be valid and the R2 created, we > create the RVA. We are in R2-SENT state at that time. This is equivalent to the HA state model with a time limit of zero. What do people think of this issue? Thanks, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 04:58:02 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22767 for ; Mon, 21 Jun 2004 04:58:02 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 2D91F72F3; Mon, 21 Jun 2004 04:01:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id A651272F2 for ; Mon, 21 Jun 2004 04:00:15 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5L8ulil013284 for ; Mon, 21 Jun 2004 02:56:47 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZN00MA5I6M7Z@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 02:56:47 -0600 (MDT) Received: from [10.0.0.29] ([194.2.198.253]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HZN00KDWI6K3K@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 02:56:46 -0600 (MDT) From: Julien Laganier Subject: [Hipsec] DNS draft (Was: Milestone status) In-reply-to: To: Miika Komu Cc: hipsec@honor.trusecure.com Message-id: <200406211056.34454.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <407E5FA9.8020702@ericsson.com> <200405191102.23309.julien.laganier@sun.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 10:56:34 +0200 Date: Mon, 21 Jun 2004 10:56:34 +0200 Content-Transfer-Encoding: 7BIT On Wednesday 16 June 2004 10:50, Miika Komu wrote: > > 1 Intro > - Perhaps it could be explicitly mentioned that (non-HAA) HITs and > HIs without the FQDN cannot be resolved to anything for the time > being. Or maybe you want to leave some space here. Yes it was intentionnal, because I believe some folks are working on a DHT-based lookup on HIs. > 3 Usage Scenarios > - may prevent him -> may prevent it > - A HIP responder use a Rendezvous Server -> uses > - Maybe something could be said about non-HIP nodes as well, such > as "Non-HIP nodes should not use the HIP RR extensions for anything > else than diagnostic purposes". Or maybe this just too obvious. Perhaps adding the following sentence: "Note that, storing HIP RR informations in the DNS at a FQDN which is assigned to a non-HIP node, might have very bad effects on its reachability by HIP nodes" > 4.4 Providing multiple IP addresses > 5.1.4 RDATA format public key > - text coming up in the next version? Yes. > Other than that, good work! Thanks! --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 04:59:04 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22812 for ; Mon, 21 Jun 2004 04:59:04 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 15FF9730B; Mon, 21 Jun 2004 04:02:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id F0A65730B for ; Mon, 21 Jun 2004 04:01:26 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5L8u753024586 for ; Mon, 21 Jun 2004 02:56:07 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZN002CVI8LNX@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 02:57:58 -0600 (MDT) Received: from [10.0.0.29] ([194.2.198.253]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HZN00K9DI8J3N@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 02:57:57 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] DNS draft and HI-locator relationship In-reply-to: To: hipsec@honor.trusecure.com Cc: Miika Komu Message-id: <200406211057.45814.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <407E5FA9.8020702@ericsson.com> <200405191102.23309.julien.laganier@sun.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 10:57:45 +0200 Date: Mon, 21 Jun 2004 10:57:45 +0200 Content-Transfer-Encoding: 7BIT On Wednesday 16 June 2004 13:16, Miika Komu wrote: > The DNS draft does not explicitly mention about the relationship > between a HI and the associated locators, or perphaps I just missed > it. The RR records corresponding to an FQDN are "flat" and it is > impossible to associate a specific HI to a spefic locator. The > ascii graphics below hopefully illustrate my point: > > +---- FQDN ---+----+ FQDN > / / \ \ \ / \ > HI1 HI2 IP1 IP2 IP3 HI1 HI2 > / \ \ > IP1 IP2 IP3 > > In the left, the "flatness" of the RRs is shown. Implicitly, each > HI is associated with all of the locators. One the right, the > "ideal" association tree is shown, where it is possible to > associate a specific HI with only certain IP addresses. I like the 'ideal' model, because it might be very useful for doing load balancing on a single FQDN which map to multiple hosts, with their own HI, and their own set of IP addresses. > Maybe this should be mentioned in the draft explicitly? True, but at the time I wrote I wasn't able to design something good enough allowing the 'ideal' model, so I choose to keep this question out of the draft for the time being.... About the ideal model, where a HI has a certain pool of IP addresses, this means that, either: o you are able to resolve an HI into a set of IP address, but at this time we don't have yet a proper way to implement this lookup (DHT might be one solution) o you store IP addresses in the DNS within a new HIP RR, said HIPLOC, along with either the HI or an index to it (or perhaps the HIT), allowing to map between several HI and IP addresses. At this point I'm not sure which of the options above makes the most sense. Perhaps other HIPpies have an opinion on that topic? Thanks, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 05:42:03 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25360 for ; Mon, 21 Jun 2004 05:42:03 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 3181372F3; Mon, 21 Jun 2004 04:45:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 0BFE672F2 for ; Mon, 21 Jun 2004 04:44:44 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5L9dP53013407 for ; Mon, 21 Jun 2004 03:39:25 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZN00MASK8R7Z@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 03:41:15 -0600 (MDT) Received: from [10.0.0.29] ([194.2.198.253]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HZN003MFK8PL5@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 03:41:14 -0600 (MDT) From: Julien Laganier Subject: [Hipsec] DNS draft (Was: Milestone status) In-reply-to: <2D3EB51EAED985419D54AB340A9D01951FB014@esebe024.ntc.nokia.com> To: hannu.flinck@nokia.com Cc: hipsec@honor.trusecure.com Message-id: <200406211141.03051.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <2D3EB51EAED985419D54AB340A9D01951FB014@esebe024.ntc.nokia.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 11:41:03 +0200 Date: Mon, 21 Jun 2004 11:41:03 +0200 Content-Transfer-Encoding: 7BIT On Friday 18 June 2004 15:46, hannu.flinck@nokia.com wrote: > Hello Julien Hi Hannu, > I also read the draft. I have one question that might have an > obvious answer, but it is not explicit in the draft. > > Why is it that the section 4.1 "Different types of HITs" defines > the HITs based on IPv6 addressing (i.e. to avoid the most commonly > occurring IPv6 addresses). Is it because of the transition period > mentioned in 4.2 only? Or is there some more fundamental reason? The main reason, as Miika explained, is to be able to use the legacy IPv6 API (socket w/ AF_INET6) with HITs in place of IP addresses. That way it's easier to distinhuish between a HIT or an IPv6 address. I can remember, also, that at some point there was both pure-HITs and IPv6-compatible HITs, the latter being basically the same with the two first bits rewritten to avoid commom IPv6 address... IMHO, the true question is, do we need more than 126 bits for fighting against collision attacks on HITs? If so, would 128 bits be sufficient? AFAICT, 126 bits are enough, and it nicely allows to mix IPv6 addresses and HITs in the APIs, so I would prefer sticking to 126... > What ever the reason could be it would be nice to have mentioned > it. I'll add some text. Thanks, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 05:56:02 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26380 for ; Mon, 21 Jun 2004 05:56:02 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EF8BA72F3; Mon, 21 Jun 2004 04:59:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by honor.icsalabs.com (Postfix) with ESMTP id 72EB372F2 for ; Mon, 21 Jun 2004 04:58:45 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5L9tD206338 for ; Mon, 21 Jun 2004 12:55:13 +0300 (EET DST) X-Scanned: Mon, 21 Jun 2004 12:54:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5L9sQZo018646 for ; Mon, 21 Jun 2004 12:54:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00pjPSU9; Mon, 21 Jun 2004 12:54:24 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5L9sMH25939 for ; Mon, 21 Jun 2004 12:54:22 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Jun 2004 12:54:18 +0300 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Jun 2004 12:54:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] DNS draft (Was: Milestone status) Message-ID: <2D3EB51EAED985419D54AB340A9D01951FB016@esebe024.ntc.nokia.com> Thread-Topic: [Hipsec] DNS draft (Was: Milestone status) Thread-Index: AcRXdAZlWX2zTG7kQ3iuvowghFUJUwAAEwGw From: To: X-OriginalArrivalTime: 21 Jun 2004 09:54:17.0364 (UTC) FILETIME=[B770F540:01C45775] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 12:54:16 +0300 Date: Mon, 21 Jun 2004 12:54:16 +0300 Content-Transfer-Encoding: quoted-printable Thank you Miika and Julien I can see the reasoning for this. However, if I gather correct HITs are = not used for routing and do not appear on wire in the IPv6 header, thus = blending them might not be the most best approach. As it appears to me = now, the IPv6 address space is used to guide the HIP layer. But if this = is not a local activity (is it?) and you may not need to use globally = routable addresses for this.=20 Regards Hannu > -----Original Message----- > From: Julien.Laganier@sun.com [mailto:Julien.Laganier@sun.com] > Sent: 21 June, 2004 12:41 > To: Flinck Hannu (Nokia-NRC/Helsinki) > Cc: hipsec@honor.trusecure.com > Subject: [Hipsec] DNS draft (Was: Milestone status) >=20 >=20 > On Friday 18 June 2004 15:46, hannu.flinck@nokia.com wrote: > > Hello Julien >=20 > Hi Hannu, >=20 > > I also read the draft. I have one question that might have an > > obvious answer, but it is not explicit in the draft. > > > > Why is it that the section 4.1 "Different types of HITs" defines > > the HITs based on IPv6 addressing (i.e. to avoid the most commonly > > occurring IPv6 addresses). Is it because of the transition period > > mentioned in 4.2 only? Or is there some more fundamental reason? >=20 > The main reason, as Miika explained, is to be able to use the legacy=20 > IPv6 API (socket w/ AF_INET6) with HITs in place of IP addresses.=20 > That way it's easier to distinhuish between a HIT or an IPv6 address. >=20 > I can remember, also, that at some point there was both pure-HITs and=20 > IPv6-compatible HITs, the latter being basically the same with the=20 > two first bits rewritten to avoid commom IPv6 address...=20 >=20 > IMHO, the true question is, do we need more than 126 bits for=20 > fighting=20 > against collision attacks on HITs? If so, would 128 bits be=20 > sufficient? >=20 > AFAICT, 126 bits are enough, and it nicely allows to mix IPv6=20 > addresses and HITs in the APIs, so I would prefer sticking to 126... >=20 > > What ever the reason could be it would be nice to have mentioned > > it. >=20 > I'll add some text. >=20 > Thanks, >=20 > --julien >=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 05:57:04 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26427 for ; Mon, 21 Jun 2004 05:57:03 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 92A09730B; Mon, 21 Jun 2004 05:00:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id B11DF730B for ; Mon, 21 Jun 2004 04:59:24 -0400 (EDT) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 623C88; Mon, 21 Jun 2004 12:55:53 +0300 (EEST) In-Reply-To: <200406211056.34454.julien.laganier@sun.com> References: <407E5FA9.8020702@ericsson.com> <200405191102.23309.julien.laganier@sun.com> <200406211056.34454.julien.laganier@sun.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2DA5E6C9-C369-11D8-A66D-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] DNS draft (Was: Milestone status) To: Julien Laganier X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 11:55:51 +0200 Date: Mon, 21 Jun 2004 11:55:51 +0200 Content-Transfer-Encoding: 7bit Thanks, Julien, for a very nice first version. Some specific comments, in no particular order: > The Host Identity Protocol[10] allows two HIP nodes to establish two > pairs of bidirectional IPsec Security Association. The above statement is not quite right. IPsec SAs are always unidirectional. And there aren't two pairs of them, just one pair of them. Hence, please reword. > Hence the desire -> Hence, there is a desire (otherwise it would be an incomplete sentence) > it first needs to perform an HIP base exchange to set-up a HIP > association between themselves. s/between themselves/towards its peer/ or something like that. Currently it is not clear what is "them". > There are two types of HITs. -> There are _currently_ two types of HITs defined. I agree with Hannu's and others' comments on the HIT format on Section 4.1, and I am looking forward on alternatives. On thing that we may need to do is to separate the format of HITs are used in the protocol and the format of HITs used in the legacy IPv6 API. I am unsure about the language "SHOULD be able to store", and its meaning. Usually RFC2119 terms are used to define protocol practices, not operational practices. Section 5.1.1: > 1 A 128-bit HAA is present Seems like there is a bug or two in the above. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 06:00:02 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26632 for ; Mon, 21 Jun 2004 06:00:02 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 3C4C672F3; Mon, 21 Jun 2004 05:03:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id 7CA9072F2 for ; Mon, 21 Jun 2004 05:02:41 -0400 (EDT) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id C0A628; Mon, 21 Jun 2004 12:59:12 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com, Jake Beal From: Pekka Nikander Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism To: Tim Shepard X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 11:59:11 +0200 Date: Mon, 21 Jun 2004 11:59:11 +0200 Content-Transfer-Encoding: 7bit Tim, > Our motivation for the time-remaining mechanism is to replace the > 2^(K+2) tries since there is no good way to tune for how long > solutions to a given puzzle should be accepted if the clients have > widely varrying processing speeds. I think that (at least) this part of your proposal is very worth of adopting. (I haven't had time to really think about the rest.) Do you have a any preference whether to use a global value or add an option to the base protocol now? Remember that such an option could always be added later, now that we have this extensible protocol. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 06:06:02 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27030 for ; Mon, 21 Jun 2004 06:06:02 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7E34072F3; Mon, 21 Jun 2004 05:09:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mail.acheron.indranet.co.nz (ns.indranet.co.nz [210.54.239.210]) by honor.icsalabs.com (Postfix) with ESMTP id 7641A72F2 for ; Mon, 21 Jun 2004 05:08:45 -0400 (EDT) Received: from localhost (enso.acheron.indranet.co.nz [192.168.1.1]) by mail.acheron.indranet.co.nz (8.11.2-20030919/8.11.2) with ESMTP id i5LA4xr16525; Mon, 21 Jun 2004 22:04:59 +1200 From: Andrew McGregor To: hannu.flinck@nokia.com, hipsec@honor.trusecure.com Subject: RE: [Hipsec] DNS draft (Was: Milestone status) Message-ID: In-Reply-To: <2D3EB51EAED985419D54AB340A9D01951FB016@esebe024.ntc.nokia.com> References: <2D3EB51EAED985419D54AB340A9D01951FB016@esebe024.ntc.nokia.com> X-Mailer: Mulberry/3.1.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 22:02:55 +1200 Date: Mon, 21 Jun 2004 22:02:55 +1200 Content-Transfer-Encoding: 7bit As I recall, we (Tim, Pekka and myself, and perhaps some others I have forgotten, sorry) had a long discussion about the required size of HITs embedded in IPv6 space during the San Francisco IETF, and came to the conclusion that even 112 bits would be fine (i.e. /16). Basically, we need to double the number to gain a substantial security benefit, which is impossible within an IPv6 address, therefore a conservative allocation of IPv6 space for the purpose is fine. We never expected that these would be routable; on the contrary. However, they do need to be distinguishable from routable addresses in the legacy IPv6 API (in effect, we route them into the HIP stack). Andrew --On Monday, 21 June 2004 12:54 p.m. +0300 hannu.flinck@nokia.com wrote: > > Thank you Miika and Julien > > I can see the reasoning for this. However, if I gather correct HITs are > not used for routing and do not appear on wire in the IPv6 header, thus > blending them might not be the most best approach. As it appears to me > now, the IPv6 address space is used to guide the HIP layer. But if this > is not a local activity (is it?) and you may not need to use globally > routable addresses for this. > > Regards Hannu > >> -----Original Message----- >> From: Julien.Laganier@sun.com [mailto:Julien.Laganier@sun.com] >> Sent: 21 June, 2004 12:41 >> To: Flinck Hannu (Nokia-NRC/Helsinki) >> Cc: hipsec@honor.trusecure.com >> Subject: [Hipsec] DNS draft (Was: Milestone status) >> >> >> On Friday 18 June 2004 15:46, hannu.flinck@nokia.com wrote: >> > Hello Julien >> >> Hi Hannu, >> >> > I also read the draft. I have one question that might have an >> > obvious answer, but it is not explicit in the draft. >> > >> > Why is it that the section 4.1 "Different types of HITs" defines >> > the HITs based on IPv6 addressing (i.e. to avoid the most commonly >> > occurring IPv6 addresses). Is it because of the transition period >> > mentioned in 4.2 only? Or is there some more fundamental reason? >> >> The main reason, as Miika explained, is to be able to use the legacy >> IPv6 API (socket w/ AF_INET6) with HITs in place of IP addresses. >> That way it's easier to distinhuish between a HIT or an IPv6 address. >> >> I can remember, also, that at some point there was both pure-HITs and >> IPv6-compatible HITs, the latter being basically the same with the >> two first bits rewritten to avoid commom IPv6 address... >> >> IMHO, the true question is, do we need more than 126 bits for >> fighting >> against collision attacks on HITs? If so, would 128 bits be >> sufficient? >> >> AFAICT, 126 bits are enough, and it nicely allows to mix IPv6 >> addresses and HITs in the APIs, so I would prefer sticking to 126... >> >> > What ever the reason could be it would be nice to have mentioned >> > it. >> >> I'll add some text. >> >> Thanks, >> >> --julien >> > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > --------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet-technologies.com/ -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GS/E/B/PA/SS d+(++) s+:+ a C++$ ULS++++ !P+++(---)$ L++++$ E++ W++ !N w(+++) !O() M++ V--() Y+$ PGP+ t- !5? X- !R !tv@ b++(++++) DI++ D+++@ G e+++ h(*)@ r% ------END GEEK CODE BLOCK------ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 06:10:02 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27303 for ; Mon, 21 Jun 2004 06:10:02 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 387E872F2; Mon, 21 Jun 2004 05:13:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 03BC972E0 for ; Mon, 21 Jun 2004 05:12:16 -0400 (EDT) Received: (from localhost user: 'mkomu' uid#27521 fake: STDIN (mkomu@kekkonen.cs.hut.fi)) by mail.niksula.cs.hut.fi id ; Mon, 21 Jun 2004 13:08:34 +0300 From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] DNS draft (Was: Milestone status) In-Reply-To: <200406211056.34454.julien.laganier@sun.com> Message-ID: References: <407E5FA9.8020702@ericsson.com> <200405191102.23309.julien.laganier@sun.com> <200406211056.34454.julien.laganier@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 13:08:34 +0300 (EEST) Date: Mon, 21 Jun 2004 13:08:34 +0300 (EEST) On Mon, 21 Jun 2004, Julien Laganier wrote: > > 3 Usage Scenarios > > ... > > - Maybe something could be said about non-HIP nodes as well, such > > as "Non-HIP nodes should not use the HIP RR extensions for anything > > else than diagnostic purposes". Or maybe this just too obvious. > > Perhaps adding the following sentence: "Note that, storing HIP RR > informations in the DNS at a FQDN which is assigned to a non-HIP > node, might have very bad effects on its reachability by HIP nodes" Ok. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 06:31:02 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28462 for ; Mon, 21 Jun 2004 06:31:02 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 42F337302; Mon, 21 Jun 2004 05:34:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 4071A72F2 for ; Mon, 21 Jun 2004 05:33:19 -0400 (EDT) Received: (from localhost user: 'mkomu' uid#27521 fake: STDIN (mkomu@kekkonen.cs.hut.fi)) by mail.niksula.cs.hut.fi id ; Mon, 21 Jun 2004 13:29:38 +0300 From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] DNS draft and HI-locator relationship In-Reply-To: <200406211057.45814.julien.laganier@sun.com> Message-ID: References: <407E5FA9.8020702@ericsson.com> <200405191102.23309.julien.laganier@sun.com> <200406211057.45814.julien.laganier@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 13:29:38 +0300 (EEST) Date: Mon, 21 Jun 2004 13:29:38 +0300 (EEST) On Mon, 21 Jun 2004, Julien Laganier wrote: > About the ideal model, where a HI has a certain pool of IP addresses, > this means that, either: > > o you are able to resolve an HI into a set of IP address, but at this > time we don't have yet a proper way to implement this lookup (DHT > might be one solution) > > o you store IP addresses in the DNS within a new HIP RR, said HIPLOC, > along with either the HI or an index to it (or perhaps the HIT), > allowing to map between several HI and IP addresses. > > At this point I'm not sure which of the options above makes the most > sense. Perhaps other HIPpies have an opinion on that topic? IMHO, the DHT approach is more elegant than the HIPLOC. Still, the HIPLOC seems more practical because we don't know if we will ever have the DHT stuff anyway. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 08:12:08 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05283 for ; Mon, 21 Jun 2004 08:12:07 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 0F78972F3; Mon, 21 Jun 2004 07:15:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id B5C1C72F2 for ; Mon, 21 Jun 2004 07:14:35 -0400 (EDT) Received: from n51.nomadiclab.com (n51.nomadiclab.com [131.160.193.51]) by n2.nomadiclab.com (Postfix) with ESMTP id B0EF32130CA; Mon, 21 Jun 2004 15:11:02 +0300 (EEST) From: Jan Mikael Melen To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism User-Agent: KMail/1.6.2 Cc: Pekka Nikander , Tim Shepard , Jake Beal References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406211511.02311.Jan.Melen@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 15:11:02 +0300 Date: Mon, 21 Jun 2004 15:11:02 +0300 Content-Transfer-Encoding: 7bit Hi, On Monday 21 June 2004 12:59, Pekka Nikander wrote: > > > Our motivation for the time-remaining mechanism is to replace the > > 2^(K+2) tries since there is no good way to tune for how long > > solutions to a given puzzle should be accepted if the clients have > > widely varrying processing speeds. > > I think that (at least) this part of your proposal is very > worth of adopting. (I haven't had time to really think about > the rest.) > > Do you have a any preference whether to use a global value or > add an option to the base protocol now? Remember that such > an option could always be added later, now that we have this > extensible protocol. I think that this should be optional TLV in the R1 and if present one should not try to solve the puzzle longer than the time-remaining indicates or 2^(K+2) times. What do others think? > > Dropping I2s to shed load If we would have a server busy notification wouldn't that be a way for the attacker to know that she has succeeded, if she is trying to just overload the server? > > Acknowledge I2s before sending R2s? I don't think this is really necessary nor wise. I think this just adds complexity that really is not needed. What would the initiator do when he receives this notification? Double the timer for waiting R2? Would these notifications be sent periodically until the R2 is sent? Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 08:14:07 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05417 for ; Mon, 21 Jun 2004 08:14:05 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E534872F3; Mon, 21 Jun 2004 07:17:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 3D70A72F2 for ; Mon, 21 Jun 2004 07:16:00 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5LCAe53013558 for ; Mon, 21 Jun 2004 06:10:40 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZN0028RR8UNX@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 06:12:31 -0600 (MDT) Received: from [10.0.0.29] ([194.2.198.253]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HZN003U5R8SL2@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 06:12:30 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism In-reply-to: To: hipsec@honor.trusecure.com Cc: Tim Shepard , Jake Beal Message-id: <200406211412.18363.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 14:12:18 +0200 Date: Mon, 21 Jun 2004 14:12:18 +0200 Content-Transfer-Encoding: 7BIT On Sunday 20 June 2004 19:14, Tim Shepard wrote: > > Note that this could obviate the need for the R1 counter > > mechanism, and we believe that a time-remaining mechanism is > > simpler and more reliable than a counter mechanism. (Note that a > > time-remaining mechanism is significantly less demanding than the > > timestamp mechanism considered earlier.) > > Well, we weren't thinking of the replay protection that the R1 > counter mechanism is supposed to provide when we said that. > > So ignore that paragraph. > > Our motivation for the time-remaining mechanism is to replace the > 2^(K+2) tries since there is no good way to tune for how long > solutions to a given puzzle should be accepted if the clients have > widely varrying processing speeds. I agree with the proposed changes... Indeed, my implementation gave up after 10 seconds of failed attempts to solve the puzzle. Tnx, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 08:35:07 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06585 for ; Mon, 21 Jun 2004 08:35:05 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5E13772F3; Mon, 21 Jun 2004 07:38:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id ED46F72F2 for ; Mon, 21 Jun 2004 07:37:14 -0400 (EDT) Received: from iki.fi (fortytwo.hiit.fi [212.68.5.83]) by pegasus.hiit.fi (Postfix) with ESMTP id A4F4D220004; Mon, 21 Jun 2004 15:33:44 +0300 (EEST) Message-ID: <40D6D5A8.8050509@iki.fi> From: Kristian Slavov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 Debian/1.6-1.he-1 X-Accept-Language: en MIME-Version: 1.0 To: Julien Laganier Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Comments on draft-eggert-hip-rendezvous-01pre1 References: <40D2F1CE.7030204@iki.fi> <200406211042.54836.julien.laganier@sun.com> In-Reply-To: <200406211042.54836.julien.laganier@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 15:33:44 +0300 Date: Mon, 21 Jun 2004 15:33:44 +0300 Content-Transfer-Encoding: 7bit Julien Laganier wrote: > On Friday 18 June 2004 15:44, Kristian Slavov wrote: > >>Hi, >> >>Is there a problem (for example) in 7.2.3: Once the responder >>receives I1 with FROM parameter from the RVS, it sends the R1 >>straight to the Initiator. The R1, that is sent, needs to have REA >>and VIA_RVS parameters added. The VIA_RVS is not covered by the >>signature, so it is not a problem. However, the REA parameter is. >>It effectively hinders us to use precreated R1s. > > > The REA parameter contain the _responder_'s IP addess, which is not > supposed to change with each initiator attempting to associate. So we > can precompute a pool of R1 per responder's IP address. The pool aproach might be inefficient in long run. We would have a situation where there are 4 variables in R1: DH group, puzzle K, HI and the responder's IPv6 address. Now, say we have 2 different values for each of the variables. That means 2^4 different R1s and we probably will want to have more than one of each R1 (say 10). So, we will need to create 160 R1s. However, I don't have anything better to suggest right now. -- Kristian Slavov, Researcher Helsinki Institute for Information Technology Gsm: +358-40-7220960 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 11:11:04 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19473 for ; Mon, 21 Jun 2004 11:11:04 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5D90F72F3; Mon, 21 Jun 2004 10:14:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 6060072E6 for ; Mon, 21 Jun 2004 10:13:22 -0400 (EDT) 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 KAA28942 for ; Mon, 21 Jun 2004 10:09:52 -0500 (CDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i5LF9qp08050 for ; Mon, 21 Jun 2004 10:09:52 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Mon, 21 Jun 2004 08:09:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] proposal for a few small changes to puzzle mechanism Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040606FB@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] proposal for a few small changes to puzzle mechanism Thread-Index: AcRXiOuP5ikC0xFNSqOS9/84q5OreAAEeqgA From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 21 Jun 2004 15:09:45.0747 (UTC) FILETIME=[C9A2FE30:01C457A1] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 08:09:45 -0700 Date: Mon, 21 Jun 2004 08:09:45 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jan Mikael Melen [mailto:Jan.Melen@nomadiclab.com]=20 > Sent: Monday, June 21, 2004 5:11 AM > To: hipsec@honor.trusecure.com > Cc: Pekka Nikander; Tim Shepard; Jake Beal > Subject: Re: [Hipsec] proposal for a few small changes to=20 > puzzle mechanism >=20 >=20 > Hi, >=20 > On Monday 21 June 2004 12:59, Pekka Nikander wrote: > > > > > Our motivation for the time-remaining mechanism is to replace the > > > 2^(K+2) tries since there is no good way to tune for how long > > > solutions to a given puzzle should be accepted if the clients have > > > widely varrying processing speeds. > > > > I think that (at least) this part of your proposal is very > > worth of adopting. (I haven't had time to really think about > > the rest.) > > > > Do you have a any preference whether to use a global value or > > add an option to the base protocol now? Remember that such > > an option could always be added later, now that we have this > > extensible protocol. >=20 > I think that this should be optional TLV in the R1 and if=20 > present one should=20 > not try to solve the puzzle longer than the time-remaining=20 > indicates or=20 > 2^(K+2) times. >=20 > What do others think? Basically, this amounts to a mechanism to allow for faster puzzle rotation in the presence of slow clients. The tradeoff is that it may require multiple I1/R1 exchanges for a slow client to get a solution. An alternative would be to allow for a slow host to figure this out on its own when its puzzle solutions are rejected as being solutions to stale puzzles (but I see that we presently do not have a NOTIFY code for "expired puzzle"). If we explicitly signal the puzzle lifetime, we could also=20 redefine the Puzzle parameter to include a TTL, either by taking=20 a byte from "Opaque" or by putting optional bytes at the end=20 of the parameter. =20 >=20 > > > Dropping I2s to shed load >=20 > If we would have a server busy notification wouldn't that be=20 > a way for the=20 > attacker to know that she has succeeded, if she is trying to=20 > just overload=20 > the server? In the absence of an explicit overload notification, do you=20 think that an attacker would be discouraged from attacking? =20 >=20 > > > Acknowledge I2s before sending R2s? >=20 Perhaps instead the optional TLV (or another optional TLV, or the Puzzle) in the R1 has a recommended "server load" time to=20 add to the normal I2 retransmission time? =20 Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 11:11:09 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19496 for ; Mon, 21 Jun 2004 11:11:08 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 4D8A5730A; Mon, 21 Jun 2004 10:14:06 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id DCC0372E6 for ; Mon, 21 Jun 2004 10:13:34 -0400 (EDT) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 3BDC28 for ; Mon, 21 Jun 2004 18:10:07 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <14416936-C395-11D8-A66D-000393CE1E8C@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: hipsec@honor.trusecure.com From: Pekka Nikander X-Mailer: Apple Mail (2.618) Subject: [Hipsec] HIP RG mailing list created Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 17:10:06 +0200 Date: Mon, 21 Jun 2004 17:10:06 +0200 Content-Transfer-Encoding: 7bit Folks, We have now a separate mailing list for the to-be HIP RG. I've mass subscribed those that previously indicated that they are willing to act as founding members for the RG. Others are free to subscribe. I expect Vern to put up the RG charter page shortly, as it has been pending on this mailing list issue. More info and subscription instructions can be found at http://honor.trusecure.com/mailman/listinfo/hipsec-rg --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 21 11:12:05 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19535 for ; Mon, 21 Jun 2004 11:12:05 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D1BBA7309; Mon, 21 Jun 2004 10:15:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id DEFC572F2 for ; Mon, 21 Jun 2004 10:14:57 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5LF9e53020750 for ; Mon, 21 Jun 2004 09:09:40 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZN0026VZJ6NX@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 09:11:31 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HZN0065TZJ387@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 21 Jun 2004 09:11:30 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] DNS draft (Was: Milestone status) In-reply-to: <2DA5E6C9-C369-11D8-A66D-000393CE1E8C@nomadiclab.com> To: Pekka Nikander Cc: hipsec@honor.trusecure.com Message-id: <200406211711.16821.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <407E5FA9.8020702@ericsson.com> <200406211056.34454.julien.laganier@sun.com> <2DA5E6C9-C369-11D8-A66D-000393CE1E8C@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 21 Jun 2004 17:11:16 +0200 Date: Mon, 21 Jun 2004 17:11:16 +0200 Content-Transfer-Encoding: 7BIT Hi Pekka, On Monday 21 June 2004 11:55, Pekka Nikander wrote: > Thanks, Julien, for a very nice first version. > > Some specific comments, in no particular order: > > The Host Identity Protocol[10] allows two HIP nodes to > > establish two pairs of bidirectional IPsec Security Association. > > The above statement is not quite right. IPsec SAs are always > unidirectional. And there aren't two pairs of them, just one > pair of them. Hence, please reword. Ok, I was counting on the two hosts... :) > > Hence the desire > > -> Hence, there is a desire > (otherwise it would be an incomplete sentence) Ok. > > it first needs to perform an HIP base exchange to set-up a HIP > > association between themselves. > > s/between themselves/towards its peer/ or something like that. > Currently it is not clear what is "them". > > > There are two types of HITs. > > -> There are _currently_ two types of HITs defined. > > I agree with Hannu's and others' comments on the HIT format > on Section 4.1, and I am looking forward on alternatives. > On thing that we may need to do is to separate the format > of HITs are used in the protocol and the format of HITs > used in the legacy IPv6 API. I'll try to insert a little summary of the discussion on this topic, as well as alternatives to the current situation. BTW, I agree that we might need to differentiate between HITs (those used in the protocol) and HITs representation (used in legacy API), but in the meanti > I am unsure about the language "SHOULD be able to store", > and its meaning. Usually RFC2119 terms are used to > define protocol practices, not operational practices. Ok. > Section 5.1.1: > > 1 A 128-bit HAA is present > > Seems like there is a bug or two in the above. Right, also the public key RDATA is missing. I'll fix these bugs before submitting. > --Pekka Thanks for the comments, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 22 07:42:13 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02007 for ; Tue, 22 Jun 2004 07:42:13 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E964D733E; Tue, 22 Jun 2004 06:45:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id C1C5E72E0 for ; Tue, 22 Jun 2004 06:44:15 -0400 (EDT) Received: from n51.nomadiclab.com (n51.nomadiclab.com [131.160.193.51]) by n2.nomadiclab.com (Postfix) with ESMTP id 6B03C2130CA; Tue, 22 Jun 2004 14:40:51 +0300 (EEST) From: Jan Mikael Melen To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism User-Agent: KMail/1.6.2 Cc: "Henderson, Thomas R" References: <6938661A6EDA8A4EA8D1419BCE46F24C040606FB@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040606FB@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406221440.50963.Jan.Melen@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 22 Jun 2004 14:40:50 +0300 Date: Tue, 22 Jun 2004 14:40:50 +0300 Content-Transfer-Encoding: 7bit Hi, Solving puzzles issue and I2 retransmission timeout issue: In R1 we need two timer values TTL for a puzzle and I2 processing delay. Also there is a question about adding a NOTIFY. One byte should be more than enough for puzzle TTL. In the absence of this TTL value the puzzle is considered to be valid for next 256 seconds (as it would if TTL field would be 0xff+1, same as setting the byte to zero, absence is indicated by zero value in this field). For I2 server delay we would probably need 16 bit value that would indicate the value to be added in to normal I2 retransmission time in milliseconds which would mean that the range is from 0...65535ms that should be enough? Now where do we put these? Proposal: - Puzzle TTL in to the puzzle TLV by reducing the size of opaque field with one byte. New TLV would be: 1 byte k, 1 byte TTL, 2 bytes Opaque and 8 bytes random I. - Modify the text in section 4.1.1 stating that client should try find a solution for a given amount of time before giving up or if time has not been specified for 256s. Remove Appendix C completely. - Add a new NOTIFY SERVER_BUSY_PLEASE_RETRY which the server MAY send to the Initiator in case it is under severe load. Not mandatory in which case the Initiator would act as if the I2 would have been dropped by the network. - Add a new optional TLV in R1 for the I2 retransmission timeout called I2_PROCESSING_DELAY. This TLV would contain 2 bytes reserved and 2 bytes indicating processing delay on the server end. Is this okay? On Monday 21 June 2004 18:09, Henderson, Thomas R wrote: > > Basically, this amounts to a mechanism to allow for faster > puzzle rotation in the presence of slow clients. The tradeoff > is that it may require multiple I1/R1 exchanges for a slow > client to get a solution. An alternative would be to allow > for a slow host to figure this out on its own when its puzzle > solutions are rejected as being solutions to stale puzzles > (but I see that we presently do not have a NOTIFY code for > "expired puzzle"). > > If we explicitly signal the puzzle lifetime, we could also > redefine the Puzzle parameter to include a TTL, either by taking > a byte from "Opaque" or by putting optional bytes at the end > of the parameter. Jan _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 22 08:08:11 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03150 for ; Tue, 22 Jun 2004 08:08:11 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 93D3E73A7; Tue, 22 Jun 2004 07:11:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id 5B20A73A7 for ; Tue, 22 Jun 2004 07:10:03 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1Bck2n-0008Qt-00; Tue, 22 Jun 2004 08:06:29 -0400 From: Tim Shepard To: Jan Mikael Melen Cc: hipsec@honor.trusecure.com, "Henderson, Thomas R" Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism In-reply-to: Your message of Tue, 22 Jun 2004 14:40:50 +0300. <200406221440.50963.Jan.Melen@nomadiclab.com> Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 22 Jun 2004 08:06:28 -0400 Date: Tue, 22 Jun 2004 08:06:28 -0400 It is not so much the I2 processing delay that we were worried about, but rather the delay that the proccessing of the I2 will see because a queue has (perhaps suddenly) built up on the server. I could imagine scenarios where the time spent in this queue is many 10s of seconds, while the round trip time is only 100 ms or less. When a client is in this situation, but is behind a lossy link (which, for example, is dropping 20% of the packets), you leave the client in a situation where it would have to wait many 10s of seconds to conclude that a packet had been dropped, if there is no acknowledgement of the I2. So I do not think that telling the client what delay to expect in the processing of its I2 is useful. TCP retransmits SYN packets much more aggressively than that. Note that a lost I2, if not recovered via a quick retransmission, may cause a solved puzzle to soon become useless, causing the client (perhaps an energy-limited client) to have to start over and solve a new puzzle. That seems to be a severe penalty for a single dropped packet. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 22 09:18:11 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07503 for ; Tue, 22 Jun 2004 09:18:11 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E4FDB7318; Tue, 22 Jun 2004 08:21:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id D5E6572EA for ; Tue, 22 Jun 2004 08:20:12 -0400 (EDT) Received: from n51.nomadiclab.com (n51.nomadiclab.com [131.160.193.51]) by n2.nomadiclab.com (Postfix) with ESMTP id E2F0E2130CA; Tue, 22 Jun 2004 16:16:48 +0300 (EEST) From: Jan Mikael Melen To: Tim Shepard Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism User-Agent: KMail/1.6.2 Cc: hipsec@honor.trusecure.com, "Henderson, Thomas R" References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406221616.48444.Jan.Melen@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 22 Jun 2004 16:16:48 +0300 Date: Tue, 22 Jun 2004 16:16:48 +0300 Content-Transfer-Encoding: 7bit Hi, Tim, yes you have a point of not introducing the processing delay of the server. But let's imagine the following situation: Initiator has already sent a I2 and received acknowledment for it. Now the user behind the computer is beginning to be frustrated as nothing is happening after a few seconds. He is already starting to bang the keyboard. What should the HIP daemon do? A) Retransmit the I2 and ignore that it got an acknowledgment from the previous I2? This same as if the responder had not sent the acknowledgement in the first place. B) Just sit wait for R2 as the user bangs the keyboard? The R2 might as well be lost due lossy link and still the Initiator just waits due to fact that it has gotten acknowledgement from the responder. R2 message has no timeout mechanism that would ensure it's retransmission. These just might be stupid questions... Regards, Jan On Tuesday 22 June 2004 15:06, Tim Shepard wrote: > It is not so much the I2 processing delay that we were worried about, > but rather the delay that the proccessing of the I2 will see because a > queue has (perhaps suddenly) built up on the server. I could imagine > scenarios where the time spent in this queue is many 10s of seconds, > while the round trip time is only 100 ms or less. When a client is in > this situation, but is behind a lossy link (which, for example, is > dropping 20% of the packets), you leave the client in a situation > where it would have to wait many 10s of seconds to conclude that a > packet had been dropped, if there is no acknowledgement of the I2. > > So I do not think that telling the client what delay to expect in the > processing of its I2 is useful. > > TCP retransmits SYN packets much more aggressively than that. > > > Note that a lost I2, if not recovered via a quick retransmission, may > cause a solved puzzle to soon become useless, causing the client > (perhaps an energy-limited client) to have to start over and solve a > new puzzle. That seems to be a severe penalty for a single dropped > packet. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 22 09:33:11 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07888 for ; Tue, 22 Jun 2004 09:33:11 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 12FBD7318; Tue, 22 Jun 2004 08:36:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id B969972EA for ; Tue, 22 Jun 2004 08:35:38 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BclNg-0008TT-00; Tue, 22 Jun 2004 09:32:08 -0400 From: Tim Shepard To: Jan Mikael Melen Cc: hipsec@honor.trusecure.com, "Henderson, Thomas R" Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism In-reply-to: Your message of Tue, 22 Jun 2004 16:16:48 +0300. <200406221616.48444.Jan.Melen@nomadiclab.com> Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 22 Jun 2004 09:32:08 -0400 Date: Tue, 22 Jun 2004 09:32:08 -0400 > A) Retransmit the I2 and ignore that it got an acknowledgment from the > previous I2? This same as if the responder had not sent the acknowledgement > in the first place. > > B) Just sit wait for R2 as the user bangs the keyboard? The R2 might as well > be lost due lossy link and still the Initiator just waits due to fact that it > has gotten acknowledgement from the responder. R2 message has no timeout > mechanism that would ensure it's retransmission. > > These just might be stupid questions... No, those are very good questions. It makes me think now that if I2s need a seperate acknowledgement, then R2s also need them. Here's an idea, if the responder sends an acknowledgement in response to an I2, it could at that time give a fairly good estimate of how many seconds it should be until the R2 is sent. Another piece of an idea: if the initiator is to be the one with a timer running to cover the case of an R2 being dropped by the network, then retransmitting the same I2 seems completely reasonable. The server should be able to tell that the I2 corresponds to an already established HIP association (assuming that it has managed to process the first I2 by the time the second I2 arrives). This retransmitted I2 may need to bypass the puzzle solution checking mechanism because the puzzle may have been deprecated. Is that a problem? Does it make sense to have the check for whether the I2 corresponds to an already-established HIP association occur before checking the puzzle? Maybe the I2 should also be checked to see if it corresponds with an already admitted-for-processing I2 that is still waiting in the queue for the DH exponentiation before checking to see if the puzzle solution is valid. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 22 14:46:14 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16559 for ; Tue, 22 Jun 2004 14:46:14 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 711D1737E; Tue, 22 Jun 2004 13:49:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id D74337351 for ; Tue, 22 Jun 2004 13:48:28 -0400 (EDT) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 716318; Tue, 22 Jun 2004 21:45:06 +0300 (EEST) In-Reply-To: <200406221440.50963.Jan.Melen@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040606FB@xch-nw-27.nw.nos.boeing.com> <200406221440.50963.Jan.Melen@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <476C0D14-C47C-11D8-A66D-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism To: Jan Mikael Melen X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 22 Jun 2004 21:45:06 +0300 Date: Tue, 22 Jun 2004 21:45:06 +0300 Content-Transfer-Encoding: 7bit A quick reaction to some details; still thinking about the more complete thing in the background. > One byte should be more than enough for puzzle TTL. In the absence of > this TTL > value the puzzle is considered to be valid for next 256 seconds (as it > would > if TTL field would be 0xff+1, same as setting the byte to zero, > absence is > indicated by zero value in this field). I would use exponential interpretation of the value. I.e. TTL = 2^(value - 32). That would allow one to express the TTL as 2^-32, 2^-31, ..., 1/8, 1/4, 1/2, 1, 2, 4, 8, ... 2^223 seconds. (2^-32 seconds = 0.2 ns, 2^223 seconds = 10^59 years). Or maybe not use 2 as the base, but e.g. sqrt(2), to get finer granularity and smaller range. > - Modify the text in section 4.1.1 stating that client should try find > a > solution for a given amount of time before giving up or if time has > not been > specified for 256s. Remove Appendix C completely. I would still leave App C in some form. It is useful info. > - Add a new NOTIFY SERVER_BUSY_PLEASE_RETRY which the server MAY send > to the > Initiator in case it is under severe load. Not mandatory in which case > the > Initiator would act as if the I2 would have been dropped by the > network. I don't think it is useful to send NOTIFY before the server has verified the puzzle. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 22 21:07:15 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20124 for ; Tue, 22 Jun 2004 21:07:14 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 54BE97346; Tue, 22 Jun 2004 20:10:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by honor.icsalabs.com (Postfix) with ESMTP id 39A497321 for ; Tue, 22 Jun 2004 20:09:07 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i5N15nLL027502 for ; Tue, 22 Jun 2004 21:05:49 -0400 (EDT) Received: from home-on-the-dome.mit.edu (HOME-ON-THE-DOME.MIT.EDU [18.7.16.76]) (authenticated bits=56) (User authenticated as jakebeal@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i5N15noL021559 for ; Tue, 22 Jun 2004 21:05:49 -0400 (EDT) Received: (from jakebeal@localhost) by home-on-the-dome.mit.edu (8.12.9) id i5N15nhS007726; Tue, 22 Jun 2004 21:05:49 -0400 (EDT) Message-Id: <200406230105.i5N15nhS007726@home-on-the-dome.mit.edu> To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism From: Jake Beal Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 22 Jun 2004 21:05:49 -0400 Date: Tue, 22 Jun 2004 21:05:49 -0400 Pekka writes: >> - Add a new NOTIFY SERVER_BUSY_PLEASE_RETRY which the server MAY >> send to the Initiator in case it is under severe load. Not mandatory >> in which case the Initiator would act as if the I2 would have been >> dropped by the network. > >I don't think it is useful to send NOTIFY before the server has >verified the puzzle. That's correct. The reason we want to add the new NOTIFY message is so the server can tell a verified, deserving client that it has lost this time, and should try again. Correct puzzle solutions are essentially lottery tickets. If the server is not overloaded doing work for verified clients, everybody wins. If the server is overloaded by verified clients, then some lottery tickets lose. SERVER_BUSY_PLEASE_RETRY means you need to purchase a new ticket (solve a new puzzle) because your old one has lost (is being persistently dropped). Thanks, -Jake _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jun 22 23:32:14 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27871 for ; Tue, 22 Jun 2004 23:32:14 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1E7D77321; Tue, 22 Jun 2004 22:35:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id BD13C731B for ; Tue, 22 Jun 2004 22:34:22 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BcyTQ-0000JM-00; Tue, 22 Jun 2004 23:30:56 -0400 From: Tim Shepard To: Pekka Nikander Cc: Jan Mikael Melen , hipsec@honor.trusecure.com Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism In-reply-to: Your message of Tue, 22 Jun 2004 21:45:06 +0300. <476C0D14-C47C-11D8-A66D-000393CE1E8C@nomadiclab.com> Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 22 Jun 2004 23:30:56 -0400 Date: Tue, 22 Jun 2004 23:30:56 -0400 > > - Add a new NOTIFY SERVER_BUSY_PLEASE_RETRY which the server MAY send > > to the > > Initiator in case it is under severe load. Not mandatory in which case > > the > > Initiator would act as if the I2 would have been dropped by the > > network. > > I don't think it is useful to send NOTIFY before the server has > verified the puzzle. > > --Pekka Of course. If the puzzle does not verify, then there is a silent drop. This notification though is needed to handle the case when the server is dropping the I2 because it is overloaded *and* is implementing some sort of persistant dropping mechanism to ensure that an attacker cannot increase the likelyhood of the attacker's puzzle solutions getting themselves a spot in the queue by retransmitting them aggressively. If you are a legit client and you got dropped, you need to learn this fact so that you know to start finding another puzzle solution. The puzzle solution you previously submitted will always be dropped no matter how many times you retransmit it, even if it still has plenty of lifetime left. As I said in the original message, this would mean: > When the server sheds load by choosing to persisitantly drop the > puzzle solution presented in an I2, we need a mechanism to say to the > client: > > Your puzzle solution was recevied by the server and was valid. > However, the server is suffering under some kind of overload and > has chosen to shed load by rejecting your request. You may retry > if you wish, however you MUST find another (different) puzzle > solution for any such retries. Note that you may need to obtain a > new puzzle with a new I1/R1 exchange (e.g. if there is not > sufficient time left or if the puzzle and/or puzzle difficulty has > been changed). > > It seems like a new NOTIFY parameter (e.g. SERVER_BUSY_PLEASE_RETRY) > would satisfy this need. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 23 07:38:30 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20326 for ; Wed, 23 Jun 2004 07:38:29 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7BE31735E; Wed, 23 Jun 2004 06:41:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id E73337351 for ; Wed, 23 Jun 2004 06:40:45 -0400 (EDT) Received: from iki.fi (fortytwo.hiit.fi [212.68.5.83]) by pegasus.hiit.fi (Postfix) with ESMTP id 5AE7A22000B; Wed, 23 Jun 2004 14:37:26 +0300 (EEST) Message-ID: <40D96B76.4030501@iki.fi> From: Kristian Slavov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 Debian/1.6-1.he-1 X-Accept-Language: en MIME-Version: 1.0 To: Tim Shepard Cc: Jan Mikael Melen , hipsec@honor.trusecure.com, "Henderson, Thomas R" Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 23 Jun 2004 14:37:26 +0300 Date: Wed, 23 Jun 2004 14:37:26 +0300 Content-Transfer-Encoding: 7bit Hi, Tim Shepard wrote: > > Here's an idea, if the responder sends an acknowledgement in response > to an I2, it could at that time give a fairly good estimate of how > many seconds it should be until the R2 is sent. Since these acknowledgements need to be light-weight in terms of CPU processing, they cannot contain any cryptographic material. An attacker could easily modify the packet and raise the estimate (or even lower to cause more load for the server). On the other hand, if the attacker has means to intercept packets he could do a MITM attack as well, so in that sense this is not a problem. > Another piece of an idea: if the initiator is to be the one with a > timer running to cover the case of an R2 being dropped by the network, > then retransmitting the same I2 seems completely reasonable. The > server should be able to tell that the I2 corresponds to an already > established HIP association (assuming that it has managed to process > the first I2 by the time the second I2 arrives). This retransmitted > I2 may need to bypass the puzzle solution checking mechanism because > the puzzle may have been deprecated. Is that a problem? Does it make > sense to have the check for whether the I2 corresponds to an > already-established HIP association occur before checking the puzzle? I think this is already covered in the base-00 draft: Section 8.7 Processing incoming I2 packets 3. If the system is in the R2-SENT state, it MAY check if the newly received I2 is similar to the one that triggered moving to R2-SENT. If so, it MAY retransmit a previously sent R2, reset the R2-SENT timer, and stay in R2-SENT. -- Kristian Slavov, Researcher Helsinki Institute for Information Technology Gsm: +358-40-7220960 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 23 08:16:18 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23691 for ; Wed, 23 Jun 2004 08:16:17 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DFF7F736D; Wed, 23 Jun 2004 07:19:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by honor.icsalabs.com (Postfix) with ESMTP id 7D0FA735E for ; Wed, 23 Jun 2004 07:18:15 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id i5NCEv2t017791 for ; Wed, 23 Jun 2004 15:14:58 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: RE: [Hipsec] Some mm-02-pre1 comments In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04521FD1@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04521FD1@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 23 Jun 2004 15:14:57 +0300 (EEST) Date: Wed, 23 Jun 2004 15:14:57 +0300 (EEST) On Tue, 15 Jun 2004, Henderson, Thomas R wrote: -> > -----Original Message----- -> > From: Mika Kousa [mailto:mkousa@cc.hut.fi] -> > Sent: Tuesday, June 15, 2004 8:18 AM -> > To: hipsec@honor.trusecure.com -> > Subject: Re: [Hipsec] Some mm-02-pre1 comments -> > -> > -> > Do we need a new parameter (or modify NES) for indicating -> > that the old SAs -> > should not be deleted ? I read and re-read the draft several -> > times but I -> > couldn't figure out how the simultaneous SPI/address -> > associations can be -> > accomplished as in Figure 2 of chapter 5.1. Or have have just -> > misunderstood something.. -> -> mm-02-pre1 doesn't deal with that issue explicitly. I have -> thought about setting old SPI = new SPI to indicate the -> case for which the new SPI was not replacing anything. All right, that could be one option. If we use this scheme where Old SPI and New SPI fields in the NES parameter are the same, then this means that we do not need to create any new SAs. Because of this the Keymat Index field should be just ignored (maybe it should be set to zero). Anyway, we need to acknowledge the initial UPDATE containing the addresses belonging to the current SPI. This kind of an UPDATE packet might need some alternative processing rules. When a host receives an initial UPDATE with Old SPI=New SPI, should the peer host follow the same convention ? That is, both hosts do not create any new SAs, so we need some kind of a reply UPDATE packet which just tells the peer "I got your address list belonging to the previous SPI you have been using". In this case the "wait for data on new SA" phase can be skipped. If the sender of the reply UPDATE would like to create new SAs, it sends an another UPDATE after sending the reply UPDATE, just as in the current draft says. I haven't looked so closely at the latest base draft (draft-ietf-hip-base-00) yet, but looks like a simple reply UPDATE packet containing just the ACK parameter and no SEQ parameter would act as an acknowledgement. One more thing in this scenario: if there is not need for rekeying, should we move into REKEYING state anyway or stay at ESTABLISHED ? _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Jun 24 03:55:29 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12286 for ; Thu, 24 Jun 2004 03:55:29 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id BEF617387; Thu, 24 Jun 2004 02:58:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 036917355 for ; Thu, 24 Jun 2004 02:57:24 -0400 (EDT) Received: from iki.fi (fortytwo.hiit.fi [212.68.5.83]) by pegasus.hiit.fi (Postfix) with ESMTP id 14583220004; Thu, 24 Jun 2004 10:54:14 +0300 (EEST) Message-ID: <40DA88A5.9030903@iki.fi> From: Kristian Slavov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 Debian/1.6-1.he-1 X-Accept-Language: en MIME-Version: 1.0 To: Jan Mikael Melen Cc: hipsec@honor.trusecure.com, Pekka Nikander , Tim Shepard , Jake Beal Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism References: <200406211511.02311.Jan.Melen@nomadiclab.com> In-Reply-To: <200406211511.02311.Jan.Melen@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 24 Jun 2004 10:54:13 +0300 Date: Thu, 24 Jun 2004 10:54:13 +0300 Content-Transfer-Encoding: 7bit Jan Mikael Melen wrote: > Hi, > > On Monday 21 June 2004 12:59, Pekka Nikander wrote: > >>>Our motivation for the time-remaining mechanism is to replace the >>>2^(K+2) tries since there is no good way to tune for how long >>>solutions to a given puzzle should be accepted if the clients have >>>widely varrying processing speeds. >> >>I think that (at least) this part of your proposal is very >>worth of adopting. (I haven't had time to really think about >>the rest.) >> >>Do you have a any preference whether to use a global value or >>add an option to the base protocol now? Remember that such >>an option could always be added later, now that we have this >>extensible protocol. > > > I think that this should be optional TLV in the R1 and if present one should > not try to solve the puzzle longer than the time-remaining indicates or > 2^(K+2) times. > > What do others think? The time-remaining parameter sounds reasonbale. I think the 2^(K+2) limit is a bit artificial. I don't think that the probability of succeeding to solve the puzzle increases if we have to fetch another cookie. Also, it should be impossible to create a puzzle that has no correct solution. The initiator wants to make the connection, so he is willing to do some work. I think it is in the best interest of the initiator to solve the puzzle as fast as possible, regardless of the tries required to solve a single puzzle. >>>Acknowledge I2s before sending R2s? > > > I don't think this is really necessary nor wise. I think this just adds > complexity that really is not needed. What would the initiator do when he > receives this notification? Double the timer for waiting R2? Would these > notifications be sent periodically until the R2 is sent? What if an attacker sends many of these notifications that double the timer? Perhaps it would be better (or at least more simple) to just drop the I2s, if there is too much load and have the initiator employ some kind of backoff algorithm when resending I2s. -- Kristian Slavov, Researcher Helsinki Institute for Information Technology Gsm: +358-40-7220960 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Jun 24 09:57:51 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13095 for ; Thu, 24 Jun 2004 09:57:51 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 795D67376; Thu, 24 Jun 2004 07:58:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id A72BB7365 for ; Thu, 24 Jun 2004 07:57:49 -0400 (EDT) Received: from n51.nomadiclab.com (n51.nomadiclab.com [131.160.193.51]) by n2.nomadiclab.com (Postfix) with ESMTP id 70CB52130FB; Thu, 24 Jun 2004 15:54:38 +0300 (EEST) From: Jan Mikael Melen To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism User-Agent: KMail/1.6.2 Cc: Pekka Nikander References: <6938661A6EDA8A4EA8D1419BCE46F24C040606FB@xch-nw-27.nw.nos.boeing.com> <200406221440.50963.Jan.Melen@nomadiclab.com> <476C0D14-C47C-11D8-A66D-000393CE1E8C@nomadiclab.com> In-Reply-To: <476C0D14-C47C-11D8-A66D-000393CE1E8C@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406241554.37499.Jan.Melen@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 24 Jun 2004 15:54:37 +0300 Date: Thu, 24 Jun 2004 15:54:37 +0300 Content-Transfer-Encoding: 7bit On Tuesday 22 June 2004 21:45, Pekka Nikander wrote: > A quick reaction to some details; still thinking > about the more complete thing in the background. > > > One byte should be more than enough for puzzle TTL. In the absence of > > this TTL > > value the puzzle is considered to be valid for next 256 seconds (as it > > would > > if TTL field would be 0xff+1, same as setting the byte to zero, > > absence is > > indicated by zero value in this field). > > I would use exponential interpretation of the value. I.e. > TTL = 2^(value - 32). That would allow one to express the > TTL as 2^-32, 2^-31, ..., 1/8, 1/4, 1/2, 1, 2, 4, 8, ... 2^223 seconds. > (2^-32 seconds = 0.2 ns, 2^223 seconds = 10^59 years). This sounds good! Is okay for others as well that we take one byte from opaque and dedicate it for puzzle TTL? > Or maybe not use 2 as the base, but e.g. sqrt(2), to get finer > granularity > and smaller range. > > > - Modify the text in section 4.1.1 stating that client should try find > > a > > solution for a given amount of time before giving up or if time has > > not been > > specified for 256s. Remove Appendix C completely. > > I would still leave App C in some form. It is useful info. Okay let's leave as informational... regards, Jan _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Jun 24 22:53:29 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16497 for ; Thu, 24 Jun 2004 22:53:29 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 840CA730D; Thu, 24 Jun 2004 21:56:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 1E46E72F5 for ; Thu, 24 Jun 2004 21:55:55 -0400 (EDT) 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 VAA03116; Thu, 24 Jun 2004 21:52:37 -0500 (CDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i5P2qbI14111; Thu, 24 Jun 2004 19:52:37 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Thu, 24 Jun 2004 19:52:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] proposal for a few small changes to puzzle mechanism Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406070F@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] proposal for a few small changes to puzzle mechanism Thread-Index: AcRYUWMAu5mQgjCtTP+mvxc2PnPexwCC48RQ From: "Henderson, Thomas R" To: "Tim Shepard" , "Jan Mikael Melen" Cc: X-OriginalArrivalTime: 25 Jun 2004 02:52:36.0805 (UTC) FILETIME=[78C90750:01C45A5F] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 24 Jun 2004 19:52:36 -0700 Date: Thu, 24 Jun 2004 19:52:36 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Tim Shepard [mailto:shep@alum.mit.edu] > Sent: Tuesday, June 22, 2004 5:06 AM > To: Jan Mikael Melen > Cc: hipsec@honor.trusecure.com; Henderson, Thomas R > Subject: Re: [Hipsec] proposal for a few small changes to puzzle > mechanism=20 >=20 > So I do not think that telling the client what delay to expect in the > processing of its I2 is useful. >=20 > TCP retransmits SYN packets much more aggressively than that. Even in the case of a NOTIFY that "acks" the I2, TCP is still going=20 to be retransmitting waiting for the SYN to be acked (and these SYNs=20 will pile up internally in the local buffer or be dropped). This is=20 unless HIP implementation has some cross-layer ability to reach into=20 TCP and adjust its RTO. >=20 >=20 > Note that a lost I2, if not recovered via a quick retransmission, may > cause a solved puzzle to soon become useless, causing the client > (perhaps an energy-limited client) to have to start over and solve a > new puzzle. That seems to be a severe penalty for a single dropped > packet. > This might be why a NOTIFY (I2-ACK) with expected R2 sending time--=20 after puzzle verification-- might be more useful than a delay parameter=20 in the R1, since if you suppress the retransmission of I2, you do not=20 know whether the first I2 actually arrived (or whether R2 was lost). Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Jun 24 23:39:27 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18785 for ; Thu, 24 Jun 2004 23:39:26 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8AF6C731B; Thu, 24 Jun 2004 22:42:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id 3FF2F72F5 for ; Thu, 24 Jun 2004 22:41:56 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BdhEs-0001FV-00; Thu, 24 Jun 2004 23:18:54 -0400 From: Tim Shepard To: "Henderson, Thomas R" Cc: "Jan Mikael Melen" , hipsec@honor.trusecure.com Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism In-reply-to: Your message of Thu, 24 Jun 2004 19:52:36 -0700. <6938661A6EDA8A4EA8D1419BCE46F24C0406070F@xch-nw-27.nw.nos.boeing.com> Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 24 Jun 2004 23:18:54 -0400 Date: Thu, 24 Jun 2004 23:18:54 -0400 > > So I do not think that telling the client what delay to expect in the > > processing of its I2 is useful. > > > > TCP retransmits SYN packets much more aggressively than that. > > Even in the case of a NOTIFY that "acks" the I2, TCP is still going=20 > to be retransmitting waiting for the SYN to be acked (and these SYNs=20 > will pile up internally in the local buffer or be dropped). This is=20 > unless HIP implementation has some cross-layer ability to reach into=20 > TCP and adjust its RTO. Yes. I believe some cross layer ability would be a good thing here. > > Note that a lost I2, if not recovered via a quick retransmission, may > > cause a solved puzzle to soon become useless, causing the client > > (perhaps an energy-limited client) to have to start over and solve a > > new puzzle. That seems to be a severe penalty for a single dropped > > packet. > > > > This might be why a NOTIFY (I2-ACK) with expected R2 sending time--=20 > after puzzle verification-- might be more useful than a delay parameter=20 > in the R1, since if you suppress the retransmission of I2, you do not=20 > know whether the first I2 actually arrived (or whether R2 was lost). I agree. The delay paramter in an R1 would not be useful. If we imlement an I2-ACK NOTIFY of some sort, then it seems it would be useful to include the expected delay in sending the R2. Perhaps just a number of seconds after receipt of the I2-ACK NOTIFY that the initiator should retransmit the I2 if it has not yet received an R2. Now for the hard part, what (if any) new denial of service attacks would such a mechanism open up that weren't there before? We'll have to think about that. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jun 25 06:12:30 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21216 for ; Fri, 25 Jun 2004 06:12:30 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B3EFB731B; Fri, 25 Jun 2004 05:15:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id 8FEC872F5 for ; Fri, 25 Jun 2004 05:14:38 -0400 (EDT) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 271808; Fri, 25 Jun 2004 13:11:33 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <089B79D6-C690-11D8-A936-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Thomas R Henderson , Tim Shepard , Jan Mikael Melen From: Pekka Nikander Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism To: hipsec@honor.trusecure.com X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 25 Jun 2004 13:11:32 +0300 Date: Fri, 25 Jun 2004 13:11:32 +0300 Content-Transfer-Encoding: 7bit As a summary of the discussion so far, how about - Using one byte of the puzzle opaque field to denote the puzzle lifetime, in exponential seconds notification. I think the time denoted should be the time that the puzzle is valid, at minimum, after it has been sent, i.e. the time it is still accepted while a new puzzle is being distributed. Consequently, the actual lifetime of the puzzle is typically in the range ..<2*TTL>, but may, of course, be longer than <2*TTL>. Zero defines the default lifetime, that needs to be decided and documented. How about 128 seconds by default? - Adding an OPTIONAL I2-ACK packet that a Responder MAY send once it has verified the puzzle solution. That packet contains a payload that indicates how long the Initiator SHOULD wait before resending I2. Note that since this packet is not crypto-protected, it can be potentially forged. To require that the potential attacker can't send such packets without being able to eavesdrop the corresponding I2, the packet should reflect pack some part of the I2 being acked, e.g., the puzzle solution payload. To me, the above mechanism seems simple enough, but still potentially helps in some situations. IMHO, we should not go for anything that is much more complex; if someone thinks about something simpler, the better. We still don't know now usual these kinds of congestion situations will be, and therefore need to get some experience. Alternative mechanisms would be good, just to get experience that allows the mechanisms to be compared against each other. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jun 25 08:49:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27347 for ; Fri, 25 Jun 2004 08:49:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 911C7740F; Fri, 25 Jun 2004 07:52:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id 700C5740D for ; Fri, 25 Jun 2004 07:51:05 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1Bdq7X-0001TY-00; Fri, 25 Jun 2004 08:47:55 -0400 From: Tim Shepard To: Pekka Nikander Cc: hipsec@honor.trusecure.com, Thomas R Henderson , Jan Mikael Melen Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism In-reply-to: Your message of Fri, 25 Jun 2004 13:11:32 +0300. <089B79D6-C690-11D8-A936-000393CE1E8C@nomadiclab.com> Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 25 Jun 2004 08:47:55 -0400 Date: Fri, 25 Jun 2004 08:47:55 -0400 Pekka, Thanks for trying to summarize. Missing from your summery is any mention of what we identified as a need for a mechanism for the responder to tell an initiator that even though it has solved the puzzle, it's puzzle solution has been dropped as part of a load shedding at the server. Jake Beal and I found that the responder, in order to defend itself against DOS attacks, will need to implement some sort of persistent dropping mechanism when it needs to shed load by dropping I2s. Otherwise, an attacker (who has control of some zombies which are solving puzzles as fast as they can and pretending to have as many identities as they can) will be motivated to retransmit their puzzle solutions aggressively in an attempt to give their puzzle solutions a better chance of occupying a spot in the server's queue than the legitimate clients. So, when a responder has decided to drop a valid puzzle solution, should we have a mechanism to let the initiator know that this has happened to them? (And can we have such a mechanism without creating yet another DOS vulnerability?) I'm not sure if you deliberately or accidently omitted that mechanism from your summary. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sat Jun 26 06:52:39 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02070 for ; Sat, 26 Jun 2004 06:52:39 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B3B1D7410; Sat, 26 Jun 2004 05:55:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id 8D6F573B5 for ; Sat, 26 Jun 2004 05:54:54 -0400 (EDT) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id D1AD78; Sat, 26 Jun 2004 13:51:53 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Thomas R Henderson , Jan Mikael Melen , Jake Beal , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism To: Tim Shepard X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sat, 26 Jun 2004 13:51:56 +0300 Date: Sat, 26 Jun 2004 13:51:56 +0300 Content-Transfer-Encoding: 7bit > Missing from your summery is any mention of what we identified as a > need for a mechanism for the responder to tell an initiator that even > though it has solved the puzzle, it's puzzle solution has been dropped > as part of a load shedding at the server. I see, but see below. > I'm not sure if you deliberately or accidently omitted that mechanism > from your summary. Well, it definitely wasn't deliberate in the sense that I would have considered that case; I'm sorry that I forgot this aspect. > Jake Beal and I found that the responder, in order to defend itself > against DOS attacks, will need to implement some sort of persistent > dropping mechanism when it needs to shed load by dropping I2s. While I agree with this, I am not sure if it is wise to solve puzzles and *then* drop packets. To me, it seems better to drop packets as early as possible, long before the puzzle solution gets checked. It might be a good idea to allow rate limited ICMP messages to be generated if packets need to be dropped. > Otherwise, an attacker (who has control of some zombies which are > solving puzzles as fast as they can and pretending to have as many > identities as they can) will be motivated to retransmit their puzzle > solutions aggressively in an attempt to give their puzzle solutions a > better chance of occupying a spot in the server's queue than the > legitimate clients. We still have the Appendix D recommendation, which should limit the zombies' possibility to select multiple identities, as the local function f is supposed to be secret and randomly changing. What comes to retransmitting valid puzzle solutions, AFAIK there is no way to initially make a difference between valid clients and zombies who behave like valid clients and generate valid I2. My current gut feeling is that we will need to give a complete revisit to the puzzle mechanism anyway before trying to go to Proposed Standard (if we ever get there). Hence, I am reluctant to device too complex mechanisms at this point of time, before we have any deployment experience. Adding text, especially appendices, to the text is good and fine. But not to complex behaviour. Actually, I would prefer either conference papers or IRTF drafts in this area, preferably with simulations, formal models, or clearly spelled out analysis. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun Jun 27 03:17:44 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06260 for ; Sun, 27 Jun 2004 03:17:43 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B2FE5732A; Sun, 27 Jun 2004 02:20:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id A0CB47311 for ; Sun, 27 Jun 2004 02:19:46 -0400 (EDT) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 35D708; Sun, 27 Jun 2004 10:16:56 +0300 (EEST) In-Reply-To: <40D050EE.8030109@netlab.nec.de> References: <40D050EE.8030109@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] draft-moskowitz-hip-arch expired To: Lars Eggert X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 27 Jun 2004 10:16:55 +0300 Date: Sun, 27 Jun 2004 10:16:55 +0300 Content-Transfer-Encoding: 7bit > just realized that draft-moskowitz-hip-arch-05 has expired. > Is there an update forthcoming? I submitted a new version, currently also available at http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-06.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-06.html --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 28 09:16:52 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03992 for ; Mon, 28 Jun 2004 09:16:51 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A4A297311; Mon, 28 Jun 2004 08:19:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 632A57311 for ; Mon, 28 Jun 2004 08:18:31 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5SDDl53004574; Mon, 28 Jun 2004 07:13:48 -0600 (MDT) Received: from sun.com (dhcp-gnb07-212-228 [129.157.212.228]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i5SDFg201483; Mon, 28 Jun 2004 15:15:42 +0200 (MEST) Message-ID: <40E019D3.8060706@sun.com> From: gabriel montenegro User-Agent: Mozilla Thunderbird 0.5 (Macintosh/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: Tim Shepard , Thomas R Henderson , Jan Mikael Melen , Jake Beal , hipsec@honor.trusecure.com Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 28 Jun 2004 15:14:59 +0200 Date: Mon, 28 Jun 2004 15:14:59 +0200 Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > My current gut feeling is that we will need to give a complete > revisit to the puzzle mechanism anyway before trying to go to > Proposed Standard (if we ever get there). Hence, I am reluctant > to device too complex mechanisms at this point of time, before we > have any deployment experience. Adding text, especially appendices, > to the text is good and fine. But not to complex behaviour. > Actually, I would prefer either conference papers or IRTF drafts > in this area, preferably with simulations, formal models, or > clearly spelled out analysis. Some comments from a lurker's point of view: - The initial observation of different clients having different processing speed have led others to search for work functions which are more egalitarian For example, some memory-bound computations as per: http://www.isoc.org/isoc/conferences/ndss/03/proceedings/papers/2.pdf - Whatever mechanism is chosen, these "proofs of work" are not currently well-enough understood, it seems (implementors may have other comments here). - The cookie puzzle mechanism may have IPR implications. Anybody know? Based on the original publication in NDSS'99 it seems probable. At any rate, this might be an issue for basic HIP. Because of the above, would it be out of the question to simply jettison the cookie puzzle mechanism out of basic HIP and pursue it (and any variants thereof) instead in the research group? The HIP WG could perhaps work on a simpler IKEv2-style DoS protection mechanism. -gabriel _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jun 28 14:29:59 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21148 for ; Mon, 28 Jun 2004 14:29:58 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 979EB7351; Mon, 28 Jun 2004 13:32:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by honor.icsalabs.com (Postfix) with ESMTP id 1FF6E734F for ; Mon, 28 Jun 2004 13:31:09 -0400 (EDT) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 5089E8; Mon, 28 Jun 2004 21:28:25 +0300 (EEST) In-Reply-To: <40E019D3.8060706@sun.com> References: <40E019D3.8060706@sun.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Jake Beal , hipsec@honor.trusecure.com, Tim Shepard , Jan Mikael Melen , Thomas R Henderson From: Pekka Nikander Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism To: gabriel montenegro X-Mailer: Apple Mail (2.618) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 28 Jun 2004 21:28:23 +0300 Date: Mon, 28 Jun 2004 21:28:23 +0300 Content-Transfer-Encoding: quoted-printable > Some comments from a lurker's point of view: Thanks, Gab, for your comments: > - The initial observation of different clients having different=20 > processing > speed have led others to search for work functions which are more=20 > egalitarian > For example, some memory-bound computations as per: > > = http://www.isoc.org/isoc/conferences/ndss/03/proceedings/papers/2.pdf We discussed the memory bound functions briefly after NDSS, but back at that time decided to stick to hash based things. There are also newer results in the queue, to be published somewhere sometime. (Not my papers but papers that I've seen for some reason before publication, and most probably others that I haven't seen.) > - Whatever mechanism is chosen, these "proofs of work" are not=20 > currently > well-enough understood, it seems (implementors may have other comments=20= > here). =46rom an operational point of view, I do agree. > - The cookie puzzle mechanism may have IPR implications. Anybody know?=20= > Based on the > original publication in NDSS'99 it seems probable. At any rate, this=20= > might be > an issue for basic HIP. Good point. However, at least C. Dwork and M. Naor. Pricing via processing or combatting junk mail. In Ernest F. Brickell, editor, CRYPTO =9292, pages 139=96147. Springer- Verlag, 1992. exists, and that may represent prior art. > Because of the above, would it be out of the question to simply=20 > jettison the > cookie puzzle mechanism out of basic HIP and pursue it (and any=20 > variants > thereof) instead in the research group? The HIP WG could perhaps work=20= > on a > simpler IKEv2-style DoS protection mechanism. I think the current cookie mechanism is pretty well thought,=20 simultaneously fairly simple and fairly flexible. IMHO, getting some operational=20 experience would be quite important at this point of time. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 30 03:29:03 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28659 for ; Wed, 30 Jun 2004 03:29:02 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DC2A47305; Wed, 30 Jun 2004 02:31:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id DB44C72F9 for ; Wed, 30 Jun 2004 02:30:20 -0400 (EDT) Received: from n51.nomadiclab.com (n51.nomadiclab.com [131.160.193.51]) by n2.nomadiclab.com (Postfix) with ESMTP id AF558213100; Wed, 30 Jun 2004 10:27:47 +0300 (EEST) From: Jan Mikael Melen To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism User-Agent: KMail/1.6.2 Cc: Pekka Nikander , Thomas R Henderson , Tim Shepard References: <089B79D6-C690-11D8-A936-000393CE1E8C@nomadiclab.com> In-Reply-To: <089B79D6-C690-11D8-A936-000393CE1E8C@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406301027.47373.Jan.Melen@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 30 Jun 2004 10:27:47 +0300 Date: Wed, 30 Jun 2004 10:27:47 +0300 Content-Transfer-Encoding: 7bit Hi, Here is proposed text in a form of context diff (Comments?): diff -c draft-ietf-hip-base-00.xml draft-ietf-hip-base-01-pre1.xml *** draft-ietf-hip-base-00.xml Wed Jun 30 10:17:48 2004 --- draft-ietf-hip-base-01-pre1.xml Wed Jun 30 10:17:48 2004 *************** *** 607,615 **** To generate a proper number J, the Initiator will have to generate a number of Js until one produces the hash target ! of zero. The Initiator SHOULD give up after trying 2^(K+2) ! times, and start over the exchange. (See .) The Responder needs to re-create the concatenation of I, the HITs, and the provided J, and compute the hash once to prove that the Initiator did its assigned task. --- 607,614 ---- To generate a proper number J, the Initiator will have to generate a number of Js until one produces the hash target ! of zero. The Initiator SHOULD give up after exceeding the ! puzzle lifetime received in PUZZLE TLV. The Responder needs to re-create the concatenation of I, the HITs, and the provided J, and compute the hash once to prove that the Initiator did its assigned task. *************** *** 1945,1951 **** +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | K, 1 byte | Opaque, 3 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | --- 1944,1950 ---- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | K, 1 byte | Lifetime | Opaque, 2 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | *************** *** 1954,1974 **** Type 5 Length 12 K K is the number of verified bits Opaque Data set by the Responder, indexing the puzzle Random #I random number ! Random #I is represented as 64-bit integer, K as 8-bit ! integer, all in network byte order. The PUZZLE parameter contains the puzzle difficulty K and an ! 64-bit puzzle random integer #I. A puzzle MAY be augmented ! by including an ECHO_REQUEST parameter to an R1. The ! contents of the ECHO_REQUEST are then echoed back in ! ECHO_RESPONSE, allowing the Responder to use the included information as a part of puzzle processing. --- 1953,1978 ---- Type 5 Length 12 K K is the number of verified bits + Lifetime Puzzle lifetime 2^(value-32) seconds Opaque Data set by the Responder, indexing the puzzle Random #I random number ! Random #I is represented as 64-bit integer, K and Lifetime ! as 8-bit integer, all in network byte order. The PUZZLE parameter contains the puzzle difficulty K and an ! 64-bit puzzle random integer #I. Puzzle Lifetime indicates ! the time during which the puzzle solution is valid and ! sets a time limit for initiator which it should not exceed ! while trying to solve the puzzle. The lifetime is indicated ! as power of 2 using formula 2^(lifetime-32) seconds. A puzzle ! MAY be augmented by including an ECHO_REQUEST parameter to an ! R1. The contents of the ECHO_REQUEST are then echoed back in ! ECHO_RESPONSE, allowing the Responder to use the included information as a part of puzzle processing. *************** *** 1986,1992 **** +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | K, 1 byte | Opaque, 3 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, 8 bytes | | | --- 1990,1996 ---- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | K, 1 byte | Reserved | Opaque, 2 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, 8 bytes | | | *************** *** 1998,2003 **** --- 2002,2008 ---- Type 7 Length 20 K K is the number of verified bits + Reserved zero when sent, ignored when received Opaque Copied unmodified from the received PUZZLE TLV Random #I random number Puzzle solution *************** *** 2735,2740 **** --- 2740,2762 ---- for some policy reason (e.g. received HIT is NULL and policy does not allow opportunistic mode). + SERVER_BUSY_PLEASE_RETRY 44 + + The resonder is unwilling to set up an association + as it is suffering under some kind of overload and + has chosen to shed load by rejecting your request. + You may retry if you wish, however you MUST find + another (different) puzzle solution for any such + retries. Note that you need to obtain a new puzzle + with a new I1/R1 exchange. + + I2_ACKNOWLEDGEMENT 46 + + The responder has received your I2 but had to queue + the I2 for processing. The puzzle was correctly solved + and the responder is willing to set up an association + but has currently a number of I2s in processing queue. + R2 will be sent after the I2 has been processed. NOTIFY MESSAGES - STATUS TYPES Value On Friday 25 June 2004 13:11, Pekka Nikander wrote: > As a summary of the discussion so far, how about > > - Using one byte of the puzzle opaque field to denote > the puzzle lifetime, in exponential seconds notification. > I think the time denoted should be the time that the > puzzle is valid, at minimum, after it has been sent, i.e. > the time it is still accepted while a new puzzle is > being distributed. Consequently, the actual lifetime > of the puzzle is typically in the range ..<2*TTL>, > but may, of course, be longer than <2*TTL>. > > Zero defines the default lifetime, that needs to be > decided and documented. How about 128 seconds by default? > > - Adding an OPTIONAL I2-ACK packet that a Responder MAY > send once it has verified the puzzle solution. That > packet contains a payload that indicates how long > the Initiator SHOULD wait before resending I2. Note that > since this packet is not crypto-protected, it can be > potentially forged. To require that the potential > attacker can't send such packets without being able > to eavesdrop the corresponding I2, the packet should > reflect pack some part of the I2 being acked, e.g., > the puzzle solution payload. > > To me, the above mechanism seems simple enough, but still > potentially helps in some situations. IMHO, we should not > go for anything that is much more complex; if someone thinks > about something simpler, the better. We still don't know > now usual these kinds of congestion situations will be, and > therefore need to get some experience. > > Alternative mechanisms would be good, just to get experience > that allows the mechanisms to be compared against each other. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jun 30 07:53:06 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11531 for ; Wed, 30 Jun 2004 07:53:06 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9AC797305; Wed, 30 Jun 2004 06:55:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by honor.icsalabs.com (Postfix) with ESMTP id 2348E72F9 for ; Wed, 30 Jun 2004 06:54:18 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i5UBpmc7029077; Wed, 30 Jun 2004 07:51:49 -0400 (EDT) Received: from home-on-the-dome.mit.edu (HOME-ON-THE-DOME.MIT.EDU [18.7.16.76]) (authenticated bits=56) (User authenticated as jakebeal@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i5UBpmOm029463; Wed, 30 Jun 2004 07:51:48 -0400 (EDT) Received: (from jakebeal@localhost) by home-on-the-dome.mit.edu (8.12.9) id i5UBpmFg025696; Wed, 30 Jun 2004 07:51:48 -0400 (EDT) Message-Id: <200406301151.i5UBpmFg025696@home-on-the-dome.mit.edu> To: Jan Mikael Melen Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] proposal for a few small changes to puzzle mechanism In-Reply-To: Your message of "Wed, 30 Jun 2004 10:27:47 +0300." <200406301027.47373.Jan.Melen@nomadiclab.com> From: Jake Beal Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 30 Jun 2004 07:51:48 -0400 Date: Wed, 30 Jun 2004 07:51:48 -0400 I only see one small problem, in the definition of the SERVER_BUSY_PLEASE_RETRY message: + SERVER_BUSY_PLEASE_RETRY 44 ... + retries. Note that you need to obtain a new puzzle + with a new I1/R1 exchange. A new I1/R1 exchance is only necessary if the puzzle's timelimit has expired. Otherwise, the initiator can simply continue searching for more solutions to the current puzzle. I would propose changing the language to: + retries. Note that you may need to obtain a new puzzle + with a new I1/R1 exchange. Thanks, -Jake _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec