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

From: "James Kempf" <[email-masked]>
Date: Wed, 5 Mar 2003 17:01:01 -0800

Finally had time to complete a review of the latest CARD draft. In general, the
design team seems to be making good progress on getting the details of the
protocol design filled in.

My comments break down into 3 areas: meta-issues involving contents of the
draft, specific technical issues with the contents, and editorial comments.

Meta-issues
------------

I found the draft somewhat confusing as there seem to be really four protocols
defined here. They are:

1) A collection of options for RFC 2461 and FMIP to provide a mobile node with
information about wireless handover connectivity to different subnets.

2) An RFC 2461 extension message for transmitting 1) between a mobile node and
access router in the absence of FMIP.

3) An interrouter protocol that uses 1) to exchange the same sort of information
between routers instead of between the mobile node and its access router.

4) An (underspecified) protocol between an access router and a server that lets
the access router authenticate CARD information and, optionally, pre-populate
its cache so that there is no learning period involved before the access router
can provide CARD information to the mobile node.

I think it would be really helpful to separate out these four areas and drill
down on them to get the details.

Specifically, I would like to suggest the following:

1) &2) As some of you may know, the Mobile IP group is currently undergoing
rechartering and there will be a BOF in SFO to discuss this. I have proposed as
part of the recharter that parts of the CARD work that have overlap with or have
relevance to FMIP be moved into a separate, spinoff MIP group. In the latest
FMIP draft, the proxy router advertisement signaling has been moved away  from
handover and now has no function other than to inform the mobile node about
wireless subnet connectivity. Since that is also what 1) and 2) are doing, I
would propose that the good work done in this document be sectioned off into a
separate document and introduced into the spinoff WG, should the IESG agree to
form such a group. If the ISEG doesn't, then I think the design team should
section the document and put this protocol into a separate document, dropping 2)
and making this signaling a collection of options on FMIP. In addition, I would
suggest that the CARD design team co-ordinate this with the current editor of
the FMIP draft. There is no point in having 2) if FMIP provides the
functionality.

3) I can't really see the point of introducing a new inter-router protocol of
this sort. I believe this would be better handled by defining some kind of
OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a
proposal, however. In any case, it needs investigation and should be moved into
a separate document if it proves to be of interest.

4) I disagree with the contention of some that this protocol is introducing a
new network element. Any large scale enterprise or ISP network is going to have
configuration in it, and this protocol is essentially defining a way to do
configuration. For small, home networks, this might not be required, because it
might be done using a Web interface to the firewall/access point. The proposed
solution in this draft is fairly vague, but I can see a couple of possible
dispositions:
    a) Define a RADIUS extension like that used by IAPP.
    b) Define an LDAP schema for access point configuration information.
    c) Define an SNMP MIB that allows a router to obtain this information from
another router.
I believe 802.11 has its own MIB, but we are talking about something that is
more generic. I've got no opinion about which of these would be better, and
there could be other possibilities. We should decide fairly quickly which we
want to pursue.

Technical Comments
---------------------

Section 3.2: Highly dynamic capabilites should be out of scope. Also, in
paragraph 2, what are downlink channels? Not all wireless protocols will have
these.

Section 4.1: I can't see how an MN could possibly perform CARD with an AR that
is not currently on its subnet. How does the MN discover such an AR in the first
place except by performing CARD with its exisitng AR (in which case, it doesn't
need to perform it with the other one)? If you assume that the MN has brought up
a separate interface with the other AR, then the other AR is on a subnet that
the MN is using on that interface. RA/RS can't be sent to any off link node, as
they are limited by the security measures in RFC 2461. Also, I don't think that
we should be considering L2 specific measures here (like including the other
router's IP address in the L2 beacon).

Throughout the draft, the notes on TAR selection and prefiltering should be
moved to an appendix. This includes the part in Section 4.2. The discussion of
TAR in the Requirements suboption and the node types in the Address suboption
need to be removed. From the MN's point of view, it doesn't matter whether the
returned address was prefiltered by the router or not. TAR selection on the
router should be completely invisible as far at the MN is concerned, and
selection on the MN is out of scope for this draft.

Section 5.1.3 Option formats need to be aligned with FMIP to avoid duplication.
For example, the MN may want to know the subnet prefix on the new subnet, but
that is not defined here.

Section 5.1.3.4 Why is the 'P' flag necessary? I think we need to align with
FMIP and remove this.

Section 5.1.4: What function does the lifetime flag perform? Either the returned
information is valid or not. If there's a lifetime associated with it, that
should be in the returned information.

Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is,
itself, subject to DOS attacks. The solutions presented in Section 6.3 for
handling these problems are much more streamlined and align with IP network
softstate approach:
    1) The protocol specifies a minimum interarrival time for sending requests.
    2) The protocol specifies a minimum reply time for routers replying. If too
many requests arrive, the router begins to selectively drop so hosts have to
retransmit.
    3) A default cache lifetime is defined. After this time, the router times
out the cache entry.
   4) An entry presented by the MN gets a preference level. The more times it is
reported by another MN, the less likely it is to time out. This needs to be
quantified and described as an algorthm.
These elements need to be added to the protocol draft for 1) in the meta-issues
section.

Editorial Comments
-------------------

Abbreviations that are defined in Section 2 should not be used until after they
are defined.

Section 2, CAR definition: the wording here is awkward. It needs clarification.

Section 3.1, paragraph 1, line 2: CAR that connects -> CAR that is connected

Section 3.1, paragraph 3, line 5: reverse address translation before -> reverse
address translation

Section 3.1, paragraph 4: These comments seem somewhat out of place. The new AR
isn't of interest to the MN for mobility purposes unless it is in a new subnet,
and, anyway, ARs in the current subnet will be obtained by RFC 2461 router
discovery. I also don't understand what the last sentence has to do with
anything.

Section 4.2 paragraph 9: the link layer ID of nearby AP -> the link layer ID of
a new AP. There are also a couple of other awkwardly phrased places in this
paragraph.

            jak

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

---

From: [email-masked]
Date: Thu, 6 Mar 2003 12:09:43 -0500

Hi Jim,
Some comments embedded inline.

Thanks,
Govind.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 8:01 PM
To: [email-masked]
Subject: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

[snip]

 dropping 2)

[Govind] 
 I do agree that we can optimize CARD if we know FMIP (I think you mean v6)
 is going to be available in the subnet. However, CARD is needed to operate in domains
 that are not IPv6. I would think the better way to go is FMIP and other seamless
 mobility protocols were to use CARD messages for this purpose. I think this was
 pointed out in an email on the mobile-ip working group. 

[Govind] Could you explain why you would think it should be an OSPF extension?
Do we have to bring OSPF/IS-IS into this? The routers are sending packets to each
other like any other packets,just like FMIPv6 or CT has messages between ARs, to enable
protocol functionality. Why is this any different? I think this is very important
 and helps provide a major functionality and it does belong in this document. Maybe 
I'm missing something.

[Govind] Do you think any of the methods that you suggest are
worth the effort for the purpose the CARD server is designated to do? Plus,
using a CARD server introduces the possibility of DoS on the CARD server itself.
I think this is one direction that we do not need to go, the cost heavily outweighs 
the benefit, IMO.  

Technical Comments
---------------------

[Govind] First, I don't know what you mean by highly dynamic capabilities. Can
you give some examples? I think the Issues draft does make the distinction between capabilities
as dynamic and static but not on the level of dynamicity in the capabilities. So why bring a new
level of distinction now? 
Second, regardless of the level of dyamicity  of the capabilities in question,
 the basic capability transfer remains the same. The state times out and it is refreshed.
 Third, the draft does not go into saying what 
capabilities are going to be put in. All it defines is the framework for capability transfer. 
So what are you trying to remove here? Are you saying that you want to remove the function of
the protocol that deals with dynamic capabilities? This I disagree with.

[snip]

[Govind]
The scope-id solution has several questions regarding effectiveness and
I have pointed them out in my earlier email.  Having said that, none of the methodologies
 that you suggest above really help that much 
