Subject: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: [email-masked]
Date: Tue, 05 Nov 2002 06:07:21 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Mobile IPv6 Fast Handovers for 802.11 Networks
	Author(s)	: P. McCann
	Filename	: draft-mccann-mobileip-80211fh-01.txt
	Pages		: 14
	Date		: 2002-11-4
	
This document describes how a Mobile IPv6 Fast Handover [2] can be 
implemented on a wireless LAN conforming to the 802.11 suite of 
specifications [3].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-mccann-mobileip-80211fh-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-mccann-mobileip-80211fh-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pete McCann <[email-masked]>
Date: Tue, 5 Nov 2002 13:46:50 -0600

Hi,

As you can see from the announcement, I have submitted a revised
version of the Fast MIPv6 for 802.11 links.  I haven't taken the time
yet to revise this according to the -05 version of the FMIPv6 draft; I
have merely incorporated the comments received on the original
version.  However, I think it is still a useful discussion document
and hopefully we can talk about how to progress both documents at the
meeting in Atlanta.

My personal recommendation is that we split the FMIP work into two
pieces: (1) The specification of F-BU, F-BACK, and related security
considerations, and (2) the specification of mechanisms like
PrRtAdv/Sol, which seem less useful in the short term and which might
anyway be integrated with CAR or link layer signaling eventually.

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 07 Nov 2002 16:41:16 -0800

Hello Folks,

there is good discussion going on here. I would like
to clarify few points that might be useful.

- the current version of FMIPv6 always creates a
   tunnel for previous CoA between the routers. This
   is done because,
   - the new CoA can be used as src IP address
       only after RR completes
   - the MN is assured of receiving packets (using previous
      CoA) even if anticipation of new CoA fails
(See Yokohama presentation and subsequent
  discussion on the mailing list)

Tunnel establishment can occur via PrRtSol/PrRtAdv or
by link-layer movement detection mechanisms.
In any case, forwarding on the tunnel can only occur after
F-BU is received by the PAR.

- Anticipation is always allowed via PrRtSol and
    PrRtAdv.

So, the distinction between "tunnel-based" and
"anticipated" handover is not what it used to be, I guess.
Anticipated handover includes tunnel establishment,
however, I cannot see how anticipation can occur
without exchanging PrRtSol/PrRtAdv (unless you relegate
new prefix information to L2 messages).

Please continue..

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 07 Nov 2002 16:57:18 -0800

Hello Pete,

> and hopefully we can talk about how to progress both documents at the

It is useful. However, I strongly recommend folks to read v05. Many
issues surrounding "tunnel-based" and "anticipation" have progressed
further.

> anyway be integrated with CAR or link layer signaling eventually.

It is not entirely clear to me why you are making such a recommendation.

- PrRtSol/PrRtAdv are available to anyone who wants to use them, just
    as link-layer assisted tunnel establishment is allowed. Just as you would
    argue that few drivers support anticipation, one could point out the need
    for a protocol between AP and AR to convey link status changes. I believe
    you have noted this in your draft.

- As I have indicated in the past, CARD must not be a requirement to
    run fast handovers. I can use a pre-configured map and fast handover
    would run fine. So, the argument that CARD is doing the work is a
    source of good reference :-)

- I think PrRtAdv can be useful to trigger a sort of "redirect" for "load
    balancing" purposes. And why not ? The traditional logic for load balancing
    could be extended to handle mobility when routers have knowledge of
    their adjacent neighbors.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 08:23:55 -0800

>     their adjacent neighbors.

This is an interesting idea but it won't work for 802.11. 802.11 handover is
purely mobile driven.

            jak

---

From: Pete McCann <[email-masked]>
Date: Fri, 8 Nov 2002 11:23:30 -0600

Hi, Rajeev,

 > issues surrounding "tunnel-based" and "anticipation" have progressed

Yes.

 >     you have noted this in your draft.

Yes, which is why I think tunnel-based should be handled in the IEEE
as an inter-AP traffic forwarding protocol.  PrRtSol/PrRtAdv could
remain available in a separate draft, and I am not saying we should
stop exploring AR discovery protocols of this type.  However, there
seems to be a clearer case for the applicability of F-BU and F-BACK
on all kinds of 802.11 firmware, not just those that support
anticipation.  You can use these messages after handoff has completed
and still derive some benefit.  Partly this situation arose because
F-BU/BACK were moved out of the MIPv6 base protocol and a decision was
made to put them in FMIPv6; if they had stayed in the base protocol I
would not be arguing for any restructuring of FMIPv6, although in that
case I would tend to make the whole thing experimental.  So partly
this is just a re-shuffling and prioritization of the functionality.

 >     source of good reference :-)

