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]

 



1) what if HIP RRs are not queried first?

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.

A suitable restriction of the scope, at an appropriate place, would be fine with me.

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..

So, maybe add a paragraph about the usability of the HIT for middle boxes.

IIRC, the context of discussion was HIP-aware firewalls. Such firewalls could simply snoop HIT RRs as they pass by (or even query them if there is a suitable reverse DNS hierarchy, which the draft does NOT specify, IIRC). Then, when they see HIP I2/R2 packets passing by, they could use the cached keys, as indexed by the HITs, to verify the signatures in the messages.

For such use, I don't see any need of verifying the cryptographic relationship between the HIT and HI. If the signatures in the I2/R2 don't match, then the firewall doesn't open the connection, and it is the user's problem. No security dangers, AFAICS. Indeed, it would be beneficial if the firewall did NOT try to establish any crypto relationship between the HIT and HI, since that would allow the relationship to evolve without mandating firewall code updates.

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?

You will fail to gain the channel binding property of HIP. In other words, you shoot to your own foot.

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?

Well, nothing if the middlebox is implemented correctly. HIT collisions are possible, anyway. Hence, in such a case the middlebox should cache both HI=X and HI=Y, indexed by the HIT. The fact that HIT!=hash(X) shouldn't matter.

--Pekka



_______________________________________________

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]