RE: [RAM] aside Re: HIP

> -----Original Message-----
> From: RJ Atkinson [mailto:rja@extremenetworks.com] 
> Sent: Tuesday, January 02, 2007 2:15 PM
> To: ram@iab.org
> Subject: [RAM] aside Re: HIP
> 
> 
> 	I think HIP is really great research.  I am not quite
> as enthusiastic about HIP as an operational solution.
> 
> 	My main concern is that with HIP, when one's public key
> is compromised (and, yes, that is always a WHEN, not an IF),
> one always necessarily loses one's Identifier.  This seems
> pretty undesirable to me.
> 
> 	HIP-like solutions that don't have issues of that sort
> are pretty different from any of the currently available HIP
> specifications.  Yes, the HIP authors/editors left the door open
> a crack, but AFAIK there isn't any proposal for how to make an  
> Identifier
> workable if the Identifier is not derived from one's public key.

Ram,
Is your concern that HIP has not explicitly considered what to do when
an identifier is compromised, or that solutions that actually do
adequately treat situations for which an identifier is compromised are
necessarily much different from HIP design?  If the latter, can you
provide a pointer?

What do you view as the operational requirements on the security and
permanence of a network-level identifier?  Note that there have been
differing views on this; for instance, the identifiers could be
transient and anonymous, or semi-permanent and public, or even securing
the channel bindings for higher-layer protocol security.  Each of these
use cases has different operational implications for how seriously to
protect the identifier from compromise and undo the damage when
compromised.  To this point, HIP has deliberately avoided choosing one
of the above use cases, and may be why these solutions are
underdeveloped for HIP.

> 
> 	Also, for moderate threat environments, I think all the
> HIP cryptography is overkill and computationally expensive.  I'd
> prefer to have the option for a less computationally intense and
> less comprehensive security mechanism for moderate threat 
> environments.
> (Something that merely prevented off-path attacks seems possible
> to me and might be interesting to have as a deployment option.)
> 

Pekka made reference to lightweight HIP using hash chains; although I
can't find the thesis, there is an expired internet draft with earlier
work:
http://tools.ietf.org/html/draft-nikander-multi6-hip-01 
which referenced the WIMP-F hash chain proposal for multi6:
http://tools.ietf.org/html/draft-ylitalo-multi6-wimp-01

Tom

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram