Subject: RE: [Seamoby] Topic #1: Dos Attack

From: [email-masked]
Date: Mon, 10 Mar 2003 15:38:41 -0500

Hi James, 

one addition to this. Even though the MN can also bombard the router with
messages in the dycard approach, the damage is local. In the server-based 
approach, there is communication happening between router and server, affecting
other network elements. 

Dirk

>-----Original Message-----
>From: ext [email-masked] [mailto:[email-masked]]
>Sent: Monday, March 10, 2003 3:34 PM
>To: [email-masked]; [email-masked]
>Subject: RE: [Seamoby] Topic #1: Dos Attack
>
>
>Hi James:
>
>See comments below:
>
>-----Original Message-----
>From: ext James Kempf [mailto:[email-masked]]
>Sent: Monday, March 10, 2003 3:00 PM
>To: [email-masked]
>Subject: [Seamoby] Topic #1: Dos Attack
>
>
>One objection that was raised to having a server provide the 
>list of authentic
>access points is that an MN can launch a DoS attack on the server.
>
>If the router uses a softstate cache, the server load will 
>only occur if the MN
>presents a new AP id. 
>
>Hemant -> Agree.
>
>Now, it is possible that an MN can attack by making up AP
>ids and sending them to the router. 
>
>Hemant -> Agree.
>
>A properly provisioned server should be able
>to handle that if the attacking MN tries to pose as a legitimate one by
>regulating its traffic. 
>
>Hemant -> Are you defining legitimate MN as the one whose 
>authenticity has been asserted to router by AAA during 
>connection phase? I think this is right assumption. But, this 
>MN can launch the above attack too. So, MN can be legitimate, 
>still malicious (or erroneously configured/programmed MN).
>
> The server capacity must be large enough to handle the
>routers that are using it. 
>
>Hemant -> Agree.
>
>If the MN doesn't regulate traffic and it bombards
>the router, the router can selectively drop message packets if 
>the message
>volume becomes too large. 
>
>Hemant -> We need to describe at least MAY method of how 
>selective dropping is achieved. In IPv6, AR identifies MN with 
>CoA. An MN that disconnects and reconnects gets different CoA. 
>Thus, MN can keep disconnecting and reconnecting each time 
>sending a bunch of bogus L2 IDs.
>
>Thus, service degrades but is not denied, until the
>sysadmin finds the offending MN and takes it off the air.
>
>Hemant -> Service degradation is a form of DoS. But, we have 
>to live with that.
>
>Note that the same problem, an MN bombarding a router with 
>packets, can occur
>for dycard as well, so it is not exclusive to the server approach.
>
>Hemant -> I think so.
>
>What am I missing?
>
>            jak
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby
>_______________________________________________
>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: "James Kempf" <[email-masked]>
Date: Mon, 10 Mar 2003 13:41:49 -0800

Agreed the server is a bottleneck if the router has to resolve unidentified APs
against the server.

If the number of ARs per server is kept small, the scope-id can be dumped. And
the server can download the list of authentic APs to the routers once, when they
start. After that, the router just compares with the list, the server pushes new
authentic APs to the router when they appear or deletes ones when they
disappear.

The server is really only useful for allowing the sysadmin to control which APs
are authentic and which not, for some collection of routers. Otherwise, each
router would have to be configured by hand.

How does dycard propose giving a sysadmin control over what APs are recognized
as authentic and what are not?

In any case, this is why I think the issue of a server does not belong in the
base draft.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Mar 2003 13:41:49 -0800

jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Mar 2003 15:41:09 -0800

> Agreed the server is a bottleneck if the router has to resolve unidentified
APs

Furthermore, I think dycard has the same problem. Pg. 5, 4th paragraph from the
top draft-trossen-seamoby-dycard-01.txt:

    To further verify the contents of the RI message, the AR sends a Physical
    Neighbor Exchange (PNE) message (see Sectoin 4.7) to pAr. The
    PNE includes both the new and previous AP identifiers, pAP and nAP.
    pAR verifies that pAP is indeed valid via its own local PNC entries, and
    the the MN was recently present. pAR replies to nAR, indicating the
    result of the validation. If the report was valid, pAR updates its own
    PNC with an entry for nAR and nAP.

It's the same attack as in the previous case, except this time the nAR ends up
bombarding the pAR with PNE messages.

Note that if the AR only accepts messages from MNs for which it has established
an authentication relationship (AAA or SEND), then the MN can use only one IP
address, and the router can rate limit on that address. This technqiue can be
used regardless of whether the back end queries a database on a server or
queries a neighboring router. Messages from a nonauthenticted address are thrown
away.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Mar 2003 15:41:09 -0800

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 10 Mar 2003 20:15:39 -0800

James,

My comments are inline.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Monday, March 10, 2003 3:41 PM
Subject: Re: [Seamoby] Topic #1: Dos Attack

>
> > Agreed the server is a bottleneck if the router has to resolve
unidentified
> bombarding the pAR with PNE messages.

I don't understand where there is anything in dycard similar to the server
of the server approach.
The pAR is not a server where all the ARs in the domain should communicate
with.
The nAR will send PNE to pAR only when its identity was reported by a MN and
the nAR does not have a record about the pAR. Once the nAR recognize the pAR
as one of its neighbors, the nAR does not have to send PNE to the pAR even
if lots of MNs report about the pAR.

> queries a neighboring router. Messages from a nonauthenticted address are
thrown

I think Dycard assumes that MN is authenticated and it is known to AR.
Checking identity of the MN is an important part of the security aspects of
Dycard.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 10 Mar 2003 20:15:39 -0800

James,

My comments are inline.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>;

unidentified

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 10 Mar 2003 20:24:19 -0800

James,

My comments are inline.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, March 10, 2003 1:41 PM
Subject: Re: [Seamoby] Topic #1: Dos Attack

> Agreed the server is a bottleneck if the router has to resolve
unidentified APs
> against the server.
>
> If the number of ARs per server is kept small, the scope-id can be dumped.

[eunsoo] Are you proposing many servers per domain? Then we will end up with
many kind of sub-domains across which CARD does not work in the server
approach. This is not a good situation because we cannot take any advantage
of CARD across sub-domain boundaries.

 And
> router would have to be configured by hand.
[eunsoo] It seems that you are advocating the server as a kind of network
management system. If any network admin needs really remote configuration of
ARs, she/he can use other existing tools. We don't need to invent any new
protocol for this. So the idea of the server approach is allowing system
admin to update the L2-L3 mapping table on each AR from a central office
rather than visiting one by one?

> as authentic and what are not?
[eunsoo] In dycard, the system admin can set up a policy such that only
authorized or classifed APs should be recognized in the CARD process.

> In any case, this is why I think the issue of a server does not belong in
the

[eunsoo] I think the server is one of the central issues of the DT draft.
The fundamental question is whether we need the server at all for CARD.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 10 Mar 2003 20:24:19 -0800

James,

My comments are inline.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, March 10, 2003 1:41 PM
Subject: Re: [Seamoby] Topic #1: Dos Attack

unidentified APs

 And

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 08:36:00 -0800

> if lots of MNs report about the pAR.

Suppose MN starts making up pAR addresses and bombarding nAR with them? nAR must
send PNE messages to resolve, causing a DoS attack on nAR, even though the pAR
don't exist.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 08:36:00 -0800

jak