in alleviating DoS attacks either. IP spoofing will counter all of the checks is it not?

One more thing that is missing in the DT draft is providing CARD services to ARs that
have private addresses, i.e. Requirement 3.3.  
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Thu, 6 Mar 2003 13:09:21 -0500

Hi James,

>Servers are used all the time for PKI. There is an article in 
>this month's ACM
>Communications about how servers are used for PKI. They are 
>used to configure
>routers, IPsec gateways, etc. Typically, LDAP is the protocol. 
>A DoS attack is
>easy to foil: put a rule in the firewall that disallows any 
>external traffic to
>the server. Also, don't advertise the address of the server 
>outside the access
>router.

In the context of the DT document, a possible DoS attack does not
even consider attacks from outside of the domain directed towards the
server as such, but inherently through the protocol operation involving the
server. Namely, a malicious MN is contaminating the cache entries of the AP 
through falsified L2-L3 mapping requests, i.e., through the cache population
mechanism that is the basis of the server approach. Firewalls won't help here!

>
>From an enterprise/ISP standpoint, tying CARD configuration to 
>a server in a
>standardized way might help to speed deployment. 

Hmm, wouldn't deployment even more speed up if we didn't have a server
at all?? The question is not whether or not a server would hinder deployment
but whether or not a server is necessary at all. I still don't see a convincing 
argument for this. The DT draft does not give one, and the current discussion
hasn't either.

Dirk

---

From: [email-masked]
Date: Thu, 6 Mar 2003 13:18:26 -0500

Jim,

I would argue that events have overtaken us and CARD is no longer relevant for
IPv4 from a market perspective. Certainly, this is the case with other advanced
IP mobility technologies, like the fast handover technologies CARD was supposed
to support. I believe it makes more sense to have CARD be a well-integrated part
of the local link movement protocols for IPv6, where there is still some
interest in technology development on advanced IP mobility technologies.

[Govind] GPRS, for example is still a technology for the near future.
I think GPRS is based on IPv4 at least now. I agree that CARD should be IPv6 amenable
but neglecting IPv4 is not correct. I disagree.

>  and helps provide a major functionality and it does belong in this document.
Maybe

First off, I'm not convinced even an OSPF extension would be the right approach.
Like I said, we need to talk with the Routing Area Directors to see what they
say. However, what suggests that it is a better approach is that the information
being conveyed is not real time, that is, it is not connected to handover. It
will vary slowly as access points are introduced or brought down. Thus, it is in
the same category as standard routing reachability information distributed by
the IGPs, and not like CT or handover.

[Govind] First, I don't think this a real time. Information transferred between does not
comprise only of the example that you talk about network topology change. Hence
I don't think we can tie everything to routing reachability information like you 
say above. 

> I think this is one direction that we do not need to go, the cost heavily
outweighs

Servers are used all the time for PKI. There is an article in this month's ACM
Communications about how servers are used for PKI. They are used to configure
routers, IPsec gateways, etc. Typically, LDAP is the protocol. A DoS attack is
easy to foil: put a rule in the firewall that disallows any external traffic to
the server. Also, don't advertise the address of the server outside the access
router.

[Govind]Even though is also manual configuration possible for PKI, I don't disagree
with PKI using servers (LDAP is just one way of doing it). 
What I disagree is with your notion that just because PKI uses it,
 CARD should use it too.  There is no need to do this. 

[Govind] DoS attack is possible because, the traffic is not coming from the external source,
it is coming from an authenticated access router because it is not able to
translate a particular AP to an AR. 

From an enterprise/ISP standpoint, tying CARD configuration to a server in a
standardized way might help to speed deployment. This component should not be a
required part of the router to host protocol, though, because the router to host
protocol could also be deployed in a small office or home environment with a Web
configuration. That's why I think it should be in a separate document.

[Govind] This is not true. The server approach needs a cache at ARs anyways. So what
ease are you talking about. By removing the server how does the protocol become
easier to deploy? This seems counter intutive to me. Are you saying that ISPs will
allow caches to be present at ARs only they have a server too?

