From hipsec-bounces@lists.ietf.org Fri Sep 01 03:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3dP-0008Sv-Pr; Fri, 01 Sep 2006 03:40:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3dO-0008Sq-6H for hipsec@ietf.org; Fri, 01 Sep 2006 03:40:14 -0400 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ3dM-0001W3-QV for hipsec@ietf.org; Fri, 01 Sep 2006 03:40:14 -0400 Received: from [192.168.1.103] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 44F4DD83001D498B; Fri, 1 Sep 2006 09:39:31 +0200 From: Julien Laganier To: Andrei Gurtov Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-rvs-05.txt Date: Fri, 1 Sep 2006 09:39:52 +0200 User-Agent: KMail/1.8.2 References: <44E5D045.4040003@cs.helsinki.fi> In-Reply-To: <44E5D045.4040003@cs.helsinki.fi> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <200609010939.52669.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Andrei, That's a bug in the draft, should be MUST in both places. Will fix it in next rev. Thanks. --julien On Friday 18 August 2006 16:35, Andrei Gurtov wrote: > Hi, > > I would like to ask if VIA parameter is mandatory or not. Currently > the draft seems not clear on this, the first paragraph tells that > responder may include addresses, while second tells it must do so > > After the responder receives a relayed I1 packet, it can begin to > send HIP packets addressed to the initiator's IP address, > without further assistance from an RVS. For debugging purposes, it > MAY include a subset of the IP addresses of its RVSs in some of > these packets. When a responder does so, it MUST append a newly > created VIA_RVS parameter at the end of the HIP packet. > > > When a responder replies to an I1 relayed via an RVS, it MUST > append to the regular R1 header a VIA_RVS parameter containing the > IP addresses of the traversed RVS's. > > > > Andrei > > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. This draft is a work item of the > > Host Identity Protocol Working Group of the IETF. > > > > Title : Host Identity Protocol (HIP) Rendezvous Extension > > Author(s) : J. Laganier, L. Eggert > > Filename : draft-ietf-hip-rvs-05.txt > > Pages : 15 > > Date : 2006-6-7 > > > > This document defines a rendezvous extension for the Host > > Identity Protocol (HIP). The rendezvous extension extends HIP > > and the HIP registration extension for initiating communication > > between HIP nodes via HIP rendezvous servers. Rendezvous servers > > improve reachability and operation when HIP nodes are multi-homed > > or mobile. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-05.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-rvs-05.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-rvs-05.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. > > > > ----------------------------------------------------------------- > >------- > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 01 04:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ4Bt-0005Ro-Ca; Fri, 01 Sep 2006 04:15:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ4Bs-0005RF-2B for hipsec@ietf.org; Fri, 01 Sep 2006 04:15:52 -0400 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ4Bp-00066n-Dt for hipsec@ietf.org; Fri, 01 Sep 2006 04:15:51 -0400 Received: from [192.168.1.103] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 44F4DD740016F4AE; Fri, 1 Sep 2006 10:15:44 +0200 From: Julien Laganier To: hipsec@ietf.org Date: Fri, 1 Sep 2006 10:16:04 +0200 User-Agent: KMail/1.8.2 References: <44E5D045.4040003@cs.helsinki.fi> <200609010939.52669.julien.IETF@laposte.net> In-Reply-To: <200609010939.52669.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609011016.05081.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: Subject: [Hipsec] VIA_RVS parameter (Was: I-D ACTION:draft-ietf-hip-rvs-05.txt) X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, [ Sorry to reply to myself, I shot too fast ] The initial requirement keyword for VIA_RVS was MAY as it's been thought as a debugging tool, but then Pekka suggested that it should be a MUST so that it can be used to mitigate possible reflection attacks [1]. Because that was then the consensus in the working group I changed the requirement keyword but kept the text as is. I now think the text should be changed to reflect the real intent. I propose the following: After the responder receives a relayed I1 packet, it can begin to send HIP packets addressed to the initiator's IP address, without further assistance from an RVS. Because in that case the R1 is sent to a different address than what I1 was received from, the responder MUST include the source address of the I1 as the first address in a VIA_RVS parameter included in the R1. This is meant to avoid introducing opportunities for certain kind of reflection attacks. For debugging purposes, the responder MAY also include a subset of the IP addresses of its RVSs as additional addresses in the VIA_RVS parameter. To do so, the responder MUST append a newly created VIA_RVS parameter at the end of the HIP packet. Does the WG agree? Another related question is that the current VIA_RVS parameter has been placed intentionally after the SIG parameter so that it it's never signed. The rationale behind that was, when multiple RVSs are cascaded, to allow intermediate RVS's to include the IP address of the upstream RVS in I1s so that it's not lost. The current draft doesnn't have anymore provision for cascaded RVS, so I thought that it would be better to place VIA_RVS before SIG so that it's signed. What do you think? Best, --julien [1] http://www1.ietf.org/mail-archive/web/hipsec/current/msg01435.html On Friday 01 September 2006 09:39, Julien Laganier wrote: > Hi Andrei, > > That's a bug in the draft, should be MUST in both places. Will fix > it in next rev. > > Thanks. > > --julien > > On Friday 18 August 2006 16:35, Andrei Gurtov wrote: > > Hi, > > > > I would like to ask if VIA parameter is mandatory or not. > > Currently the draft seems not clear on this, the first paragraph > > tells that responder may include addresses, while second tells it > > must do so > > > > After the responder receives a relayed I1 packet, it can begin to > > send HIP packets addressed to the initiator's IP address, > > without further assistance from an RVS. For debugging purposes, > > it MAY include a subset of the IP addresses of its RVSs in some > > of these packets. When a responder does so, it MUST append a > > newly created VIA_RVS parameter at the end of the HIP packet. > > > > > > When a responder replies to an I1 relayed via an RVS, it MUST > > append to the regular R1 header a VIA_RVS parameter containing > > the IP addresses of the traversed RVS's. > > > > > > > > Andrei > > > > Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. This draft is a work item of the > > > Host Identity Protocol Working Group of the IETF. > > > > > > Title : Host Identity Protocol (HIP) Rendezvous Extension > > > Author(s) : J. Laganier, L. Eggert > > > Filename : draft-ietf-hip-rvs-05.txt > > > Pages : 15 > > > Date : 2006-6-7 > > > > > > This document defines a rendezvous extension for the Host > > > Identity Protocol (HIP). The rendezvous extension extends HIP > > > and the HIP registration extension for initiating communication > > > between HIP nodes via HIP rendezvous servers. Rendezvous > > > servers improve reachability and operation when HIP nodes are > > > multi-homed or mobile. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-05.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-rvs-05.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-rvs-05.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. > > > > > > --------------------------------------------------------------- > > >-- ------- > > > > > > _______________________________________________ > > > Hipsec mailing list > > > Hipsec@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 01 07:44:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7R2-00036E-H0; Fri, 01 Sep 2006 07:43:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7OF-0000oE-4J for hipsec@ietf.org; Fri, 01 Sep 2006 07:40:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ5Nt-0002hX-EY for hipsec@ietf.org; Fri, 01 Sep 2006 05:32:21 -0400 Received: from mx.laposte.net ([81.255.54.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GJ59t-0003aE-Bc for hipsec@ietf.org; Fri, 01 Sep 2006 05:17:55 -0400 Received: from [192.168.1.103] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 44F4DD6E0017866B; Fri, 1 Sep 2006 11:16:36 +0200 From: Julien Laganier To: Andrei Gurtov Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-dns-06.txt Date: Fri, 1 Sep 2006 11:16:56 +0200 User-Agent: KMail/1.8.2 References: <44E18DC5.8060400@cs.helsinki.fi> In-Reply-To: <44E18DC5.8060400@cs.helsinki.fi> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200609011116.56522.julien.IETF@laposte.net> X-Spam-Score: -2.6 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Andrei, On Tuesday 15 August 2006 11:03, Andrei Gurtov wrote: > In the next revision it would be good to update DNSSEC refs to > RFC4033-RFC4035. Will do. > How about simultaneous query of A and HIP RR? It might be useful to > save some RTTs, but it doesn't seem explicitly described. The way queries are issued is implementation dependent. The description of how queries are issued is only illustrative (note the absence of requirement keywords and the use of the 'typically' adverb.) Do you think we need additional text? > What about storing multiple HIs per a host? Is it done using > several HIP RRs? Yes; this is not specific to HIP but generic to DNS usage: when multiple information of the same type have to be stored, multiple RRs are used. Examples includes A, AAAA, MX, etc. Do you think we need additional text? Best, --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 04 03:26:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK8pX-0007vg-6s; Mon, 04 Sep 2006 03:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIT09-0007ne-7B for hipsec@ietf.org; Wed, 30 Aug 2006 12:33:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIT08-0007WS-VA for hipsec@ietf.org; Wed, 30 Aug 2006 12:33:17 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GISt1-0003gK-IQ for hipsec@ietf.org; Wed, 30 Aug 2006 12:25:56 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 762EDE00C0; Wed, 30 Aug 2006 12:25:57 -0400 (EDT) From: Sam Hartman To: Mark Townsley Subject: Re: [Hipsec] draft-ietf-hip-esp-03 References: <44EABD76.50100@cisco.com> <44EEA3D5.3080505@nomadiclab.com> <44F5B894.6090108@cisco.com> Date: Wed, 30 Aug 2006 12:25:57 -0400 In-Reply-To: <44F5B894.6090108@cisco.com> (Mark Townsley's message of "Wed, 30 Aug 2006 18:11:00 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.5 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Mon, 04 Sep 2006 03:25:13 -0400 Cc: hipsec@ietf.org, Russ Housley , hip-chairs@tools.ietf.org, jan.melen@nomadiclab.com X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org >>>>> "Mark" == Mark Townsley writes: Mark> It sounds like this addresses the concern in terms of "truth Mark> in advertising" here, and I am very glad to see this as it Mark> is certainly important. I wonder if the IPsec community will Mark> have architectural issues with SPIs being attached to Mark> specific processing above the IP stack (depending, I Mark> suppose, on where you consider HIP, IP, and IPsec in Mark> relation to one another). I remember somewhat similar cases Mark> in the past causing serious heartburn within the IPsec Mark> community. I actually saw a copy of the new section 3.4 before it was posted to the list (or at the same time). I think the best thing to do at this point is to run it by the IPsec community either by asking for secdir reviews or by sending to the old ipsec list. I actually suspect you get more comments of the form "you said things the wrong way," than "you did things that must not be done. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 14 10:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrur-000086-5v; Thu, 14 Sep 2006 10:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrup-0008SL-Kj for hipsec@ietf.org; Thu, 14 Sep 2006 10:10:07 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNruo-0002ll-DF for hipsec@ietf.org; Thu, 14 Sep 2006 10:10:07 -0400 Received: by py-out-1112.google.com with SMTP id e30so2836099pya for ; Thu, 14 Sep 2006 07:10:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-disposition:content-type:content-transfer-encoding:message-id:sender; b=j8+493E1FZYCMmqq9LTVT12mvTLnWChurls2SHCV82bcwBzCyCA7dOliVS5TyY7BABGKJnTnK1kjJHT6a0qtIrGSamzyVKwvfhru9YyUoA99YNQzzaqbaLjMFBfaxf0ywttSw5EPg1eUePF7QsuQwzBAyb8fdN9I3UuIpQehomI= Received: by 10.35.53.18 with SMTP id f18mr15079875pyk; Thu, 14 Sep 2006 07:10:05 -0700 (PDT) Received: from ?192.168.50.196? ( [83.236.145.130]) by mx.gmail.com with ESMTP id 8sm1674583nzn.2006.09.14.07.10.05; Thu, 14 Sep 2006 07:10:05 -0700 (PDT) From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] VIA_RVS parameter (Was: I-D ACTION:draft-ietf-hip-rvs-05.txt) Date: Thu, 14 Sep 2006 16:10:43 +0200 User-Agent: KMail/1.8.2 References: <200609010939.52669.julien.IETF@laposte.net> <200609011016.05081.julien.IETF@laposte.net> In-Reply-To: <200609011016.05081.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <200609141610.44020.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, So far I received no response to the message below, so I assume that consensus is: - to use the new text regarding requirement level of VIA_RVS - to keep the existing VIA_RVS parameter placement (i.e. after SIG) --julien On Friday 01 September 2006 10:16, Julien Laganier wrote: > > The initial requirement keyword for VIA_RVS was MAY as it's been > thought as a debugging tool, but then Pekka suggested that it > should be a MUST so that it can be used to mitigate possible > reflection attacks [1]. Because that was then the consensus in the > working group I changed the requirement keyword but kept the text > as is. I now think the text should be changed to reflect the real > intent. I propose the following: > > After the responder receives a relayed I1 packet, it can begin > to send HIP packets addressed to the initiator's IP address, > without further assistance from an RVS. Because in that case the > R1 is sent to a different address than what I1 was received from, > the responder MUST include the source address of the I1 as the > first address in a VIA_RVS parameter included in the R1. This is > meant to avoid introducing opportunities for certain kind of > reflection attacks. For debugging purposes, the responder MAY also > include a subset of the IP addresses of its RVSs as additional > addresses in the VIA_RVS parameter. To do so, the responder MUST > append a newly created VIA_RVS parameter at the end of the HIP > packet. > > Does the WG agree? > > Another related question is that the current VIA_RVS parameter has > been placed intentionally after the SIG parameter so that it it's > never signed. The rationale behind that was, when multiple RVSs are > cascaded, to allow intermediate RVS's to include the IP address of > the upstream RVS in I1s so that it's not lost. The current draft > doesnn't have anymore provision for cascaded RVS, so I thought that > it would be better to place VIA_RVS before SIG so that it's signed. > > What do you think? > > -- julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 14 14:20:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNvoa-0002Mo-VR; Thu, 14 Sep 2006 14:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNvoa-0002ML-2e for hipsec@ietf.org; Thu, 14 Sep 2006 14:19:56 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNvoW-0001p0-Os for hipsec@ietf.org; Thu, 14 Sep 2006 14:19:56 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id E88ED31C8; Thu, 14 Sep 2006 21:19:49 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.4-niksula20060712 (2006-07-25) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.4-niksula20060712 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 815BD315D; Thu, 14 Sep 2006 21:19:49 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id k8EIJmAT026048; Thu, 14 Sep 2006 21:19:49 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Thu, 14 Sep 2006 21:19:48 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: [Hipsec] VIA_RVS parameter (Was: I-D ACTION:draft-ietf-hip-rvs-05.txt) In-Reply-To: <200609141610.44020.julien.IETF@laposte.net> Message-ID: References: <200609010939.52669.julien.IETF@laposte.net> <200609011016.05081.julien.IETF@laposte.net> <200609141610.44020.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 14 Sep 2006, Julien Laganier wrote: > Folks, > > So far I received no response to the message below, so I assume that > consensus is: > > - to use the new text regarding requirement level of VIA_RVS > - to keep the existing VIA_RVS parameter placement (i.e. after SIG) This seems to be fine IMHO. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 19 19:24:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPow1-0005jt-UM; Tue, 19 Sep 2006 19:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPow1-0005jm-2R for hipsec@ietf.org; Tue, 19 Sep 2006 19:23:25 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPovx-0006do-Ov for hipsec@ietf.org; Tue, 19 Sep 2006 19:23:25 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k8JNNKF9024437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Sep 2006 18:23:21 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k8JNNKcx028496 for ; Tue, 19 Sep 2006 16:23:20 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k8JNNK5A028479; Tue, 19 Sep 2006 16:23:20 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 16:23:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] VIA_RVS parameter (Was: I-DACTION:draft-ietf-hip-rvs-05.txt) Date: Tue, 19 Sep 2006 16:23:17 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F6EC@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <200609011016.05081.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] VIA_RVS parameter (Was: I-DACTION:draft-ietf-hip-rvs-05.txt) Thread-Index: AcbNnuRzwxF2zVJNTUKdFzJ8JLM+tAOoI8jQ From: "Henderson, Thomas R" To: "Julien Laganier" , X-OriginalArrivalTime: 19 Sep 2006 23:23:17.0907 (UTC) FILETIME=[96970630:01C6DC42] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org sorry for the late reply > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net]=20 > Sent: Friday, September 01, 2006 1:16 AM > To: hipsec@ietf.org > Subject: [Hipsec] VIA_RVS parameter (Was:=20 > I-DACTION:draft-ietf-hip-rvs-05.txt) >=20 > Folks, >=20 > [ Sorry to reply to myself, I shot too fast ] >=20 > The initial requirement keyword for VIA_RVS was MAY as it's been=20 > thought as a debugging tool, but then Pekka suggested that it should=20 > be a MUST so that it can be used to mitigate possible reflection=20 > attacks [1]. Because that was then the consensus in the working group=20 > I changed the requirement keyword but kept the text as is. I now=20 > think the text should be changed to reflect the real intent. I=20 > propose the following: >=20 > After the responder receives a relayed I1 packet, it can begin to > send HIP packets addressed to the initiator's IP address, without > further assistance from an RVS. Because in that case the R1 is > sent to a different address than what I1 was received from, the > responder MUST include the source address of the I1 as the first > address in a VIA_RVS parameter included in the R1. This is meant > to avoid introducing opportunities for certain kind of reflection > attacks. For debugging purposes, the responder MAY also include a > subset of the IP addresses of its RVSs as additional addresses in > the VIA_RVS parameter. To do so, the responder MUST append a newly > created VIA_RVS parameter at the end of the HIP packet. >=20 > Does the WG agree? - I would clarify "source address of the RVS-relayed I1" instead of "source address of the I1" - As presently defined, I do not know what these "other addresses in the VIA_RVS" would be. I think this text is left over from cascading RVS use case. I recommend to either delete or clarify what these multiple addresses may be. >=20 > Another related question is that the current VIA_RVS parameter has=20 > been placed intentionally after the SIG parameter so that it it's=20 > never signed. The rationale behind that was, when multiple RVSs are=20 > cascaded, to allow intermediate RVS's to include the IP address of=20 > the upstream RVS in I1s so that it's not lost. The current draft=20 > doesnn't have anymore provision for cascaded RVS, so I thought that=20 > it would be better to place VIA_RVS before SIG so that it's signed.=20 > What do you think? >=20 I think that including VIA_RVS within signature range works against the goal of being able to generate presigned R1s, so I would prefer to leave it outside. Other comments: - the draft is a bit unclear how to handle the FROM parameter in Section 4.3.2 (that the R1 MUST use the address in the first FROM parameter as the destination IP address for the R1). - In section 4.3.4, it is stated: In case the IP addresses are also checked, then the source IP address MUST be checked against the IP address included in the VIA_RVS parameter. I think that this should say: In case the IP addresses are also checked, then the destination IP address of the original I1 MUST be checked against one of the addresses included in the VIA_RVS parameter. or else I am misunderstanding something. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 22 02:56:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQewM-0000Qn-KS; Fri, 22 Sep 2006 02:55:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQewL-0000Qf-6T; Fri, 22 Sep 2006 02:55:13 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQewK-0002nd-94; Fri, 22 Sep 2006 02:55:13 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k8M6t6ha028804; Fri, 22 Sep 2006 09:55:06 +0300 Date: Fri, 22 Sep 2006 09:55:06 +0300 (EEST) From: Pekka Savola To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.4/1923/Fri Sep 22 03:09:13 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_50, NO_RELAYS autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: hipsec@ietf.org Subject: [Hipsec] Re: Last Call: 'Host Identity Protocol' to Experimental RFC (draft-ietf-hip-base) X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 31 Aug 2006, The IESG wrote: > The IESG has received a request from the Host Identity Protocol WG to > consider the following document: > > - 'Host Identity Protocol ' > as an Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-14. Sorry for being late with comments. I mainly reviewed the first sections of the spec. I think there are some major issues with IANA considerations section and the use of IPv6-compatible addresses (at least) which require revising the specification. R1 generation counter design should also be (IMHO) reconsidered. See below. substantial ----------- Finally, HIP is designed as an end-to-end authentication and key establishment protocol, to be used with Encapsulated Security Payload (ESP) [24] and other end-to-end security protocols. The base protocol lacks the details for security association management and much of the fine-grained policy control found in Internet Key Exchange IKE RFC2409 [7] that allows IKE to support complex gateway policies. Thus, HIP is not a replacement for IKE. ==> I do not think this paragraph is entirely clear about the role of HIP wrt. IKE. Does this mean that as "base protocol lacks the details for SA management..." that IKE must be used on conjuntion with HIP to manage the SAs? Or that if additional SA management features are deemed necessary, IKE must be used in addition to HIP? I suspect you mean the latter, but the language should be more explicit on this. Current wording raises a question whether the SA management in HIP has been adequately specified if it "lacks the details". ==> s/IKE/(IKE)/ 4 The protocol number for Host Identity Protocol will be assigned by IANA. For testing purposes, the protocol number 253 is currently used. This number has been reserved by IANA for experimental use (see [19]). but IANA considerations section says: This document specifies the IP protocol number 253 to be used with Host Identity Protocol during the experimental phase. This number has been reserved by IANA for experimental use (see [19]. ==> 'reserving' 253 out of the experimental space. I think the experimental values are supposed to be used in pre-RFC trials, and codifying a value in an RFC goes goes against [19]. IMHO, you should request a new protocol value (using IESG Approval process) and give proper instructions to IANA. 4.1.4 The R1 generation counter is a monotonically increasing 64-bit counter that may be initialized to any value. The scope of the counter MAY be system-wide but SHOULD be per host identity, if there is more than one local host identity. The value of this counter SHOULD be kept across system reboots and invocations of the HIP base exchange. ==> What if the R1 generation counter is NOT kept across system reboots? I'd generally expect that to be the case, and I'd be happier if this was downgraded to a MAY so that this mode of interoperability would also be better tested. Also, the R1 generation counter MUST NOT roll over; if the counter is about to become exhausted, the corresponding HI must be abandoned and replaced with a new one. ==> So, you're required to create a new public key if R1 rolls over, you don't store it in the disk during reboot, etc.? As this creates requirements on the use of HIs, this would need to be spelled out better. I'd also actively encourage against this kind of design per above. A host may receive more than one R1, either due to sending multiple I1s (Section 6.6.1) or due to a replay of an old R1. When sending multiple I1s, an initiator SHOULD wait for a small amount of time after the first R1 reception to allow possibly multiple R1s to arrive, and it SHOULD respond to an R1 among the set with the largest R1 generation counter. ==> "a small amount of time" is very subjective; it could be milliseconds to some, dozens of seconds or even minutes to others. Does this have implementation/interoperability implications? 5.2.1 The parameters MUST be included in the packet such that their types form an increasing order. If the order does not follow this rule, the packet is considered to be malformed and it MUST be discarded. ==> does "increasing order" allow you to send the same option number multiple times or not? This was discussed at the IETF list some months ago... :-) All of the TLV parameters have a length (including Type and Length fields) which is a multiple of 8 bytes. When needed, padding MUST be added to the end of the parameter so that the total length becomes a multiple of 8 bytes. This rule ensures proper alignment of data. If padding is added, the Length field MUST NOT include the padding. ==> I must be missing something. If padding is added according to the abovementioned text, adding the padding (up to the next 64 bit boundary) doesn't change the Length field -- so I'm not sure what the last sentence is saying ? I think protocol design shouldn't be such that there is more data (even if it's padding) that goes beyond the length field. 8 Denial-of-service attacks take advantage of the cost of start of state for a protocol on the Responder compared to the 'cheapness' on the Initiator. ==> insert "often" before "take advantage". By definition, DoS attack does not need to rely on the cost at the start. Above attack was commonplace 5 years ago, now with botnets the evolution has been towards more classical "flash crowd" attacks. 9 The type codes 32768 through 49141 are reserved for experimentation and private use. Types SHOULD be selected in a random fashion from this range, thereby reducing the probability of collisions. A method employing genuine randomness (such as flipping a coin) SHOULD be used. ==> randomization is not good enough here. Remember that half of the values imply Critical bit being set. So, the requestor should indicate whether (s)he wants a value that has a critical bit set or not, right? There should be some IANA guidance on this. ==> By the way, do we even want to allow non-reviewed critical bit usage? Appendix C. Example Checksums for HIP Packets The HIP checksum for HIP packets is specified in Section 6.1.2. Checksums for TCP and UDP packets running over HIP-enabled security associations are specified in Section 3.5. The examples below use IP addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4- compatible IPv6 formats), and HITs with the first two bits "01" followed by 124 zeroes followed by a decimal 1 or 2, respectively. C.1. IPv6 HIP Example (I1) Source Address: ::192.168.0.1 Destination Address: ::192.168.0.2 ... ==> first of all, section 6.1.2 does not exist (anymore), maybe you were referring to 5.1.1 ? ==> second, I don't think I found in 5.1.1 or elsewhere any specification why you used IPv4-compatible IPv6 format here. Is that a pseudo-header representation of an IPv4 address? If so, it should probably be a mapped address (::ffff:a.b.c.d) instead as the compatible address has been deprecated and was used in tunneling. editorial --------- abstract Discussion related to this document is going on at the IETF HIP Working Group mailing list. ==> this should probably be removed prior to RFC publication. 1.1 There are two main representations of the Host Identity, the full Host Identifier (HI) and the Host Identity Tag (HIT The HI is a public key and directly represents the Identity. ==> missing ")." after HIT ? Exchange Complete (EC): Time that the host spends at the R2-SENT before it moves to ESTABLISHED state. The time is n * I2 retransmission timeout, where n ~ I2_RETRIES_MAX. ==> what do you mean by "n ~ .." notation ? For example, if ESP is used to protect data traffic, the Security Parameter Index (SPI) carried in the ESP header, can be used to map the encrypted data packet to the correct HIP association. ==> s/header,/header/ 4.1.2 Responder remembers an old puzzle at least 2*lifetime seconds after it has been deprecated. ==> does 'lifetime' refer to the field defined in 5.2.4? If so, maybe it should be written as "Lifetime" or the like.. | HMAC | 61505 | variable | HMAC based message | | | | | authentication code, with | | | | | key material from | | | | | HIP_TRANSFORM | | | | | | | HMAC_2 | 61569 | variable | HMAC based message | | | | | authentication code, with | | | | | key material from | | | | | HIP_TRANSFORM | ==> you should probably note the HMAC/HMAC_2 difference in this table (i.e., HMAC_2 includes HOST_ID) to aid readability. 9 This document also creates a set of new name spaces. These are described below. Packet Type ==> should this be called "HIP Packet Type" ? In the early times of this draft, John Gilmore kept Bob Moskowitz challenged to provide something of value. ==> reword "draft" to "document" or some such ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 22 03:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfjD-0003kC-5V; Fri, 22 Sep 2006 03:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfjB-0003k4-To; Fri, 22 Sep 2006 03:45:41 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQfj9-0003yr-Bi; Fri, 22 Sep 2006 03:45:41 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DAB63212C61; Fri, 22 Sep 2006 10:45:26 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 43187212C4C; Fri, 22 Sep 2006 10:45:26 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Re: Last Call: 'Host Identity Protocol' to Experimental RFC (draft-ietf-hip-base) Date: Fri, 22 Sep 2006 10:45:18 +0300 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: hipsec@ietf.org, iesg@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Pekka, Thanks for your review. I am responding only to your concerns about R1 generation counter design and private parameter types. I cannot comment your IANA considerations since I am not familiar enough with IANA considerations. Finally, IMHO, most of your comments seem to be caused by the text not being clear enough and mainly requiring only rewordings or clarifications. >> 4.1.4 >> The R1 generation counter is a monotonically increasing 64-bit >> counter that may be initialized to any value. The scope of the >> counter MAY be system-wide but SHOULD be per host identity, if >> there >> is more than one local host identity. The value of this counter >> SHOULD be kept across system reboots and invocations of the HIP >> base >> exchange. > > ==> What if the R1 generation counter is NOT kept across system > reboots? > I'd generally expect that to be the case, and I'd be happier if > this was > downgraded to a MAY so that this mode of interoperability would > also be > better tested. If you don't keep your R1 generation counter, your open up your peers to R1 replay attacks. What an R1 replay attack may cause is that under an active attack the Initiator may solve a wrong puzzle, causing the communication to fail. I would not consider that a big problem, though. The idea of generation counters is to plug that problem to those hosts that do have stable storage. So, basically, the reason for the current wording is that we wanted to allow devices that have no stable storage at all, i.e., ROM-only devices. If that was not the concern, the second SHOULD would be a MUST. >> Also, the R1 generation counter MUST NOT roll over; if >> the counter is about to become exhausted, the corresponding HI >> must >> be abandoned and replaced with a new one. > > ==> So, you're required to create a new public key if R1 rolls > over, you > don't store it in the disk during reboot, etc.? No, or at least that is not the intention. The intention is to only require a new public key to be created if you do keep the generation counter on the disk and it does roll over. Again, this is related to the desire to support ROM-only devices. > As this creates requirements on the use of HIs, this would need to be > spelled out better. I'd also actively encourage against this kind of > design per above. I don't understand how it creates requirements to the use of HIs. Personally, I would not care too much about ROM-only devices, and therefore I'd be willing to change the spec to require the gen counter to be always committed to stable storage. On the other hand, opening one's peers to R1 replay attacks may not be that big a problem. Besides, IIRC, the spec allows the peers to protect themselves iff they know that a given host does implement genuinely increasing generation counter. >> A host may receive more than one R1, either due to sending >> multiple >> I1s (Section 6.6.1) or due to a replay of an old R1. When sending >> multiple I1s, an initiator SHOULD wait for a small amount of time >> after the first R1 reception to allow possibly multiple R1s to >> arrive, and it SHOULD respond to an R1 among the set with the >> largest >> R1 generation counter. > > ==> "a small amount of time" is very subjective; it could be > milliseconds to > some, dozens of seconds or even minutes to others. Does this have > implementation/interoperability implications? "small amount of time" depends your expected RTT and other network considerations. Basically, how long would you expect it take to any replies to arrive. Maybe a sentence stating something like "A reasonable value may be 2 * expected RTT." However, that would still have the problem of estimating the RTT, which may be very hard. On the other hand, I don't see any direct interoperability implications. Having a small value (even zero) only increases the probability that the receiver may solve a stale puzzle. Having a too large value increases the probability that the puzzle may become stale while being solved. >> 9 >> The type codes 32768 through 49141 are reserved for >> experimentation and private use. Types SHOULD be selected in a >> random fashion from this range, thereby reducing the >> probability >> of collisions. A method employing genuine randomness (such as >> flipping a coin) SHOULD be used. > > ==> randomization is not good enough here. Why? > Remember that half of the values imply Critical bit being set. > So, the requestor should indicate whether (s)he wants a value > that has a critical bit set or not, right? Yes. If the sender wants the receiver to abandon the negotiation if it doesn't understand the parameter, the design should pick a critical parameter. > There should be some IANA guidance on this. Why? > ==> By the way, do we even want to allow non-reviewed critical bit > usage? Now I don't understand your thinking at all. --Pekka Nikander _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 22 04:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQg3o-0004SW-PY; Fri, 22 Sep 2006 04:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQg3n-0004SN-LI; Fri, 22 Sep 2006 04:06:59 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQg3m-0006nV-VS; Fri, 22 Sep 2006 04:06:59 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k8M86tMt030992; Fri, 22 Sep 2006 11:06:55 +0300 Date: Fri, 22 Sep 2006 11:06:55 +0300 (EEST) From: Pekka Savola To: Pekka Nikander Subject: Re: [Hipsec] Re: Last Call: 'Host Identity Protocol' to Experimental RFC (draft-ietf-hip-base) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.4/1923/Fri Sep 22 03:09:13 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL, BAYES_40, NO_RELAYS autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: hipsec@ietf.org, iesg@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 22 Sep 2006, Pekka Nikander wrote: > If you don't keep your R1 generation counter, your open up your peers to > R1 replay attacks. What an R1 replay attack may cause is that under an > active attack the Initiator may solve a wrong puzzle, causing the > communication to fail. I would not consider that a big problem, though. > The idea of generation counters is to plug that problem to those hosts > that do have stable storage. To clarify, I didn't see this attack as a big problem, hence I do not see the sufficiently clear justification for stable storage requirement and related complexity. Very few IETF protocols require or recommend (in uppercase) stable storage and IMHO such protocol design choices need more careful examination. >> ==> So, you're required to create a new public key if R1 rolls over, you >> don't store it in the disk during reboot, etc.? > > No, or at least that is not the intention. The intention is to only > require a new public key to be created if you do keep the generation > counter on the disk and it does roll over. Again, this is related to > the desire to support ROM-only devices. ... > I don't understand how it creates requirements to the use of HIs. So, if you happen to have an implementation bug, for example, which would jump the generation counter forward too much so that it would need to be rolled over, you'd need to regenerate your keys. This doesn't sound too userfriendly. I keep wondering why a typical counter that can roll over could not sufficiently protect from a replay attack. >>> 9 >>> The type codes 32768 through 49141 are reserved for >>> experimentation and private use. Types SHOULD be selected in a >>> random fashion from this range, thereby reducing the probability >>> of collisions. A method employing genuine randomness (such as >>> flipping a coin) SHOULD be used. >> >> ==> randomization is not good enough here. > > Why? > >> Remember that half of the values imply Critical bit being set. >> So, the requestor should indicate whether (s)he wants a value >> that has a critical bit set or not, right? > > Yes. If the sender wants the receiver to abandon the negotiation > if it doesn't understand the parameter, the design should pick > a critical parameter. > >> There should be some IANA guidance on this. > > Why? The IANA cannot just randomize a number. It at the very least, it needs to randomize a number, and then to keep it as it is or add or subtract one, depending on whether the requestor wants a Critical bit to be set or not. >> ==> By the way, do we even want to allow non-reviewed critical bit usage? > > Now I don't understand your thinking at all. As the lack of support for the critical bit option stops the HIP exchange, those option numbers should be designed and deployed with more care than non-critical options. Whether IETF review helps (or is the right way) to ensure this is probably a matter of opinion (and I don't have a strong one myself). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 22 04:27:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQgNY-0003wc-FX; Fri, 22 Sep 2006 04:27:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQgNX-0003vY-6I; Fri, 22 Sep 2006 04:27:23 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQgNV-0002Hj-ML; Fri, 22 Sep 2006 04:27:23 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DEEA9212C4C; Fri, 22 Sep 2006 11:27:20 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 73529212C3D; Fri, 22 Sep 2006 11:27:20 +0300 (EEST) Message-ID: <45139E55.1000602@nomadiclab.com> Date: Fri, 22 Sep 2006 11:27:01 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Re: Last Call: 'Host Identity Protocol' to Experimental RFC (draft-ietf-hip-base) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: hipsec@ietf.org, iesg@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, and thanks Pekka (S) for reviewing the document! Pekka Nikander wrote: > Pekka, > >>> 9 >>> The type codes 32768 through 49141 are reserved for >>> experimentation and private use. Types SHOULD be selected in a >>> random fashion from this range, thereby reducing the probability >>> of collisions. A method employing genuine randomness (such as >>> flipping a coin) SHOULD be used. >> >> ==> randomization is not good enough here. > > Why? > >> Remember that half of the values imply Critical bit being set. >> So, the requestor should indicate whether (s)he wants a value >> that has a critical bit set or not, right? > > Yes. If the sender wants the receiver to abandon the negotiation > if it doesn't understand the parameter, the design should pick > a critical parameter. The randomization (in my mind) would mean that implementor selects first if the new parameter is critical or not and then selects the type value randomly from the available (half of the original) area. Maybe this requires a small clarification in the text. >> There should be some IANA guidance on this. > > Why? > >> ==> By the way, do we even want to allow non-reviewed critical bit usage? > > Now I don't understand your thinking at all. If I understand correctly, the HIP document is currently in line with the following: http://ietfreport.isoc.org/idref/rfc3692/ When using the type values from the area reserved for testing there should be no restrictions. These parameter type values are not used in standards compliant implementations in the network and implementations in general should not accept parameters with these values. If this parameter area for testing is not specified (including critical parameter values), implementors will then pick other values for testing anyway (which is bad). Once these new parameters have gone through the normal IETF process (with discussions about critical/non-critical issues), a "real" parameter type value is reserved for them. Petri -- Petri Jokela e-mail: petri.jokela@nomadiclab.com Research Scientist phone: +358 9 299 2413 Ericsson Research, NomadicLab mobile: +358 44 299 2413 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 22 06:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQiRX-0003FD-1b; Fri, 22 Sep 2006 06:39:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQiRV-0003F3-Sp; Fri, 22 Sep 2006 06:39:37 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQiRV-0001rj-7E; Fri, 22 Sep 2006 06:39:37 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 915D5212C4C; Fri, 22 Sep 2006 13:39:35 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 274AC212C3D; Fri, 22 Sep 2006 13:39:35 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2ABE5CD7-607C-4AC5-9234-E893DDEE4BF6@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Re: Last Call: 'Host Identity Protocol' to Experimental RFC (draft-ietf-hip-base) Date: Fri, 22 Sep 2006 13:39:34 +0300 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: hipsec@ietf.org, iesg@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org >> If you don't keep your R1 generation counter, your open up your >> peers to >> R1 replay attacks. What an R1 replay attack may cause is that >> under an >> active attack the Initiator may solve a wrong puzzle, causing the >> communication to fail. I would not consider that a big problem, >> though. >> The idea of generation counters is to plug that problem to those >> hosts >> that do have stable storage. > > To clarify, I didn't see this attack as a big problem, hence I do > not see the sufficiently clear justification for stable storage > requirement and related complexity. Very few IETF protocols > require or recommend (in uppercase) stable storage and IMHO such > protocol design choices need more careful examination. IIRC, we discussed in length at the WG if the generation counter was a good idea at all. The additional protection it provides is not that large; that is clear. My memory may fail here, but IIRC in the end of the day we felt that the actual added complexity is small enough compared to the potential benefit. In practical terms, it is just that you store the generation counter in the same file than the private key, or next to it. And we felt that in this way we make the design "complete", i.e., provide all the protection that we "can". (I can spell out the qualified "can" if you want to -- it basically refers to the engineering trade-off between the various conflicting forces in this space. But it is a long story.) Anyway, we only recommend using stable storage if you have it, and still allow the operation without it. The reason why it is a SHOULD and not a MAY is that leaving it out has security implications to others, basically leaving your *peers* slightly more vulnerable to a potential security problem. Hence, to overcome the economic asymmetry here (you pay to protect your peers), we thought that encouragement from the IETF side is needed. >>> ==> So, you're required to create a new public key if R1 rolls >>> over, you >>> don't store it in the disk during reboot, etc.? >> >> No, or at least that is not the intention. The intention is to only >> require a new public key to be created if you do keep the generation >> counter on the disk and it does roll over. Again, this is related to >> the desire to support ROM-only devices. > ... >> I don't understand how it creates requirements to the use of HIs. > > So, if you happen to have an implementation bug, for example, which > would jump the generation counter forward too much so that it would > need to be rolled over, you'd need to regenerate your keys. IMHO that is pretty far fetched. Why should you imagine to have such a bug and go unnoticed for the at least few years that is needed to roll over the counter even at the fastest speeds I can imagine? > This doesn't sound too userfriendly. I keep wondering why a > typical counter that can roll over could not sufficiently protect > from a replay attack. It may be that I don't remember all the design considerations here, but rolling a 64-bit counter takes quite a lot of time, and you may initialise it to zero. At the rate of one generation per minute, rolling a 64-bit counter takes about 2300 times the current estimate for the age of the universe. At the rate of a new generation each second, it just takes 38 times the current age of the universe to roll it over. Hence, if you do your math, you may not even need to include any code to cover that situation, as it will never happen. Furthermore, it seems unwise to rely on the same public keys for longer than perhaps a decade or two. Hence, I don't quite understand what you are objecting. (A comparison point that we had in mind was that in IPsec, if you roll over your 64-bit replay protection, which gets updated at a much faster rate, you need to recreate your SAs. And that is not seen as a problem.) >>>> 9 >>>> The type codes 32768 through 49141 are reserved for >>>> experimentation and private use. Types SHOULD be selected >>>> in a >>>> random fashion from this range, thereby reducing the >>>> probability >>>> of collisions. A method employing genuine randomness (such as >>>> flipping a coin) SHOULD be used. >>> There should be some IANA guidance on this. > > The IANA cannot just randomize a number. It at the very least, it > needs to randomize a number, and then to keep it as it is or add or > subtract one, depending on whether the requestor wants a Critical > bit to be set or not. I don't understand how you get the impression that IANA should generate and/or register them? They are explicitly told to be for experimentation and private use. Perhaps the wording is unclear? >>> ==> By the way, do we even want to allow non-reviewed critical >>> bit usage? >> >> Now I don't understand your thinking at all. > > As the lack of support for the critical bit option stops the HIP > exchange, those option numbers should be designed and deployed with > more care than non-critical options. Whether IETF review helps (or > is the right way) to ensure this is probably a matter of opinion > (and I don't have a strong one myself). If you are worried about running out HIP parameter types, IMHO you should be more worried about the ordering requirement. That is far more likely to cause local shortages than that we might run out by any other means. I'm sorry for being dense, but I still fail to see your point. I just don't understand why there should be any more care with critical options than non-critical ones. As far as I can see, which one to use is a design choice. In general, by using a critical option you basically want a fast-stop feature. You could as well use a non- critical option that requires a reply if implemented, but you just save yourself the burden of checking that by making the option critical. The reason to include is that there are certain types of crypto protocols that become somewhat easier to implement and/or make secure with such fast-stop feature. So, are you calling for clarification of the (IMHO pretty obvious) thinking behind, or what is your concern? Have you looked at the advice in 5.2.2? --Pekka Nikander _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 22 15:34:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQqmC-00026t-7M; Fri, 22 Sep 2006 15:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQqmA-00022s-QC; Fri, 22 Sep 2006 15:33:30 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQqdx-0001nM-LH; Fri, 22 Sep 2006 15:25:02 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k8MJOuSO022217; Fri, 22 Sep 2006 22:24:57 +0300 Date: Fri, 22 Sep 2006 22:24:56 +0300 (EEST) From: Pekka Savola To: Pekka Nikander Subject: Re: [Hipsec] Re: Last Call: 'Host Identity Protocol' to Experimental RFC (draft-ietf-hip-base) In-Reply-To: <2ABE5CD7-607C-4AC5-9234-E893DDEE4BF6@nomadiclab.com> Message-ID: References: <2ABE5CD7-607C-4AC5-9234-E893DDEE4BF6@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.4/1923/Fri Sep 22 03:09:13 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: hipsec@ietf.org, iesg@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 22 Sep 2006, Pekka Nikander wrote: >>>>> 9 >>>>> The type codes 32768 through 49141 are reserved for >>>>> experimentation and private use. Types SHOULD be selected in a >>>>> random fashion from this range, thereby reducing the probability >>>>> of collisions. A method employing genuine randomness (such as >>>>> flipping a coin) SHOULD be used. >>>> There should be some IANA guidance on this. >> >> The IANA cannot just randomize a number. It at the very least, it needs to >> randomize a number, and then to keep it as it is or add or subtract one, >> depending on whether the requestor wants a Critical bit to be set or not. > > I don't understand how you get the impression that IANA should generate > and/or register them? They are explicitly told to be for experimentation and > private use. Perhaps the wording is unclear? Sorry, I misread the text as calling these out to be registered with IANA. It seems clear enough. Maybe it could have something about the user deciding whether it wants to have a critical bit or not (e.g., a pointer to some other part of the draft) but that doesn't seem strictly necessary. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 28 15:51:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT1uP-0007Ib-7M; Thu, 28 Sep 2006 15:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT1u3-0006YS-8j; Thu, 28 Sep 2006 15:50:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT1u3-0003sm-6C; Thu, 28 Sep 2006 15:50:39 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GT1tx-0002VZ-AQ; Thu, 28 Sep 2006 15:50:39 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D7C60175C9; Thu, 28 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GT1tS-00008V-E0; Thu, 28 Sep 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 28 Sep 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-dns-07.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Author(s) : P. Nikander, J. Laganier Filename : draft-ietf-hip-dns-07.txt Pages : 21 Date : 2006-9-28 This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP.) This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVS.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-07.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-dns-07.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-dns-07.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: <2006-9-28121707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-dns-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-dns-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-28121707.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart--