|
List Info
Thread: RE:CoA verification for HA
|
|
| RE:CoA verification for HA |

|
2007-08-16 04:31:33 |
>
> I have a comment for the monami6-mipv6 analysis draft.
>
> RFC 3775 permits MN to have only a single CoA binding
at HA
> at any given time. So this means if MN (attacker) set
ups a
> DoS on a victim (using victim's address as CoA), MN can
no
> longer communicate with other nodes using his HoA.
However,
> in simultaneous bindings, MN can set up DoS attack on
> multiple victims, and yet retain one real CoA for
> communication with other nodes (possibly HA, to alter
filter
> settings to change victim's address).
>
> Do we need to consider some form of CoA verification
being
> performed by HA?
Sam.Xia> CoA binding has been authencticated by some
other means, such as
IPsec or RFC4285.
>
> Regards,
> Benjamin Lim
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Monami6 mailing list
> Monami6 ietf.org
> https:
//www1.ietf.org/mailman/listinfo/monami6
>
>
> End of Monami6 Digest, Vol 30, Issue 4
> **************************************
>
_______________________________________________
Monami6 mailing list
Monami6 ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|
|
| RE: CoA verification for HA |

|
2007-08-16 04:58:29 |
Hi,
> > I have a comment for the monami6-mipv6 analysis
draft.
> >
> > RFC 3775 permits MN to have only a single CoA
binding at HA
> > at any given time. So this means if MN (attacker)
set ups a
> > DoS on a victim (using victim's address as CoA),
MN can no
> > longer communicate with other nodes using his HoA.
However,
> > in simultaneous bindings, MN can set up DoS attack
on
> > multiple victims, and yet retain one real CoA for
> > communication with other nodes (possibly HA, to
alter filter
> > settings to change victim's address).
> >
> > Do we need to consider some form of CoA
verification being
> > performed by HA?
>
> Sam.Xia> CoA binding has been authencticated by some
other means, such as
> IPsec or RFC4285.
[Ben] I am talking more on path verification. Yes HA can
authenticate that
MN is a valid user to bind CoA at it. But HA cannot be sure
if this MN is
binding 'fake' CoAs that does not belong to MN. If no path
verification is
done by HA, MN can use these 'fake' CoAs to launch DoS
attacks.
Regards,
Benjamin Lim
_______________________________________________
Monami6 mailing list
Monami6 ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|
|
| Re: RE: CoA verification for HA |
  Japan |
2007-08-16 15:25:11 |
Hi Benjamin,
This problem is not specific to monami6, but more general
issue of MIP6.
However, I'm not sure this is real scenario, because MN must
establish
SA before sending BU... MN is always identified by HA before
sending BU.
ryuji
On 2007/08/16, at 18:58, Benjamin Lim wrote:
> Hi,
>
>>> I have a comment for the monami6-mipv6 analysis
draft.
>>>
>>> RFC 3775 permits MN to have only a single CoA
binding at HA
>>> at any given time. So this means if MN
(attacker) set ups a
>>> DoS on a victim (using victim's address as
CoA), MN can no
>>> longer communicate with other nodes using his
HoA. However,
>>> in simultaneous bindings, MN can set up DoS
attack on
>>> multiple victims, and yet retain one real CoA
for
>>> communication with other nodes (possibly HA, to
alter filter
>>> settings to change victim's address).
>>>
>>> Do we need to consider some form of CoA
verification being
>>> performed by HA?
>>
>> Sam.Xia> CoA binding has been authencticated by
some other means,
>> such as
>> IPsec or RFC4285.
> [Ben] I am talking more on path verification. Yes HA
can
> authenticate that
> MN is a valid user to bind CoA at it. But HA cannot be
sure if this
> MN is
> binding 'fake' CoAs that does not belong to MN. If no
path
> verification is
> done by HA, MN can use these 'fake' CoAs to launch DoS
attacks.
>
> Regards,
> Benjamin Lim
>
>
>
> _______________________________________________
> Monami6 mailing list
> Monami6 ietf.org
> https:
//www1.ietf.org/mailman/listinfo/monami6
_______________________________________________
Monami6 mailing list
Monami6 ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|
|
| RE: RE: CoA verification for HA |

|
2007-08-17 00:16:30 |
Hi Ryuji,
[snip]
> This problem is not specific to monami6, but more
general issue of MIP6.
[Ben] Not really. I feel the issue should be view as so:-
1) Degree of threat.
In MIP6, an attacker can only launch a single DoS attack.
But in Monami6,
due to multiple CoA bindings support, an attacker can launch
multiple DoS
attack.
2) Form of threat.
In MIP6, once the attacker launch the DoS, the attacker
loses communication
means (as the HoA, CoA binding is taken up for attack).
However, in Monami6,
one of the multiple CoAs can be used by the attacker to
control the DoS
attack for the other CoA bindings. (e.g. set filter rules at
HA)
> However, I'm not sure this is real scenario, because MN
must establish
> SA before sending BU... MN is always identified by HA
before sending BU.
[Ben] The CoA used for binding at HA need not be the source
address of the
BU. i.e. AltCoA option, BUI option. So does this means HA
should trust the
CoAs in such options?
Regards,
Benjamin Lim
>
> ryuji
>
>
> On 2007/08/16, at 18:58, Benjamin Lim wrote:
>
> > Hi,
> >
> >>> I have a comment for the monami6-mipv6
analysis draft.
> >>>
> >>> RFC 3775 permits MN to have only a single
CoA binding at HA
> >>> at any given time. So this means if MN
(attacker) set ups a
> >>> DoS on a victim (using victim's address as
CoA), MN can no
> >>> longer communicate with other nodes using
his HoA. However,
> >>> in simultaneous bindings, MN can set up
DoS attack on
> >>> multiple victims, and yet retain one real
CoA for
> >>> communication with other nodes (possibly
HA, to alter filter
> >>> settings to change victim's address).
> >>>
> >>> Do we need to consider some form of CoA
verification being
> >>> performed by HA?
> >>
> >> Sam.Xia> CoA binding has been
authencticated by some other means,
> >> such as
> >> IPsec or RFC4285.
> > [Ben] I am talking more on path verification. Yes
HA can
> > authenticate that
> > MN is a valid user to bind CoA at it. But HA
cannot be sure if this
> > MN is
> > binding 'fake' CoAs that does not belong to MN. If
no path
> > verification is
> > done by HA, MN can use these 'fake' CoAs to launch
DoS attacks.
> >
> > Regards,
> > Benjamin Lim
> >
> >
> >
> > _______________________________________________
> > Monami6 mailing list
> > Monami6 ietf.org
> > https:
//www1.ietf.org/mailman/listinfo/monami6
_______________________________________________
Monami6 mailing list
Monami6 ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|
|
| Re: RE: CoA verification for HA |
  Japan |
2007-08-18 01:33:10 |
On 2007/08/17, at 14:16, Benjamin Lim wrote:
> Hi Ryuji,
>
> [snip]
>> This problem is not specific to monami6, but more
general issue of
>> MIP6.
> [Ben] Not really. I feel the issue should be view as
so:-
>
> 1) Degree of threat.
> In MIP6, an attacker can only launch a single DoS
attack. But in
> Monami6,
> due to multiple CoA bindings support, an attacker can
launch
> multiple DoS
> attack.
>
> 2) Form of threat.
> In MIP6, once the attacker launch the DoS, the attacker
loses
> communication
> means (as the HoA, CoA binding is taken up for attack).
However, in
> Monami6,
> one of the multiple CoAs can be used by the attacker to
control the
> DoS
> attack for the other CoA bindings. (e.g. set filter
rules at HA)
>
>> However, I'm not sure this is real scenario,
because MN must
>> establish
>> SA before sending BU... MN is always identified by
HA before
>> sending BU.
> [Ben] The CoA used for binding at HA need not be the
source address
> of the
> BU. i.e. AltCoA option, BUI option. So does this means
HA should
> trust the
> CoAs in such options?
No, but MN is authenticated at this point.
Why will MN try to cheat CoA even if it is authenticated by
HA...
Will you do bank robber with your name tag-on?
ryuji
> Regards,
> Benjamin Lim
>
>>
>> ryuji
>>
>>
>> On 2007/08/16, at 18:58, Benjamin Lim wrote:
>>
>>> Hi,
>>>
>>>>> I have a comment for the monami6-mipv6
analysis draft.
>>>>>
>>>>> RFC 3775 permits MN to have only a
single CoA binding at HA
>>>>> at any given time. So this means if MN
(attacker) set ups a
>>>>> DoS on a victim (using victim's address
as CoA), MN can no
>>>>> longer communicate with other nodes
using his HoA. However,
>>>>> in simultaneous bindings, MN can set up
DoS attack on
>>>>> multiple victims, and yet retain one
real CoA for
>>>>> communication with other nodes
(possibly HA, to alter filter
>>>>> settings to change victim's address).
>>>>>
>>>>> Do we need to consider some form of CoA
verification being
>>>>> performed by HA?
>>>>
>>>> Sam.Xia> CoA binding has been
authencticated by some other means,
>>>> such as
>>>> IPsec or RFC4285.
>>> [Ben] I am talking more on path verification.
Yes HA can
>>> authenticate that
>>> MN is a valid user to bind CoA at it. But HA
cannot be sure if this
>>> MN is
>>> binding 'fake' CoAs that does not belong to MN.
If no path
>>> verification is
>>> done by HA, MN can use these 'fake' CoAs to
launch DoS attacks.
>>>
>>> Regards,
>>> Benjamin Lim
>>>
>>>
>>>
>>>
_______________________________________________
>>> Monami6 mailing list
>>> Monami6 ietf.org
>>> https:
//www1.ietf.org/mailman/listinfo/monami6
>
>
>
_______________________________________________
Monami6 mailing list
Monami6 ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|
|
| RE: RE: CoA verification for HA |

|
2007-08-19 21:07:04 |
Hi Ryuji,
[snip]
> No, but MN is authenticated at this point.
> Why will MN try to cheat CoA even if it is
authenticated by HA...
> Will you do bank robber with your name tag-on?
[Ben] Why not? Having your identity known does not preclude
such action. An
authenticated MN could get infected by a virus that performs
such action
unwitting. Furthermore, if an attacker is bent on creating
trouble, having
his/her identity known does not really stop their personal
agenda (as seen
by some real life events..;p)
Regards,
Benjamin Lim
>
> ryuji
_______________________________________________
Monami6 mailing list
Monami6 ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|
|
[1-6]
|
|