> Technical Comments

I didn't make the distinction, it was in the draft. I think it should be
removed.
[Govind] ok.
> in alleviating DoS attacks either. IP spoofing will counter all of the checks
is it not?

If the router starts dropping requests when they come in too quickly, then it
will look to clients like it is responding more slowly, but the attacker will
not succeed in completely disrupting service. That is what is meant by 2).

[Govind] I feel that there are better, possibly not difficult, ways to make any 
DoS attack really hard to materialize. 

In addition to these measures, I think the draft should specify that standard ND
security including SEND is used on the protocol. This should completely
eliminate the possibility of IP spoofing.

[Govind] I have to read up on this before I can respond to you.

> have private addresses, i.e. Requirement 3.3.

If the IPv4 requirement is dropped, I don't think this is necessary.

[Govind] First, I don't think the IPv4 should be dropped. Secondly, I think
site-local addresses in IPv6 is also covered by this requirement. 
Third, I think non global routeability may not be just for the sake of lack
of addresses, it may be for other reasons too, like security, as you probably know.

            jak

---

From: [email-masked]
Date: Thu, 6 Mar 2003 13:58:12 -0500

Hi Jim,

The AR should *never* propagate any MN supplied information back to the server.
The server should contain a map of what are the valid, authorized AP to AR
mappings, as installed by the sysadmin.

[Govind] From what I understand, the DT draft does exactly this. If the L2-L3 mapping
for a MN supplied L2 is not available in the cache it is fetched from the server.

The rest of my note describes how to deal with weeding out bogus MN supplied
information (timeouts, weighting information supplied by multiple MNs more
highly than by a single one, etc).

[Govind]The point is this all these schemes work on the cache. They don't
need a server to exist, which is exactly my point. If you have a scheme
where in we can avoid DoS, why do we need a server?

> argument for this. The DT draft does not give one, and the current discussion

Nope. If I am a sysadmin, I want my routers to know they can trust the
information supplied by an MN. I, as a sysadmin, know what APs I've installed.
The router should not trust any information provided by the MN unless it is
validated by the map in the server.

[Govind] I agree that any MN supplied information should be validated.

---

From: [email-masked]
Date: Thu, 6 Mar 2003 13:58:12 -0500

Hi Jim,

---

From: [email-masked]
Date: Thu, 6 Mar 2003 14:02:41 -0500

Hi James,

>The AR should *never* propagate any MN supplied information 

If the (MN-)requested L2-L3 mapping does not exist in the AR cache, 
a request is sent to the server to obtain this information (maybe I missed
something in the draft). If the MN does the request for all n ARs in the scope, 
the cache will soon be filled up with all possible ARs in the scope region. But even
more, the MN can also explicitly request L2-L3 mappings of ARs that are not within the region 
(the AR does not know about the region, and it does not know whether or not the supplied 
information is correct, so it has to ask the server). The mapping is requested from the server 
by the AR, the server rejects the request (reason "out of scope region"). Result of this would be
server and AR load, i.e., DoS attack.

Another thought: Since eventually, the AR might get the L2-L3 mappings of all scope region ARs anyway 
(assuming such malicious MN above), why don't we simply push the L2-L3 mappings right from the beginning 
to the AR instead of requesting it on time???? This would bring us very close to a static configuration 
approach though.

Dirk

---

From: [email-masked]
Date: Thu, 6 Mar 2003 14:15:06 -0500

I don't see what GPRS has to do with CARD.

[Govind] Well, GPRS uses IPv4 addresses as I explained. CARD is an useful tool to 
support inter-technology handovers. I hope my point is clear now. Infact
so is CDMA2000 based networks also use IPv4 based networks. Hence IPv4 is relevant.

I think I would have to see a higher level of implementation and deployment
interest before I would be willing to change my opinion, but the trend in Mobile
IP is towards stopping any technology development in MIPv4 unless it is directly
related to deployment concerns. As a way to focus the design and reduce people's
work load, I think that would be a prudent course for Seamoby to follow as well.

