Subject: [mobile-ip] rfc3012 question

From: Alper Yegin <[email-masked]>
Date: Sat, 17 Mar 2001 15:54:01 -0800 (PST)

Hello,

I have a question about how FA can keep track of valid challenge values.

As I understand, FA keeps track of valid challenges by noting the challenge 
values sent in multicast/broadcast RAs (these are global, received by all MNs), 
and challenge values sent to individual MNs.

It's easy to keep track of challenge values, when they are sent in a 
registration reply. MN's identity is the key.

But, when challenge values are sent in unicast RAs in response to RS, how can FA 
keep track of these? FA wouldn't know the identity of the MN. There's no NAI in 
RS. And the source address of the RS doesn't have to be home address.

If the solicited RA is sent multicast/broadcast, then since there can be too 
many MNs sending RS, this would fill up the CHALLENGE_WINDOW very quickly and 
create unnecessary rejections.

Unless I'm missing something, this seems like a problem.

alper

---

From: "Rambabu Tummala" <[email-masked]>
Date: Tue, 20 Mar 2001 14:23:08 -0600

Alper,

I ran into same problem, only way to get around this is by increasing the
CHALLENGE_WINDOW to bigger number.  In my opinion, which defeats the purpose
of the draft (RFC) itself.

Let me know, if you have a solution.

Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Saturday, March 17, 2001 5:54 PM
To: [email-masked]
Subject: [mobile-ip] rfc3012 question

Hello,

As I understand, FA keeps track of valid challenges by noting the challenge 
values sent in multicast/broadcast RAs (these are global, received by all
MNs), 
and challenge values sent to individual MNs.

But, when challenge values are sent in unicast RAs in response to RS, how
can FA 
keep track of these? FA wouldn't know the identity of the MN. There's no NAI
in 
RS. And the source address of the RS doesn't have to be home address.

many MNs sending RS, this would fill up the CHALLENGE_WINDOW very quickly
and 
create unnecessary rejections.

alper

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 26 Mar 2001 15:53:28 -0800 (PST)

As Alper brought this issue, it's a hard problem on specifying
the window size. Mostly the problem will appear in shared media like
wireless or wired LAN.

The scenario :  1. FA does unsolicited adv with challenge C1
                 2. 5 MNs solicit and gets different Challenge
                     numbers (C2, C3....C6)
                 3. Now FA again sends unsolicited adv with C7,
                 4. Now MN1 sends request with C2 value, if your
                    windowsize is 3(for example), the registration
                    will fail due to incorrect authorization.

How do we set a limit on the window size to minimize the
risk in security in the shared media as well as make the implementation
not so complex?

Two thoughts:

One simple idea is to not change challenge value during solicitation,
only change during unsolicited advertisements. This will work very well
in point-to-point connection between MN and FA, but will open security
holes in the shared media, especially when the advertisement interval
is large. The RFC then should specify a MAX (small value) time interval 
between two unsolicited advertisements (to reduce risks of attacks),
when challenge response mechanism is used.

 Another idea is  having a "minimum" window size
specification for challenge value, where:

Minimum window size = Time interval in sec between two periodic 
                      unsolicited advertisements.
                      
In this case, we can allow solicitation to send a new challenge value
with 'at least' one second of granularity. Comments ?

Anyway, RFC3012 should put some text in the RFC to clarify the challenge
values in case of solicitation.

Regards,
-Samita