Subject: [Mip6] FW: I-D ACTION:draft-dupont-ikev2-haassign-01.txt

From: "DENG, HUI -HCHBJ" <[email-masked]>
Date: Mon, 13 Mar 2006 11:47:22 +0800

Hi, Francis

>	Filename	: draft-dupont-ikev2-haassign-01.txt
We read your draft here.
Firstly, if you have time, please read our draft too.
http://ietfreport.isoc.org/all-ids/draft-li-mip6-ha-init-bootstrap-00.tx
t

Secondly, we thought this problem has been presented by us
in last year Paris ietf meeting and made a solution there.

Thirdly, we read draft just now, think that we already consider your
solution before, at that time, we think that such kind of HA address
assignment is not securely protected since it is processed before IKE
procedure.

Fourthly, to guarantee your security of HA assignment in split scenario,
we thought that it needs at least twice IKE procedures to do it.

Lastly, as you said in your draft:
http://www.ietf.org/internet-drafts/draft-dupont-mip6-dhaadharmful-01.tx
t
>   The main security issue is in the anycast destination of requests,
>  and as the mechanism is the first step of bootstrapping, there is no
>  way to add reasonable security to it.
We guess that this description could apply to your draft solution :)

-Hui

Disclaimer:
The contents of this e-mail, and its attachments, if any, are confidential and may be protected
by law against any unauthorized use.  If you have received this e-mail by mistake or have
reason to believe that you are not the intended recipient, please notify the sender by reply
e-mail as soon as possible and delete it from your computer system immediately thereafter.
If you are not the intended recipient, you must not copy this e-mail or attachment or disclose
the contents to any other person.  While we have made every effort to keep our network virus free,
we take no responsibility for any computer virus which might be transferred by way of this e-mail.
_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Mon, 13 Mar 2006 19:36:34 +0100

We read your draft here.

=> I am rereading it.

   http://ietfreport.isoc.org/all-ids/draft-li-mip6-ha-init-bootstrap-00.txt

=> note your draft expired.

=> the problem we address is a bit different: it is only to add
home agent assignment to IKEv2. For home agent reliability we
believe in HA-switch (some kind of reassignment) and VRRP
(transparent server redundancy).
Some random comments about your draft:
 - in 3. you have 5 items for 4 sub-problems
 - in 4.1. what is the HAS message? (please introduce it before)
 - in 4.2. you enforce separate SAs for transport mode when in fact
   there is a choice between one SA pair for all or one SA pair
   per service (cf. the unique stuff).
   More important, you loose the extensible authentication (EAP)
   which is defined only for the initiator (IMHO this is enough
   to make IKEv2 established initiated by the HA less attractive).

=> I don't understand your argument: our draft is not less secure than
the current solution:
 - a fake HA is always detected at its first IKE_AUTH message
 - a fake client must go throught the cookie step (i.e., this defense
   against DoS attack against HAs is always enabled)
 - fake extra responses can't really mess the MN (IKEv2 has a defense
   against this attack, cf. RFC 4306 2.4 "There is a Denial of Service
   attack on the initiator" and Tero's message about this when it was
   invented (by Kilian BTW)).

=> this is clearly not acceptable so you have to explain your argument...

   Lastly, as you said in your draft:
   http://www.ietf.org/internet-drafts/draft-dupont-mip6-dhaadharmful-01.txt
   
=> what I said is it is impossible to secure the anycast DHAAD itself
but it doesn't give an insecure complete solution (fortunately!) because
a fake HA is always detected. I agree the same attack can be tried against
our solution but in fact it exists with any solution, even independently
of the mobility, and RFC 4306 identified the issue and gave the way to
avoid it.   
   
Regards

[email-masked]

---

From: Qin Li <[email-masked]>
Date: Wed, 15 Mar 2006 23:41:48 +0800

Hi Francis,

>  - in 3. you have 5 items for 4 sub-problems
It is 5 problems, not 4 problem, sorry about that.
>  - in 4.1. what is the HAS message? (please introduce it before)
HAS is HA Switch message, it is referred in the references below.
>    invented (by Kilian BTW)).

Could you explain some major differences between your solution and
this one: the Mobile Node use DHAAD to obtain HA address, then use
IKEv2 with cookie step to bootstrap from the HA.

Our argument is that we would naturally expect a solution more
secure than DHAAD + IKE.
> => this is clearly not acceptable so you have to explain your argument...
see above.
> [email-masked]

Best Regards

-Qin

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Mar 2006 17:59:43 +0100

=> simple (and it is the difference between discovery and assignment):
in our solution the HA side has the control about which HA will be
used.

=> IMHO things are really secure only when a SA is established
(before any attacker can try to play the role of the MN or the HA),
so the idea is to get one as soon as possible but in a flexible way,
i.e., with the assigned HA.
If you'd like to go further it is clear a very long term SA will be
better but the only way to provide it seems to use an AAA infrastructure
(I am convinced it is the more efficient, powerful and secure way but
unfortunately the bootstrapping DT gave us only 1% of what we expected).

Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Mar 2006 18:39:02 +0100

> in our solution the HA side has the control about which HA will be

In the pure non-anycast rfc3775 DHAAD solution too, the HA side has the 
control about which HA will be used.  The HAs advertise their 
preferences in RA and the MN receives an ordered list of HAs to use. 
The MN will use the HA with the highest preference.  The HAs set their 
preference as they wish, so collectively they know which HA will be used.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Mar 2006 18:40:34 +0100

Qin Li wrote:
>>> The main security issue is in the anycast destination of
>>> requests, and as the mechanism is the first step of
>>> bootstrapping, there is no way to add reasonable security to it.

If that address being an anycast address is the real problem then it 
would be useful to modify its definition and make it non-anycast.

Alex