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
