Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC
Pekka Nikander <pekka.nikander@nomadiclab.com> Tue, 29 May 2007 13:10 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1Sm-0004aP-Ug; Tue, 29 May 2007 09:10:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1Sj-0004aB-9Z; Tue, 29 May 2007 09:10:09 -0400
Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht1Sh-0001lx-S3; Tue, 29 May 2007 09:10:09 -0400
Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 69D05212E13; Tue, 29 May 2007 16:10:06 +0300 (EEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 33AAA212DFC; Tue, 29 May 2007 16:10:06 +0300 (EEST)
In-Reply-To: <Pine.LNX.4.64.0705290821170.13396@netcore.fi>
References: <E1Hnaws-0006TN-7V@stiedprstage1.ietf.org> <Pine.LNX.4.64.0705290821170.13396@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <6498B3B5-3627-4959-9051-3C288647C97D@nomadiclab.com>
Content-Transfer-Encoding: 7bit
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
Date: Tue, 29 May 2007 16:10:02 +0300
To: Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.752.3)
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: hipsec@ietf.org, ietf@ietf.org
Subject: Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
Hi Pekka, I don't have answers to all of your questions/remarks, but I'd take forward a few: > 1) what if HIP RRs are not queried first? > > In the following we assume that the initiator first queries for HIP > resource records at the responder FQDN. > > ==> what if it does not? Remember that this is an experimental spec. So, taking it the reverse, why should id specify what to do if someone has a reason to do it in another way? I don't see any specific reason to make any MUSTs or even SHOULDs here: I don't see here any danger for the Internet nor interoperability. But maybe I just don't understand the dangers you have in your mind. > 3) a premature optimization of HIT lookup tags > > Upon return of a HIP RR, a host MUST always calculate the HI- > derivative HIT to be used in the HIP exchange, as specified in > Section 3 of the HIP base specification [I-D.ietf-hip-base], while > the HIT possibly embedded along SHOULD only be used as an > optimization (e.g. table lookup). > > .. and in section 8.2: > > [...] This is why a HIP > end-node implementation SHOULD NOT authenticate its HIP peers based > solely on a HIT retrieved from the DNS, but SHOULD rather use HI- > based authentication. > > ==> this seems like a premature optimization. Note that these RRs may need to be indexed also by other boxes but the end-nodes. For them, using the HIT as an index and doing a simple memory comparison instead of calculating a hash may be a win. Further note that both the sections you quote above discuss only host/ end-note behaviour. > If you go forward as it is, I think the spec needs to be more > explicit on 1) > what happens when HIT received from the DNS does not match the hash > but the hash > is checked; I agree. FWIW, either ignore the HIT or drop the record. I think the latter would be the right option, but I may be wrong. > 2) what are the threats if HIT is used as-is without > hash-checking (as allowed by the spec at the moment) when a) the > DNS-HIT > points to something used by another HI, and b) the DNS-HIT doesn't > exist. I don't understand what you are saying here. --Pekka (the other one) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Last Call: draft-ietf-hip-dns (Host Identity … Pekka Savola
- Re: Last Call: draft-ietf-hip-dns (Host Identity … Stephane Bortzmeyer
- Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (H… Pekka Nikander
- Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (H… Pekka Savola
- Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (H… Pekka Nikander