Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt

From: [email-masked] (Henderson, Thomas R)
Date: Fri Jan 23 12:24:00 2004

> -----Original Message-----
> From: marcelo bagnulo [mailto:[email-masked]]=20
> Sent: Friday, January 23, 2004 7:54 AM
> To: Henderson, Thomas R; [email-masked]
> Subject: RE: [Hipsec] Re: draft-nikander-hip-mm-01.txt
>=20
>=20
> > OK, I see this now, but there are scenarios for which the two hosts
> > trust each other (e.g., non-anonymous mode) so it would be=20
> preferable
> > in my view to make RR an option for the host receiving a REA.  I
> > would like to keep a lightweight readdress option--
> > so could we have two possible modes?
> >
> > REA ->
> > <- REA-ACK
> >
> > REA ->
> > <- REA-ACK (cookie)
> > REA-CONF (cookie) ->
> >
> > NES is an option for either of the above exchanges.  This puts
> > control in the responder's hands as to whether the REA initiator
> > is trusted enough to readdress without cookie challenge, and it
> > leaves control in the REA initiator's hands as to whether it
> > wants to rekey the SA.
>=20
> Well, the point here is who is the victim, i guess.
>=20
> You have A and B that trust each other, so you suggest that=20
> they could just
> skip the RR procedure for additional addresses.
>=20
> So A asks B to start sending its traffic to address C.
>=20
> Now, neither A nor B is damaged here but C is the one who is attacked
>=20
> I mean, if A trusts B it can take some risks that concern him=20
> and himself
> only.
>=20
> However, not performing RR endanger other parts like C so it=20
> is not up to A
> to decide this, IMHO it is up to the protocol designer to=20
> make sure that
> this doesn't happen
>=20
> But my criteria may be wrong here....
>=20

A doesn't get to decide-- B does.  B makes a decision that it
trusts A enough to not lie about moving to a given address. =20

This is really a policy issue, not a protocol issue.  I would
instead argue that it is up to the protocol designer to avoid
unnecessarily constraining the possible operation of the protocol
when there is no technical basis for the restriction, and leave
the policy decision to the operator.

Tom=20

---

From: [email-masked] (Pekka Nikander)
Date: Fri Jan 23 12:55:01 2004

Tom,

[Sorry about delay in answering.]

>>> trust each other (e.g., non-anonymous mode) so it would be preferable
>>> in my view to make RR an option for the host receiving a REA.

Tom, yes you are right.  We have discussed this through already
before, but I forgot.  I will add this back to the next version
of the draft.  Sorry about forgetting about this.

[I'll answer to the rest of your first message separately.]

>>> I would like to keep a lightweight readdress option--

Yes, definitely.  Mea culpa.

> trusts A enough to not lie about moving to a given address.

Right.

> the policy decision to the operator.

Yes.

Again, I am sorry about forgetting this and dropping this
from the -01 version of the draft.

--Pekka Nikander