Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]