[Govind] same reply as above.

(for the second and last time) Like I said, I did not say it should be an OSPF
extension. I said that we need to talk with the Routing Area Directors about
whether it is an appropriate kind of information to distribute using the IGP. It
is different from CT in that it is not tied to handover. 
There are no timing
constraints on whether this information gets between routers within a particular
time window. The information is not tied to a specific mobile node. 

[Govind] Ofcourse this is tied to handovers. This information helps best choose
the ARs, isn't it? Also, if AP information is sent as capabilities, it is the very
necessary mapping, needed for handovers.

It is
orthogonal to the router to host protocol for CARD. The information is tied to a
topology change, an AP going up or down, which is like a router going up or
down, suggesting an IGP extension. Therefore I believe it should be in a
separate document. Whether or not an IGP extension is the right approach is TBD.
[Govind] Well lets discuss this at a later stage.. we have too much on the plate
already :)

>  CARD should use it too.  There is no need to do this.

Govind, if I am a sysadmin, I don't want 50 different ways to configure my
network, I want one. Its as simple as that. Ask the sysadmin in your office if
he likes having multiple ways of doing things if you don't believe me.

[Govind] Sure, I hear you. But, I don't agree that you would need a server based
approach for your objective.

---

From: [email-masked]
Date: Thu, 6 Mar 2003 14:15:06 -0500

It is

---

From: [email-masked]
Date: Thu, 6 Mar 2003 15:00:49 -0500

Jim,

Please read what I wrote again.

"Should not propagate *from* the MN *to* the server." Please point out to me
where in the draft it says that. Fetching *from* the server is the other way
around.

[Govind] The MN sends an L2 id. It is not there in the cache.
Note the AR has no way of determining whether this is a genuine AP.
If the entry to the AP is not in the cache it is sent over to the server.
 Server responds with the mapping or probably a error
based. Doesn't the MN have direct control of what goes to the server?
Thats what I meant. Hope it is clear now. This is what I understood. The DT
draft has acknowledged that this is a problem and proposes the scope-id as
one solution for this. Look at section 6.2.

-Govind.

---

From: [email-masked]
Date: Thu, 6 Mar 2003 15:00:49 -0500

Jim,

-Govind.

---

From: [email-masked]
Date: Thu, 6 Mar 2003 18:15:55 -0500

Hi Guys:

Some clarification on possibility of DoS in current DT draft. The following DoS attacks are possible in the current protocol:

+ MN sending bogus L2 ids to current AR. This in turn means that current AR makes request to CARD server to resolve it. Server returns error condition (no such mapping or mapping out of scope ID).

+ Limiting requests per MN is not possible to avoid the above. MN may keep disconnecting and connecting back frequently, each time sending a set of bogus L2 IDs. In each reconnection, MN may acquire a different CoA, and hence, current AR cannot keep track of which MN is sending how many L2 IDs over a period of time.

+ Scope ID is simple mechanism to limit cache contamination from domain scale to region scale. However, it is easily possible that malicious node would make the cache at current AR always filled up will all ARs in scope ID.

+ If additional mechanisms are introduced such as tagging cache entries with MN identifier (as asserted by AAA when access was granted), DoS can be managed however. Then scope ID wont be necessary, IMHO. 

Hemant

-----Original Message-----
From: ext [email-masked]
[mailto:[email-masked]]
Sent: Thursday, March 06, 2003 3:01 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

Jim,

-Govind.

---

From: [email-masked]
Date: Thu, 6 Mar 2003 18:30:51 -0500

Hi James:

Please see some comments below:

----------snip-------------

Hemant -> I do not see any point in bothering all routers in domain (as OSPF updates will do) for the sake of exchanging a piece of message between two ARs. 

------------------snip-----------------------------------------
they are limited by the security measures in RFC 2461. 

