Subject: RE: [mobile-ip] FW: Changing RS Reply Timing for Mobile IPv6

From: [email-masked]
Date: Tue, 8 Oct 2002 17:22:48 -0500

>As a followup, I'm wondering if we should put a reference to this
>document into the MIPv6 spec? 

No.

>Implementors need to be made aware of
>it, since we've found that the performance consequences of not having
>it can be pretty severe. If all goes well, we hope to advance this

"If all goes well" being the key word....

>spec in IPv6 WG quickly, so it should be ready by the time MIPv6 gets
>to RFC (which will hopefully be soon). Alternatively, we could put it
>into the nonnormative references, but I think it is important that an
>RFC number be there so implementors can trace the reference. 

MIPv6 will have a number of followup RFCs that implementers will need
to worry about. Fast HOs, Piggybacking and more to come. 

>            jak

-Basavaraj

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 9 Oct 2002 08:47:44 -0500

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Tuesday, October 08, 2002 6:07 PM
To: Hesham Soliman (EAB); Khalil, Mohamed [RICH2:2N51:EXCH];
[email-masked]
Subject: Re: [mobile-ip] FW: Changing RS Reply Timing for Mobile IPv6

> There was some
>   > concern on the part of Erik that the router with
>   > MAX_RA_DELAY_TME set to zero
>   > would then be open to a DoS attack. In the current design,
>   > the router is only
>   > exposed until it runs out of MAX_FAST_RAS. Of course, the
>   > attacker can simply
>   > roll over and continue after the RA is multicast, but it
>   > does provide some
>   > window of protection.
>
> => But (I could have missed this too!) I thought
> you were intending to use the same RS as normal
> hosts would, so how does a router know if this
> is a legitimate request or a DoS attack?
> I mean, many RSs could arrive at the same time,
> MAX_FAST_RAS are per host right? if so, then
> the router would reply to all of them and set
> MAX_FAST_RAS per dst address.
>

MAX_FAST_RAS are per router, not per host. When the router gets
MAX_FAST_RAS, it rolls over to doing multicast. Thus, the attacker can only
deny service for as long as it takes to use up MAX_FAS_RAS. After that,
everybody gets the multicast.

            jak

To add to what James said we are limiting the effect of DoS attacks within
MAX_FAS_RAS by limiting the upper bound of the Router Advertisement's
response rate to (MAX_FAST_RAS+1)/MIN_DELAY_BETWEEN_RAS. 

-Mohamed

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 10 Oct 2002 10:15:14 +0900

Hi Brett

Thanks for your kind comment. 

As you may know, random delay of RS is 'to alleviate congestion' 
as the following states:

" This serves to alleviate congestion when
many hosts start up on a link at the same time, such as might happen
after recovery from a power failure."

Therefore, we should examine if there will be congestion in case 
"mobile nodes send RS without delay when they detect link changes".

Two cases come in to my attention.

1) As Alper pointed, sometimes handovers can be synchronized (to 
    some extent) among a set of mobile nodes. In that case, there would 
    be congestion.

2) Sometimes (abnormal) link change occurs without movement. For 
    example, if AP (not AR) recovers from power failure or admin changes 
    AP for new one, mobile nodes will detect link change and send RSs 
    simultaneously. To prevent this, mobile nodes should be able to 
    distinguish normal link change (caused by movement) from abnormal 
    link change (caused by power failure or AP exchange).

With the above reasons, I think there will be congestion without random delay. 

Do you think it's negligible?

Regards,