Subject: RE: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt

From: "Benjamin Lim" <[email-masked]>
Date: Mon, 26 Nov 2007 12:17:22 +0800

Hi,

My 2 'sense' on one point raised.

=8==8<=8==
> 3) Bulk Registrations and CNs: It is not clear why bulk 
> registrations are not allowed for CNs. Is it so much more 
> complex to handle bulk registrations once that is defined for 
> the HA and once the CNs handle MCoAs one at a time? 
[Ben] This point I agree with George. I feel that we might need to consider
extending Bulk Reg to CN. 

>From what I understand on why bulk registration is not used for CN is that
the complexity it creates trying to figure out how to protect the BU with
multiple CoKs and one HoK and in the same time proving to the CN that all
the specified CoAs in the bulk BU are valid routing addresses to MN. It
boils down to the matter on whether the benefit of bulk registration is
worth the solving of such a complex procedure. One benefit I see in bulk
registration is the effect it has on saving the power consumption for the
MN. E.g. MN can use one of its IF to send a bulk BU to HA to bind CoAs for
its other interfaces. This means that those IFs can be in idle mode only to
be woken up upon the need to receive/send packets. This saves power on
maintaining the multiple IFs of the MN. So such saving in power at the MN
might be worth considering exploring on this matter.

Also, I feel that other considerations on what impact would MN trigger when
using bulk registration. For instance, in my recently submitted ID
(http://www.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verify-00.t
xt), I mention MN using bulk registration might be able to bind CoAs of
victims at HA and thereby leading to a flooding attack to those victims. I
believe it is worth taking such issue into consideration.

Regards,
Benjamin Lim

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 27 Nov 2007 01:29:42 +0900

Hi Benjamin,

> My 2 'sense' on one point raised.

right. If we support RO, we have to extend RR for bulk-registration.
We need some mechanism to verify all the CoAs in a BU.

> might be worth considering exploring on this matter.

For power saving purpose, the best way is that MN registers that CoA  
only to HA.
MN just bulk-registers all the CoA in HA and waits for packets at the  
idle IF.

> believe it is worth taking such issue into consideration.

Thanks for writing that document.
We discussed this issue on Monami6 ML before.

I am still not sure how serious this attack is.
When the MN sends bulk-BU to HA, the MN has to create IPsec SA with  
the HA.
The scenario looks very limited because not all the nodes can launch  
the attack.
Even RFC3775 does not verify CoA for home registration.

regards,
ryuji

---

From: "Benjamin Lim" <[email-masked]>
Date: Tue, 27 Nov 2007 11:05:48 +0800

Hi Ryuji, 

My response to one of your comment inline.

=8==8<=8==
> > Also, I feel that other considerations on what impact would 
> MN trigger 
> > when using bulk registration. For instance, in my recently 
> submitted 
> > ID 
> > 
> (http://www.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verif
> > y-00.t xt), I mention MN using bulk registration might be 
> able to bind 
> > CoAs of victims at HA and thereby leading to a flooding attack to 
> > those victims. I believe it is worth taking such issue into 
> > consideration.
> 
> When the MN sends bulk-BU to HA, the MN has to create IPsec 
> SA with the HA.
[Ben] Yes IPsec protects the BU from any form of man-in-the middle
modification to the contents of the BU. But how can HA be sure that MN is
not the one being malicious. This is the problem we highlight in our draft
(that MN could be the malicious node). If you say, the identity of MN is
known to HA, we re-iterated in our draft providing an example that having
the identity known does not deter such attacks from being launched.

> The scenario looks very limited because not all the nodes can 
> launch the attack.
[Ben] True, but you do not need all nodes to launch the attack. Just a
Monami6 node launching the attack is at most equivalent to all nodes
launching the attack.

> Even RFC3775 does not verify CoA for home registration.
[Ben] RFC3775 assumes trust for home registration. More than likely, the CoA
is specified in the source address field of the packet hence ingress
filtering can be assumed to be performed. Even if AltCoA option used, in
RFC3775, at most MN can only specify one AltCoA binding. But in bulk
registration, MN can specify more than one CoA to be bound at HA.
Furthermore, only one of these CoAs is specified in the source address field
of the BU. The rest are specified in the BU itself. Hence, this increases
the risk of not knowing if they are actually valid routing address to MN
that HA has to take when binding these CoAs. Thus, it might be worth
considering in this case for HA to perform some procedure in order to lessen
such risk.

I believe that most of the question/answer is as per what we have discussed
on the Monami6 ML. Hopefully, this mail will clarify your doubts on such
issue.

Regards,
Benjamin Lim

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 27 Nov 2007 12:39:51 +0000

The draft describes how one can cause a CN to send downlink traffic
and then redirect that traffic to the target using MCoA+flow. One
observation is that this is also possible (although in a more limited
way) with plain MIPv6 e.g., triger a large UDP streaming download and
then handoff to the target's CoA to cause flooding.

I am not sure this is a really good attack though, given the fact that
the attacker's identity is known to the HA i.e., the attacker can get
caught.
It may, however, have some value as an attack if the attacker actually
owns the HA, and thus can not be traced as such. In such a case,
however, it might be easier for the attacker to run a random traffic
generator and flood whatever address it wants from the HA directly.

Am I missing something?
George

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 28 Nov 2007 11:34:11 +0800

Hi George, 

Thanks for having a look at the draft. My reply inline.

> -----Original Message-----
> From: George Tsirtsis [mailto:[email-masked]] 
> Sent: Tuesday, November 27, 2007 8:40 PM
> To: Benjamin Lim
> Cc: RYUJI WAKIKAWA; [email-masked]
> Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt
> 
> The draft describes how one can cause a CN to send downlink 
> traffic and then redirect that traffic to the target using 
> MCoA+flow. One observation is that this is also possible 
> (although in a more limited
> way) with plain MIPv6 e.g., triger a large UDP streaming 
> download and then handoff to the target's CoA to cause flooding.
> 
> I am not sure this is a really good attack though, given the 
> fact that the attacker's identity is known to the HA i.e., 
> the attacker can get caught.
[Ben] Let me clarify one thing. I understand most of us view most hackers as
someone hiding his/her identity when causing havoc in the system to prevent
being caught. However, there are those hackers that hack into nodes to try
and control them (e.g. spyware, bots). When this type of hacker controls a
node with Monami6 function, it can cause the node to unwitting bind victims'
CoA at the HA and redirect large traffic to them, thereby flooding those
CoAs. So, inevitably, the attacker has created a 'scapegoat' for his/her
action. Fine, the HA knows the identity of the node, but that is not the
'real' attacker's identity. In the draft, it also provided another example
saying that the attacker has create multiple 'fake' IDs to deter from being
identified.

To sum up, what I am trying to say is having 'HA know identity' does not
mean that nodes will not bind 'fake' CoA at HA. There are work-around to the
identity factor. In one sense, if the attacker is really motivated enough,
such attack can still be performed even if he/she knows that HA has the
identity. Its like playing 'cat & mouse' with the attacker screaming "Catch
me if you can!"

Hence, it might be worth considering providing some function at HA to
further reduce the chances of such issue of 'fake' CoA binding from
occurring.

Regards,
Benjamin Lim

> It may, however, have some value as an attack if the attacker 
> actually owns the HA, and thus can not be traced as such. In 
> such a case, however, it might be easier for the attacker to 
> run a random traffic generator and flood whatever address it 
> wants from the HA directly.
> 
> Am I missing something?
> George

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 28 Nov 2007 10:27:12 +0000

OK, you have a point. Thanks for the clarification.
George