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

[Pekka Savola <pekkas at netcore.fi>]

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