Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC
Pekka Savola <pekkas@netcore.fi> Tue, 29 May 2007 20:18 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 1Ht89B-0003j5-Ne; Tue, 29 May 2007 16:18:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7tH-0000BT-Gv; Tue, 29 May 2007 16:02:00 -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 1Ht7qs-0001pB-2G; Tue, 29 May 2007 15:59:37 -0400
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l4TJwN4F011586; Tue, 29 May 2007 22:58:23 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l4TJwNiF011583; Tue, 29 May 2007 22:58:23 +0300
Date: Tue, 29 May 2007 22:58:23 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
In-Reply-To: <6498B3B5-3627-4959-9051-3C288647C97D@nomadiclab.com>
Message-ID: <Pine.LNX.4.64.0705292246010.10757@netcore.fi>
References: <E1Hnaws-0006TN-7V@stiedprstage1.ietf.org> <Pine.LNX.4.64.0705290821170.13396@netcore.fi> <6498B3B5-3627-4959-9051-3C288647C97D@nomadiclab.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: ClamAV 0.90.2/3315/Tue May 29 03:04:17 2007 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
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
On Tue, 29 May 2007, Pekka Nikander wrote: > 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. I have personally no big problems if the spec were to say that "HIP-after-A-or-AAAA" were to be left out of scope of this document. However, what I'm a bit uncomfortable with is that this assumption is apparently made in Section 3, "Usage Scenarios", which seems to be a section with no normative content. As such I believe such a statement/assumption (if made) should be made in a more prominent place in the spec. >> 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. This is makes me even more afraid. If most end-nodes use mechanism A but others are expected to maybe use another mechanism B, I foresee problems with both mechanisms especially in middleboxes. It certainly won't improve the reliability of the protocol.. >> 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. Maybe I was trying to be too terse or I'm missing an assumption about how HIT vs HI is validated in other parts of HIP infrastructure. Let's say I publish a HIPRR with HIT=hash(Y) and HI=X. Someone else has HI=Y, and I choose HIT above so that HIT=hash(Y), i.e., create an intentional conflict. Given that the spec does not mandate that the implementations check that HIT will correspond to the HI, what's going to happen in this case? Will a middlebox overwrite the index at hash(Y) with HI=X? If yes, what is the result? Will it be a DoS on the host that used HI=Y? That was the scenario 2.a) above and 2.b) is when HITs don't conflict (a more trivial case) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ 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