Hemant -> I have not read RFC 2461 recently. But, I was curious about this. We talked a lot about this on mailing list after Steve Deering's presentation in Minneapolis. Steve advocated this as the primary way of doing CARD when there are multiple interfaces available on MN. You also quite strongly supported this view. And then, IMHO this is the most natural way to do CARD when there are multiple interfaces available. This is also ideal for inter-domain handoffs such as handoff from cellular to my home WLAN. All decisions and security issues are anchored at MN and can be easily addressed for this case. I am wondering as to what has changed between then and now.

-------------------snip-----------------------------

Hemant -> 4) can be fooled as follows: MN can disconnect and reconnect each time sending the same bogus entry. This increases the preference of that entry. At each reconnection, MN may get different CoA. So current AR cannot identify bogus requests coming from same MN (unless other mechanisms as I pointed out in my other email are introduced).

Hemant

---

From: [email-masked]
Date: Thu, 6 Mar 2003 18:30:51 -0500

Hi James:

-------------------snip-----------------------------

Hemant

---

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

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.

---

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

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

have on

---

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.

have on

---

From: [email-masked]
Date: Fri, 7 Mar 2003 12:07:37 -0500

> kind of situation from the protocol design stage. Dycard has an advantag

If you mean dycard, I don't see the alternative as any better. An MN can still
bombard the router with requests.
[Govind] The MN can bombard the AR with L2 ids, but it does not cause a deterioration
of performance in dycard as in the DT draft. 
I don't think you are correct on this. The very fact that
the DT draft asks the L2-L3 mapping from the server if not available at the AR is bound to have 
problems. 

> > > + Scope ID is simple mechanism to limit cache contamination from domain
> scale
> > to region scale. However, it is easily possible that malicious node would
> make
> > the cache at current AR always filled up will all ARs in scope ID.
> > >
> >
> > So?
> >
> [eunsoo] I gave you an example of the negative impact of this situation in
> the past. In short, it means the cache is not useful for most of other CARD
> applications except L2-L3 mapping.
>

You've missed my point.

If the cache is large enough to hold all the entries in the domain, what does it
matter if  all the entries in the domain are in the cache?

[Govind] The problem is that dynamic updates need refreshing. This leads to unnecessary
communication between ARs that are not CARs. The more the number of such incorrect entries
more the communication, which is another DoS.
  Also, once all genuine entries are in the cache
why would you ever need a server? 
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Fri, 7 Mar 2003 12:07:37 -0500

You've missed my point.

---

From: [email-masked]
Date: Fri, 7 Mar 2003 12:45:36 -0500

Hi James:

The bogus AP is understood as an AP that is "not physically adjacent" to current AP. The bogus AP may be valid AP in the domain (attached to another AR) or non-existent. 

Scope ID solution restricts the bogus AP (in non-physical adjacency sense) DoS on AR cache to a subset of domain APs. If AP does not exist in the domain, an error is returned from CARD server.

- Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Friday, March 07, 2003 12:16 PM
To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston);
[email-masked]
Cc: [email-masked]
Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

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

> 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.

---

From: [email-masked]
Date: Fri, 7 Mar 2003 12:45:36 -0500

Hi James:

- Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Friday, March 07, 2003 12:16 PM
To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston);
[email-masked]
Cc: [email-masked]

            jak

---

From: [email-masked]
Date: Mon, 10 Mar 2003 10:10:42 -0500

Hi James,