I don't think CARD is a requirement.  You could run F-BU/F-BACK
entirely after link layer handover, and discover the new AR through
normal router solicitation.  Or, there might be link-layer tricks that
can be played.  All you want is the IP address of the new AR, and I
think that discovery problem should be separate from the tunnel
establishment/packet forwarding mechanism.

 >     their adjacent neighbors.

Sure, but the MN can also pick a router from a list of responders,
without requiring a middle box to do the mapping.

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 09:37:33 -0800

> This is an interesting idea but it won't work for 802.11. 802.11 handover is

The MN always makes the ultimate decision. However, why
won't a message from the AR with the new AP, AR info
could not be used to switch links ?

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 09:57:37 -0800

> establishment/packet forwarding mechanism.

I think it would have to be the other way around. You would have to do the RS/RA
first, in order to get the link layer address of the router to which to send the
F-BU, right?

Also, what would be the return address on the F-BU? It can't be the old CoA
because the new AR's ingress filter will drop it.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 10:00:55 -0800

> could not be used to switch links ?

Because in a typical 802.11 deployment, the AR knows nothing about APs connected
to it.

See my previous rant about taking APs seriously as IP devices.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 10:16:25 -0800

> Because in a typical 802.11 deployment, the AR knows nothing about APs connected

Ok. In a deployment which supports fast handover, AR can maintain
a table containing the AP information.

-Rajeev

---

From: Pete McCann <[email-masked]>
Date: Fri, 8 Nov 2002 13:50:55 -0600

Hi, James,

 > first, in order to get the link layer address of the router to which to send the

Yes, assuming you didn't get it from link layer signaling.  And in the
long run, PrRtAdv or CARD may be the right approach --- I just don't
think we should put it in the same document as F-BU.

 > because the new AR's ingress filter will drop it.

If this is really a problem we could set it to the unspecified (0)
address, but maybe we will need to configure ARs so that they don't do
this sort of ingress filtering until an address has been assigned.  If
you think about it, there will probably be some sort of link layer
security in place and the AR should probably do per-MAC address
ingress filtering anyway, assuming it is serving mutually untrusted
users with access to the Internet.  This would be needed to prevent
user A from using B's IP source address while connected to the same
AR.  As long as we are maintaining this state per-MAC address, it
would be no big deal to have special processing for "address
assignment" type messages (like F-BU) and then install an ingress
filter once we know the address, even if it is from a different
subnet.  The PDSN in cdma2000 behaves similarly.

-Pete

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 8 Nov 2002 12:58:57 -0800

> subnet.  The PDSN in cdma2000 behaves similarly.

I agree with Pete that, allowing F-BU packets with topologically
incorrect address forwarded by newAR shouldn't be an issue for ingress
filtering environments.

Ingress filtering is about tracability, and if a MN launches an attack
on an AR by exploiting this "pinhole", believe me, it'll be easily
identified
within the access network.

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 8 Nov 2002 12:54:19 -0800

> as an inter-AP traffic forwarding protocol.  

I agree. 

alper

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 13:50:51 -0800

I disagree. I think this is a major security hole, and I don't think the ADs are
going to allow the null address to be used in this case any more than they were
prepared to allow it to be used for PANA.

            jak

---

From: Pete McCann <[email-masked]>
Date: Fri, 8 Nov 2002 16:29:36 -0600

Hi, James,

My understanding is that the decision was made for PANA based on a
lack of a perceived need for the unspecified address among working
group members, not by AD fiat.  I also thought there might be some
room to reconsider this decision.

Note that Router Solicitations are allowed to use the unspecified
source address, and they must pass through ingress filters in order to
work.  Maybe you are saying that, for security, a Router Solicitation
is the only kind of IP packet that is allowed to use the unspecified
source address.  Maybe you are imagining some sort of reflector attack
using F-BUs.  I don't see how those are really practical, especially
given the security associations we are presuming to be in place
between ARs.

