Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

From: [email-masked]
Date: Fri, 7 Mar 2003 10:56:51 -0500

Hi:

In current DT draft, it is not the intention to create a database from administrator in CARD server to validate AP addresses. What we have assumed is that some L2 layer mechanism is available which enables AR to know what APs are attached to it, as well as AR to know when some APs are removed or new ones are introduced. AR reports this AP list to CARD server. So, effectively ARs are in control of validating AP addresses that are attached to them.

Hemant

-----Original Message-----
From: ext [email-masked]
[mailto:[email-masked]]
Sent: Friday, March 07, 2003 10:40 AM
To: [email-masked]; Chaskar Hemant (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

Hi Eunsoo,
Good points.
Comments embedded.
Thanks,
Govind.

>
> Rate limiting isn't done on any particular MN, it is done on *all* CARD
> requests. If the default limits defined in the protocol are gone over, the
> router starts dropping CARD requests, regardless of what IP address they
have on
> them. Service begins to degrade, but it is not denied.
>

[eunsoo] If the server cannot answer all CARD requests after the limit, the
whole network is affected by that. Why do we want this while there is an
alternative?

[Govind] Very good point. Dycard provides an alternative wherein the probability
of a DoS happening is quite low, as has been pointed  out by Robert in his email. The
probability of such a DoS attack happening in the DT draft is quite high.
Also another question would be: is such a situation possible from happening 
in a non-malicious case?
Consider the following scenario. Genuine MNs report beacons from APs other domains. 
 Wouldn't a similar case happen in even then as the number of APs/ given area
begin to increase? Note the server or the AR has no way to make out whether such APs are genuine
or not.
Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email
 increase and the system  provides degraded service even here? Ofcourse, one way is for the
 AR to maintain a list of all APs for which the the server sent a nack in the past.
 Isn't this an added burden? 
Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch
such an attack. 
 
> Meanwhile, legitimate users begin to notice, get a sysadmin, and find the
> villian.
>
>
[eunsoo] This should be the last resort. We should prevent or minimize this
kind of situation from the protocol design stage. Dycard has an advantag
regarding this.

[Govind] One more question to ponder is when there are multiple "villains". 
One could just move away once the rate falls and another one takes over
 after sometime. 

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 7 Mar 2003 12:00:02 -0800

Hermant,

OK. But the problem is not how an AR find the addresses of the AP attached
to itself.
The problem is that MN will hear various beacons which may come from
different domains. This is often the case for WLAN.
And MN will send an inquiry to the current AR and the current AR will send
an inquiry to the CARD server.
As the number of MN increases, the number of inquires from ARs to the CARD
server will increase.
Then the measure proposed by James will cause blocking the CARD server from
answering any more inquiries and we may see high probability of such
situation.

Eunsoo

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 07, 2003 7:56 AM
Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

Hi:

In current DT draft, it is not the intention to create a database from
administrator in CARD server to validate AP addresses. What we have assumed
is that some L2 layer mechanism is available which enables AR to know what
APs are attached to it, as well as AR to know when some APs are removed or
new ones are introduced. AR reports this AP list to CARD server. So,
effectively ARs are in control of validating AP addresses that are attached
to them.

Hemant

-----Original Message-----

Hi Eunsoo,
Good points.
Comments embedded.
Thanks,
Govind.

have on

[Govind] Very good point. Dycard provides an alternative wherein the
probability
of a DoS happening is quite low, as has been pointed  out by Robert in his
email. The
probability of such a DoS attack happening in the DT draft is quite high.
Also another question would be: is such a situation possible from happening
in a non-malicious case?
Consider the following scenario. Genuine MNs report beacons from APs other
domains.
 Wouldn't a similar case happen in even then as the number of APs/ given
area
begin to increase? Note the server or the AR has no way to make out whether
such APs are genuine
or not.
Now if we have multiple MNs doing this wouldn't the problem described by
Hemant in his email
 increase and the system  provides degraded service even here? Ofcourse, one
way is for the
 AR to maintain a list of all APs for which the the server sent a nack in
the past.
 Isn't this an added burden?
Since I think dycard bases cache entries on actual handovers, this is quite
difficult to launch
such an attack.

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 7 Mar 2003 12:00:02 -0800

Hermant,

Eunsoo

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 07, 2003 7:56 AM
Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

Hi:

Hemant

-----Original Message-----

Hi Eunsoo,
Good points.
Comments embedded.
Thanks,
Govind.

have on

---

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Mar 2003 09:16:04 -0800

Right, but what about APs that are attached to other ARs? How can AR1 know that
an AP being presented to it by MN is not bogus?

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 07, 2003 7:56 AM
Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

> In current DT draft, it is not the intention to create a database from
administrator in CARD server to validate AP addresses. What we have assumed is
that some L2 layer mechanism is available which enables AR to know what APs are
attached to it, as well as AR to know when some APs are removed or new ones are
introduced. AR reports this AP list to CARD server. So, effectively ARs are in
control of validating AP addresses that are attached to them.
probability
email. The
domains.
such APs are genuine
Hemant in his email
way is for the
difficult to launch

---

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Mar 2003 09:16:04 -0800

jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 07, 2003 7:56 AM
Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

probability
email. The
domains.
such APs are genuine
Hemant in his email
way is for the
difficult to launch