>> something in the draft). If the MN does the request for all 
>n ARs in the
>scope,
>> the cache will soon be filled up with all possible ARs in 
>the scope region.
>But even
>> more, the MN can also explicitly request L2-L3 mappings of 
>ARs that are not
>within the region
>> (the AR does not know about the region, and it does not know 
>whether or not
>the supplied
>> information is correct, so it has to ask the server). The 
>mapping is requested
>from the server
>> by the AR, the server rejects the request (reason "out of 
>scope region").
>Result of this would be
>Where's the denial of service? All you've described above is 
>how the router
>cache gets populated by all the APs in the region. Properly 
>sizing the router
>cache is required, of course.

Well, it was said quite a lot, but maybe another time would help to get the picture.
You've got two cases. One is to have a malicous MN sending in-scope L2 id to the 
AR. This eventually leads to filling up the cache with all scope L2 id. But I wasn't talking
about this case. In the case described above, the malicous MN requests L2-L3 mappings
of ARs that are not within the region. Since the AR cannot figure this out, it will forward
the request to the server, asking for resolving. The server will answer (correctly) with "out-of-region" 
(or whatever). If the MN keeps injecting these kind of requests, you'll add load to the server. The cache
will not get populated at all, but the AR and server keep communicating.

Dirk

---

From: [email-masked]
Date: Mon, 10 Mar 2003 10:10:42 -0500

Hi James,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 10:37:44 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 10, 2003 9:11 AM
To: [email-masked]; [email-masked];
[email-masked]

Hi James,

AJOY-> I think this can be easily solved by maintaining some soft-state  
at AR. AR should able to track the number of requests made by connected
MN during given time interval. The AR should avoid forwarding request from 
malicious MN to the CARD server once the number of attempts crosses the 
pre-configured threshold. I am sure there are lots of other ways
to solve this problem.

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 10:37:44 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 10, 2003 9:11 AM
To: [email-masked]; [email-masked];
[email-masked]

Hi James,

Dirk

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:05:40 -0500

Hi Ajoy:

I do not see how AR can track number of request from a specific malicious node. When node disconnects and reconnects, it appears as a completely different node to AR. To pinpoint MN's identity additional mechanisms may be needed.

Hemant

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Monday, March 10, 2003 11:38 AM
To: Trossen Dirk (NRC/Boston); [email-masked]; Krishnamurthi
Govind (NRC/Boston); [email-masked]
Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 10, 2003 9:11 AM
To: [email-masked]; [email-masked];
[email-masked]

Hi James,

Dirk

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:05:40 -0500

Hi Ajoy:

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 10, 2003 9:11 AM
To: [email-masked]; [email-masked];
[email-masked]

Hi James,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 11:28:54 -0600

Hi Hemant,

I do not see how AR can track number of request from a specific malicious
node. When node disconnects and reconnects, it appears as a completely
different node to AR. To pinpoint MN's identity additional mechanisms may be
needed.

AJOY-> You can always maintain history information that is independent of 
MN call state. You just need to uniquely identity MN. You can use
information
such as user name, NAI or IMSI to do this. BTW, I am just talking 
about some soft-state that should be cached only for pre-configurable 
amount of time. 

Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 10, 2003 11:06 AM
To: Ajoy Singh; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

Hi Ajoy:

I do not see how AR can track number of request from a specific malicious
node. When node disconnects and reconnects, it appears as a completely
different node to AR. To pinpoint MN's identity additional mechanisms may be
needed.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 10, 2003 9:11 AM
To: [email-masked]; [email-masked];
[email-masked]

Hi James,

>cache is required, of course.

Well, it was said quite a lot, but maybe another time would help to get the
picture.
You've got two cases. One is to have a malicous MN sending in-scope L2 id to
the 
AR. This eventually leads to filling up the cache with all scope L2 id. But
I wasn't talking
about this case. In the case described above, the malicous MN requests L2-L3
mappings
of ARs that are not within the region. Since the AR cannot figure this out,
it will forward
the request to the server, asking for resolving. The server will answer
(correctly) with "out-of-region" 
(or whatever). If the MN keeps injecting these kind of requests, you'll add
load to the server. The cache
will not get populated at all, but the AR and server keep communicating.

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 11:28:54 -0600

Hi Hemant,

Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 10, 2003 11:06 AM
To: Ajoy Singh; [email-masked]; [email-masked];

Hi Ajoy:

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 10, 2003 9:11 AM
To: [email-masked]; [email-masked];
[email-masked]

Hi James,

Dirk

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:35:12 -0500

Hi Ajoy,

[Govind] As pointed out earlier, this is not restricted to a malicious MN.
A non-malicious MN can cause this kind of situation too, by reporting beacons
that are not in the same domain. 

Dirk

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:35:12 -0500

Hi Ajoy,

Dirk