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

From: [email-masked]
Date: Mon, 10 Mar 2003 15:53:03 -0500

James,
I think the answers to these questions are there in previous threads. Anyways,
here they are again embedded. I think, the fundamental topic is to be discussed before is
whether we need a server at all.

[anip]

If the router uses a softstate cache, the server load will only occur if the MN
presents a new AP id. Now, it is possible that an MN can attack by making up AP
ids and sending them to the router.

[snip] Not necessarily. A MN could be reporting APs not in the same domain. 
This is not a malicious MN. 

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. The server capacity must be large enough to handle the
routers that are using it.
[snip]

 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. Thus, service degrades but is not denied, until the
sysadmin finds the offending MN and takes it off the air.

[Govind] Even when talking about malicious MNs, I don't think this is so simple, 
unless you track MNs that are making requests as what dycard does. Unless as 
Hemant pointed out, it is quite easy to deceive. 

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.

[Govind] In dycard, cache entries are not created because MNs hear the beacons. In the DT
draft the protocol attempts to create cache entries based on
what a MN hears. This is fundamental problem (?). I therefore don't understand the DoS
attack you are referring to w.r.t to dycard. 

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

---

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

> attack you are referring to w.r.t to dycard.

Pg. 4, last paragraph on the page, draft-trossen-seamoby-dycard-01.txt:

    Following a handover, a MN informs its new access router (nAR)
    as seen in Figure 1, about its prevous point of attachment. In
    particular, the MN sends to nAR a Router Identity (RI) message
    (see Section 4.2) containing the IP address of the previous access
    router (pAR), the link-layer address of the prevous access point,
    as well as the link layer address of the new AP.  So, for the
    scenarios depeicted in Figure  1, the MN would send the tuple
    (pAR,pAP,nAP) to nAR.

Now, suppose, instead of just sending a single message, the MN pumps out a
stream of packets at one per millisecond in order to tie up the router
processing packets. Suppose the MN changes the IP address or uses other tricks
so that the AR can't filter based on whether or not the MN is legitimate. That's
the DoS attack I'm talking about.

Furthermore, there is a problem with the information tuple in the dycard
message. It is useless to the next MN that wants to come along and handover to
pAR. Where does the MN get pAR's IP address? According to RFC 2461, a router
never gives out a global IP address in ND. Yes, I know you can get one via
traceroute so this prohibition has little effect on anything but the RFC says
link local addresses are a MUST. Are you proposing a change in RFC 2461? What
the MN really needs when it hands over to pAR is the L2 address on the wireless
interface for pAR. So that it can send packets to pAR for forwarding without
having to solicit an RA. Also the subnet prefix(s) and any other router
configuration information so that it can perform address configuration without
having to solicit an RA.

            jak

---

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

jak

---

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

James,

My comments are inline.

> > what a MN hears. This is fundamental problem (?). I therefore don't
understand
> the DoS
[eunsoo] As I said in a previous email, authenticating MN is an important
requirement for security in Dycard. The problem of the server approach is
that authenticating MN does not help preventing MN from doing cache
contamination. There is no way to prevent MN from causing cache
contamination in the server approach as far as I understand. If I am missing
something, please let me know.

> interface for pAR. So that it can send packets to pAR for forwarding
without

[eunsoo] I think you were confused here. What MN needs eventually is L3
address (IP address) of pAR for fast handoff when it hands over to pAR. I
don't understand how MN can send packets to pAR without knowing pAR's IP
address unless the packets are for multicasting or broadcasting.

Also the subnet prefix(s) and any other router
> configuration information so that it can perform address configuration
without

Eunsoo

---

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

James,

My comments are inline.

understand

Eunsoo

---

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

> something, please let me know.

What is your definition of cache contamination?

> address unless the packets are for multicasting or broadcasting.

No it doesn't. Currently, FMIPv6 uses a global address for pAR in only one way:
the MN sends FBU to pAR to set up the tunnel. But providing security for this
has been a problem, and there is discussion in the MIP group for the signaling
to go to the current AR (whether pAR or nAR is immaterial) to set up the tunnel.
That way, SEND could be used to secure the signaling (possibly with some
authorization token to the pAR, that is still under discussion) between the MN
and AR, and the HI/HAck would be secured using the interrouter security
association.

With dycard, nAR needs pAR's address from the MN in order to be able to send
PNE. Dycard establishes a dependency on the global IP address of the router
being provided by the MN which may not be there in the end for fast handover.

This is one reason why I think the CARD work needs to be moved into the MIP
group (or, at least, the MN to AR part). Seamoby could end up designing a
protocol that doesn't provide what FMIP needs.

            jak

---

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

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 13:59:23 -0800

> What is your definition of cache contamination?
[eunsoo] Hmm, strange. I have used the term in the same way as before.
Anyway, I mean putting wrong entries (that is, entries for AR that are not
CAR) in the cache (the CAR table). Even if an entry is for an AR that is
within the domain and authentic, it is a wrong entry if it is not a
candidate access router for the AR where the cache is located.

> and AR, and the HI/HAck would be secured using the interrouter security

[eunsoo] Whether MN talks to nAR directly or pAR talks to nAR on behalf of
MN does not make a difference in the requirement that MN needs IP address of
nAR for fast handoff. That's the reason L2-L3 mapping became an issue which
we are tackling with now. If pAR talks to nAR on behalf of MN, nAR needs to
know IP address of pARand that information should come from somewhere. L2
address of nAR is usefuly only when L2-L3 mapping is possible and that's
what CARD enables.

> being provided by the MN which may not be there in the end for fast
handover.

[eunsoo] I don't understand this. You don't need globally routable IP
address of nAR (or something similar) for fast handoff? If not, how does pAR
or MN talk to nAR?

> protocol that doesn't provide what FMIP needs.
[eunsoo] I think many people in the SeaMoby WG participate in the MIP WG or
at least monitor the development there. Of course, folks in MIP WG can
participate in our discussion any time. Also FMIPv6 is still evolving and
thus we cannot wait until FMIPv6 is finalized. While we have the DT draft
(version 01) and serious discussion going on, I don't think it is a good
idea to think of moving the work to another WG.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 13:59:23 -0800

Eunsoo