Anyway, I think we should also allow PCOA for F-BU, because that way
the MN doesn't need to distinguish whether it sent the packet on the
old or new link; it looks the same either way.  I don't see why we
have to have HI/HACK to install an ingress filtering pinhole at the
new AR.  If the F-BU doesn't pass the security checks at the old AR
the operation will fail and the ARs won't allow traffic to pass
to/from the MN.

-Pete

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 8 Nov 2002 15:08:42 -0800

> prepared to allow it to be used for PANA.

I wasn't necessarily in agreement with the unspecified address use actually,
just topologically incorrect address use (e.g., oldCoA). And this discussion
does not relate to PANA discussion on unspec. address use.

How is this creating a major security hole? What is it that the attacker can
do, and how does the administrator of the access network (collection of ARs
and
more) cannot identify the offender? Note that the pinhole in the filter
should
just allow a host to send a FBU to one of the ARs, that's it.

alper

> > >  > Also, what would be the return address on the F-BU? It can't be the
old
> > CoA

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 08 Nov 2002 16:11:01 -0800

Hello Jim,

I hate to jump in these difficult and choppy waters, but it
seems to me that any security problem is not going to be
solved by choice of address.  Instead, the mobile node will
have to supply some data that proves it deserves to be the
recipient of any state associated with the fast handover.

This is also a problem relevant to context transfer, which is
likely to be going on at the same time as the fast handover.

Whether or not the mobile node is addressable at a topologically
correct care-of address is really beside the point.

Furthermore, I'm pretty sure that ingress filtering is also
quite much beside the point.  If I read about what ingress
filtering is supposed to do, and the threats it is supposed
to protect against, then I don't see any relevance to this
discussion.

See you in Atlanta!

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 16:19:49 -0800

"Alper E. YEGIN" wrote:

>  Note that the pinhole in the filter
> should

Indeed, this is what v05 draft says in Section 4.2

"First, the ingress filtering rules allow packets sent with PAR's
   prefix in a source address to be forwarded.  Second, the destination
   IP address is that of the PAR. Note that both these conditions must
   be met for succesful completion of any HI and HAck message exchange
   in any case."

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 11:32:07 -0800

> just allow a host to send a FBU to one of the ARs, that's it.

It allows someone to mount a DoS attack on the router. The attacker can't be
confined to operating from the same link because the old router could be at
arbitrary topological distance away from the new link.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 11:38:59 -0800

> to protect against, then I don't see any relevance to this

How about an untracable DoS attack?

            jak

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 11 Nov 2002 13:07:12 -0800

Hello Jim,

> How about an untracable DoS attack?

MMM... well, no thanks, none for me please.

Maybe I didn't read enough e-mails, but I thought we
were discussing the problem where a mobile node was
trying to signal its new access router.  In another note, you
stated that we could not assume (..?the mobile node?...)
was on-link, and something about the oAR, so maybe
I should wait until I get better than 25 Kb/s link and
read more e-mails.

However, in case you WERE discussing signaling
between the mobile node and nAR, then my original
comments stand.  If you are worried about off-link
attacks, then that is solvable in several good ways.

Bye for now...

Regards,
Charlie P.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 11 Nov 2002 13:17:58 -0800

> arbitrary topological distance away from the new link.

This can have limited impact, because the type of packets allowed is very
specific.

Attacker cannot send lots of packets, because a legitimate MN doesn't need
that, and any reasonable newAR won't let this happen.

newAR and oldAR has to be in the same "fast handover domain", or something.
So, MN shouldn't be allowed to send FBU to arbitrary destinations. A simple
filter
on newAR can provide this control.

If, after all these, oldAR is still subject to attacks, the offender can be
found by logging FBUs on the newAR. This is not an Internet-wide problem,
just in
an access network, so it should be managable.

alper

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 13:58:17 -0800

> that, and any reasonable newAR won't let this happen.

Hmm. Tell that to the guys that mounted the DoS attack on the root domain
servers a couple weeks ago. A host resolving DNS names also typically doesn't
need more than one request.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 11 Nov 2002 21:47:27 -0800

> need more than one request.

But the access routers all across the Internet doesn't know that, right?
If they did, they could perhaps rate-limit the attackers.

This is very well possible with F-BU, and access routers in
a fast handover domain.

Your example DoS attack is executed under significantly different
conditions and assumptions.

alper

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 11 Nov 2002 13:07:12 -0800

Hello Jim,

Bye for now...

Regards,
Charlie P.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 11 Nov 2002 13:17:58 -0800

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 11 Nov 2002 21:47:27 -0800

alper