[Hipsec-rg] A vs. B

[[e-mail] (Henderson, Thomas R)]

> -----Original Message-----
> From: Greg Perkins [mailto:[e-mail]]
> Sent: Friday, November 19, 2004 10:22 AM
> To: Henderson, Thomas R
> Cc: [e-mail]
> Subject: Re: [Hipsec-rg] A vs. B
>=20
>=20
> Tom,
>=20
> > I am not sure I agree with the above, or perhaps I don't understand
> > your point, or maybe there is a terminology issue.  The HI and HIT
> > really are identifiers.  They name the endpoint that holds the
> > corresponding private key.  It doesn't matter whether the=20
> identifiers
> > are well-known or anonymous or unregistered-- they are still
> > identifiers nonetheless.
>=20
> I am still getting up to speed on the terminology so forgive=20
> me since I
> misused it in some places.  In my mind a host identifier is a=20
> device/PC
> identifier, which a HIP HI can be but definitely doesn't have=20
> to be.  Any
> chance we can call them EI's then?  End-point identifiers?

See the terminology section in the HIP architecture draft, where
the Host Identity terminology is linked to the end-point terminology.
In the architecture draft, there is a distinction between public vs.=20
unpublished host identifiers, but they are both EIDs.

> > I don't know what you mean by 'dropping' the security features,
> > or running a base exchange without creating any ESP-- what is the
> > point of doing HIP in that case?
>   Currently, the internet works well without HIP but IPv6=20
> opens up a number
> of attacks that are currently not present (or IPv6 makes some=20
> attacks easier
> to perform).  Still, most sessions shouldn't need any active security
> because they aren't typically being attacked.  As I browse=20
> the Internet on
> my mobile phone I'd rather not spend cycles on security that=20
> most likely
> isn't needed.  If I detect that my session(s) are being=20
> hijacked then I can
> move into an active security state and re-claim ownership of=20
> sessions.  This
> is probably subject to some type of man-in-the-middle attack=20
> but for normal
> Internet use I somehow doubt that will be much of a threat.
>   On the other end the service provider can force active=20
> security if they
> perceive a DoS attack is under-way (or some other threat)=20
> (they up K for the
> puzzle, verify all sessions, etc.).  But during normal=20
> operations HIP is not
> 'enforced' but session identifiers can still be passed.
>   I guess I will call this passive-HIP.  I can see a use for=20
> this type of
> implementation.  Thoughts?
>=20


We've had some discussions previously as to whether a session could
be upgraded to full HIP protection after it started.  For example,
if one party decides to later change its addresses.  There are some
details that need to be worked out regarding what to use in the
transport pseudoheader, and how to do the IP-address-to-session
context mapping.  IIRC, there wasn't fundamental opposition to
this concept, but it seems to be a lower priority agenda item
to develop such a proposal more fully.=20

See also the lightweight HIP draft in the multi6 group, along these
same lines:
draft-nikander-multi6-hip-01

Tom=20