Subject: [mobile-ip] are L2 triggers "secure" ?

From: John Williams Floroiu <[email-masked]>
Date: Thu, 23 May 2002 17:34:45 +0200

Hi,

I would like to rise a question regarding the tunnel based handover (section 3.2 in
draft-ietf-mobileip-fast-mipv6-04.txt). I believe the use of L2
triggers might introduce some security holes as long as their "safety" cannot be correctly assess by the layer 3.

I am not a L2 technology expert, therefore I am not sure how L2 triggers are actually implemented. However, taking as an
example the scenario described in fig. 8 (p.25), and trying to extrapolate somehow the functionality of WaveLAN (which
is not the only but anyway the most widely considered case study), I could imagine the situation described below
occurring.

An attacker spoofing the MAC address of a legitimate MN may force itself to attach to a different access point (nAP)
than the one the MN is currently using (oAP). This event happening at the nAP is most probably the source of a L2-TT
trigger nAR is going to receive, and the effect is that the incoming MN traffic is going to be mis-routed, since the
reception of L2-TT at nAR triggers the initiation of the handover between (a false) nAR and oAR --- well I do not really
know how nAR could learn the address of oAR in general, again, maybe some technologies which I do not know about support
this.

The bottom line is that an attacker spoofing the identity --- MAC address or whatever ID appearing in the radio control
messages, like WaveLAN beacons --- of a legitimate mobile terminal, can produce fake L2 triggers by attaching to false
access points, and mount in this way DoS attacks against MNs.

John.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 23 May 2002 09:26:14 -0700

I don't recall if the FMIPv6 draft specifically mentions this, but in
the low latency MIPv4 draft we do mention that the MAC layer needs to be
secure in order to use tunnels. In FMIPv6, this is true both for Prereg
and Postreg/BETH, since tunnels are used for both. Perhaps the draft
needs changing.

In addition, you are correct that 802.11 security won't currently allow
secure tunnels.  However, it should also be noted that on 802.11
including 802.1x, ARP and ND are not secure either. There is no way to
prevent a host from stealing a MAC address on 802.11, unlike switched
Ethernet where 802.1x ties a switch port to the MAC address and won't
allow the host to change it.

            jak

----- Original Message -----
From: "John Williams Floroiu" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 23, 2002 8:34 AM
Subject: [mobile-ip] are L2 triggers "secure" ?

> triggers might introduce some security holes as long as their "safety"
cannot be correctly assess by the layer 3.
>
> I am not a L2 technology expert, therefore I am not sure how L2
triggers are actually implemented. However, taking as an
> example the scenario described in fig. 8 (p.25), and trying to
extrapolate somehow the functionality of WaveLAN (which
> is not the only but anyway the most widely considered case study), I
could imagine the situation described below
> occurring.
>
> An attacker spoofing the MAC address of a legitimate MN may force
itself to attach to a different access point (nAP)
> than the one the MN is currently using (oAP). This event happening at
the nAP is most probably the source of a L2-TT
> trigger nAR is going to receive, and the effect is that the incoming
MN traffic is going to be mis-routed, since the
> reception of L2-TT at nAR triggers the initiation of the handover
between (a false) nAR and oAR --- well I do not really
> know how nAR could learn the address of oAR in general, again, maybe
some technologies which I do not know about support
> this.
>
> The bottom line is that an attacker spoofing the identity --- MAC
address or whatever ID appearing in the radio control
> messages, like WaveLAN beacons --- of a legitimate mobile terminal,
can produce fake L2 triggers by attaching to false

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 May 2002 10:17:26 -0700

Hello John,

I believe that any Fast Handover message (perhaps including
Context Transfer options) used by a mobile node to "confirm"
its arrival at the new access router MUST contain authentication
data.

Regards,
Charlie P.

---

From: John Williams Floroiu <[email-masked]>
Date: Thu, 23 May 2002 19:26:21 +0200

James,

> In FMIPv6, this is true both for Prereg

sorry, but who exactly are "Prereg" and "Postreg", I could only find HI, HACK and HTT.

> [...] switched

okay, but this applies I guess to wired infrastructures rather than wireless ones.

John.

---

From: "Robert J Marks" <[email-masked]>
Date: Thu, 23 May 2002 12:42:21 -0500

Hi Charlie,

I believe it depends upon the capabilities and requirements
of the access network. I do not think that all access networks
require authentication data in a "handoff confirmed" message.

Bob

Charles E. Perkins wrote:
> > triggers might introduce some security holes as long as 
> their "safety" cannot be correctly assess by the layer 3.
> > 
> > I am not a L2 technology expert, therefore I am not sure 
> how L2 triggers are actually implemented. However, taking as an
> > example the scenario described in fig. 8 (p.25), and trying 
> to extrapolate somehow the functionality of WaveLAN (which
> > is not the only but anyway the most widely considered case 
> study), I could imagine the situation described below
> > occurring.
> > 
> > An attacker spoofing the MAC address of a legitimate MN may 
> force itself to attach to a different access point (nAP)
> > than the one the MN is currently using (oAP). This event 
> happening at the nAP is most probably the source of a L2-TT
> > trigger nAR is going to receive, and the effect is that the 
> incoming MN traffic is going to be mis-routed, since the
> > reception of L2-TT at nAR triggers the initiation of the 
> handover between (a false) nAR and oAR --- well I do not really
> > know how nAR could learn the address of oAR in general, 
> again, maybe some technologies which I do not know about support
> > this.
> > 
> > The bottom line is that an attacker spoofing the identity 
> --- MAC address or whatever ID appearing in the radio control
> > messages, like WaveLAN beacons --- of a legitimate mobile 
> terminal, can produce fake L2 triggers by attaching to false

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 May 2002 10:50:04 -0700

Robert J Marks wrote:

Hello Bob,

Maybe the layer-2 messages don't require authentication, but
I reckon the layer-3 messages do.  The only way otherwise would
be if every router within the access network had very rigid
controls and filters on every layer-3 packet, which seems
un-IP-like to me.

Regards,
Charlie P.

---

From: John Williams Floroiu <[email-masked]>
Date: Thu, 23 May 2002 20:08:38 +0200

Charles,

> I reckon the layer-3 messages do.  [...]

True, but in case of tunnel-based handover the layer 3 messages are exchanged only between ARs. It can be assumed they
are secure (they can be made secure), but the L2 triggers themselves may not. Could layer 3 rely on layer 2 security
(when deciding a handover) ? Encryption in WaveLAN - which proved to be quite easy breakable - is the first example
coming into my mind.

Regards,
John.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 23 May 2002 12:44:44 -0700

> sorry, but who exactly are "Prereg" and "Postreg", I could only find
HI, HACK and HTT.

Sorry. Prereg means the mobile and old access router exchange a
PrxyRtSol/PrxyRtAdv or the network sends a PrxyRtAdv and the mobile
sends a F-BU when it has completed CoA change. PostReg == BETH, i.e. the
HI, HACK, HTT and means just use a tunnel in response to a trigger on
the old or new access router.

> okay, but this applies I guess to wired infrastructures rather than
wireless ones.

Rightl, that was my point. 802.11 is not a secure link layer.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 23 May 2002 12:51:40 -0700

John,

> True, but in case of tunnel-based handover the layer 3 messages are
exchanged only between ARs. It can be assumed they
> are secure (they can be made secure), but the L2 triggers themselves
may not. Could layer 3 rely on layer 2 security
> (when deciding a handover) ? Encryption in WaveLAN - which proved to
be quite easy breakable - is the first example
> coming into my mind.

802.11 link level security is not strong enough to provide secure tunnel
based handover. The cellular protocols do have strong enough security.

BTW, note that in the FMIPv6 draft, the mobile initiated method also
requires a tunnel. The tunnel is set up when the F-BU is sent by the
mobile node (there are possible optimizations). So this is not just an
issue with "tunnel based" handover.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 23 May 2002 15:08:22 -0700

Any signal that cause a change in routing needs to
be secured. In the case BETH, these are all L2
signals between the MN and the network, in
the rest of FMIP6, it's a blend of L3 and some
L2... And all of these needs to be authenticated..

alper

----- Original Message -----
From: "Charles E. Perkins" <[email-masked]>
To: "John Williams Floroiu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 23, 2002 10:17 AM
Subject: Re: [mobile-ip] are L2 triggers "secure" ?

> >
> > I am not a L2 technology expert, therefore I am not sure how L2 triggers
are actually implemented. However, taking as an
> > occurring.
> >
> > An attacker spoofing the MAC address of a legitimate MN may force itself
to attach to a different access point (nAP)
> > trigger nAR is going to receive, and the effect is that the incoming MN
traffic is going to be mis-routed, since the
> > messages, like WaveLAN beacons --- of a legitimate mobile terminal, can
produce fake L2 triggers by attaching to false

---

From: John Williams Floroiu <[email-masked]>
Date: Fri, 24 May 2002 10:31:58 +0200

James,

> issue with "tunnel based" handover.

True, but the difference however is that F-BU and F-BACK are "layer 3 secured". The anticipated handover method sets up
the tunnel after exchanging F-BU and F-BACK --- which can be trusted by layer 3 --- with MN.

With tunnel-based handover, the handover is initiated by L2 triggers, and the problem I see is whether layer 3 could
trust layer 2 security (and for some technologies it obviously cannot). HI, HACK and HTT are "layer 3 secured" but they
are exchanged between the ARs, which is not relevant in this context because they make no guarantee about the MN's
legitimacy. 

L2 triggers are obviously a very efficient method to initiate handovers, but imho they need to always be accompanied by
secure layer 3 exchange which necessarily involve the MN. If this would be the case, then tunnel-based handover would
resemble very much the anticipated handover from the perspective of the control message exchange. 

John.

---

From: "James Kempf" <[email-masked]>
Date: Sun, 26 May 2002 21:58:13 -0700

> True, but the difference however is that F-BU and F-BACK are "layer 3
secured". The anticipated handover method sets up
> the tunnel after exchanging F-BU and F-BACK --- which can be trusted
by layer 3 --- with MN.

Are they? I don't believe there was anything in
draft-ietf-mobileip-fast-ipv6-XX.txt the last time I looked that
mentioned how they would be secured.

There was some discussion on the list a while back in the middle of the
IPv6 security debate about how to secure F-BU and F-BACK. Should return
routability be used as with forwarding from previous care of address? Or
something else?

Additionally, the PrxyRtSol and PrxyRtAdv contain Layer 2 addresses for
the next access point or router. If the network can spoof these, then it
is possible to cause a handover to something that is not a legitimate
router. In 802.11, it is relatively easy to spoof the link layer. The
MAC address can be spoofed, as I mentioned previously, or, even easier,
someone could set up a bogus access point.

> With tunnel-based handover, the handover is initiated by L2 triggers,
and the problem I see is whether layer 3 could
> trust layer 2 security (and for some technologies it obviously
cannot). HI, HACK and HTT are "layer 3 secured" but they
> are exchanged between the ARs, which is not relevant in this context
because they make no guarantee about the MN's
> legitimacy.

The handover is initiated with L2 triggers in anticpated handover as
well. Something needs to give the mobile node an identifier for the next
access router. Unless the mobile node can talk to two access points at
once, so it can perform router solicitation on the new one while the old
one is still delivering traffic, the information on the new access point
must come from layer 2.

> L2 triggers are obviously a very efficient method to initiate
handovers, but imho they need to always be accompanied by
> secure layer 3 exchange which necessarily involve the MN. If this
would be the case, then tunnel-based handover would
> resemble very much the anticipated handover from the perspective of
the control message exchange.

If the layer 2 is secure, there is no need to involve the MN at the time
the wireless signal is fading around handover (it may be involved before
or after). As I've stated numerous times on this list, traffic with the
MN around a handover is subject to the unavoidable probability that it
will be cut off prior to completing, resulting in the need for the MN to
recover with standard MIP on the new access point, making the expected
performance of anticipated handover less reliable relative to
tunnel-based handover. For those wireless link layers that provide the
right kind of security, like the cellular protocols, there is no reason
to penalize them by requiring anticipated handover. And security on the
local link is exactly what layer 2 security should be all about.

            jak

---

From: John Williams Floroiu <[email-masked]>
Date: Mon, 27 May 2002 10:47:57 +0200

James,

> secured". [...]

> mentioned how they would be secured.

Well, okay it is not mentioned HOW, but I remember I saw a statement saying that they should be.

>> [...]

I agree, PrRtAdv and RtSolPr contain layer 2 information or originate themselves from layer 2 triggers. However if
PrRtAdv and RtSolPr (as well as HI-HACK) were authenticated at layer 3, it wouldn't be possible to force a MN perform a
bogus handover. 

In 802.11, a MN may be fooled by bogus beacons to attempt a number of handovers to nowhere or to attackers themselves,
but these handovers won't succeed since the targets won't be able to authenticate the layer 3 control message exchange.
This raises however another interesting question: how would a 802.11 adapter perform under a flood of bogus beacons ?
Even if encryption is used, an attacker can still achieve quite easily a computational DoS.
 
>> [...]

Okay, but for cellular protocols in particular we don't have to bother too much about Mobile IP fast handover, have we ?

Regards,
John.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 27 May 2002 20:37:12 -0700

> I agree, PrRtAdv and RtSolPr contain layer 2 information or originate
themselves from layer 2 triggers. However if
> PrRtAdv and RtSolPr (as well as HI-HACK) were authenticated at layer
3, it wouldn't be possible to force a MN perform a
> bogus handover.

OK, I think I understand your point. In the anticipated case, failure of
the HI/HACK is reported via the PrRtAdv (presuming it is delayed until
the HACK returns, the draft specifies that it may be sent prior to the
return if stateless addrconfig is used instead of stateful, this
probably ought to change). The mobile then aborts the handover,
presuming the layer 2 protocol allows it.

> In 802.11, a MN may be fooled by bogus beacons to attempt a number of
handovers to nowhere or to attackers themselves,
> but these handovers won't succeed since the targets won't be able to
authenticate the layer 3 control message exchange.
> This raises however another interesting question: how would a 802.11
adapter perform under a flood of bogus beacons ?
> Even if encryption is used, an attacker can still achieve quite easily
a computational DoS.

Good question. I believe the protocol requires the mobile host to
maintain a list of BSSids. A flood of bogus beacons might be used to
perform a state attack, in which the host's BSSid state list is
essentially filled.  I don't know the protocol well enough to say
whether it contains anything to prevent this from happening.

> Okay, but for cellular protocols in particular we don't have to bother
too much about Mobile IP fast handover, have we ?

We do if you are concerned, as I am, about removing the deep radio
access networks in the current generation of cellular protocols. There
are several new radio protocols that would lend themselves to putting
Mobile IP directly on top of the radio in cellular systems, and Motorola
has done it for low latency MIPv4 on a representative of the current
generation, with an experimental implementation on the IS-2000 (3GPP2)
cellular protocol. The fast handover designs are supposed to work for
existing protocols and new ones.

                jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 28 May 2002 00:34:11 -0400

Hi,

Using the CAR discovery protocol, the mobile host can check the IP address
(or identifier) of the access router associated to the base station or any
device sending the bogus beacons. Furthermore the CAR discovery will be able
to tell the mobile host whether the access router, if any, is authenticated
and authorized to participate in the CAR discovery process, which is a good
guidance about whether to take the BSSid seriously or ignore it. If the CAR
discovery protocol cannot find the associated access router for the BSSid,
the mobile host may take a cautious step in keeping trying to hand over
following the beacon.
The CAR discovery protocol is a complimentary protocol for the low-latency
handoff protocol and may provide a  reasonable solution for the security
concern pointed in the discussion below.

Thanks.

Eunsoo

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 29 May 2002 16:44:46 -0700

Hello folks,

I was away last week, and I am still catching up with e-mails.
In general, I would like to keep the L2-specific issues including
L2 trigger authentication away from a baseline FMIPv6 protocol.
The protocol has to work on all link layers, and hence it must
not be based on _specific L2 customizations_ or features.
This is not to say that L2 features should not be exploited, however, a
baseline
FMIPv6 protocol should consider IP authentication and performance
issues. Link-specific optimizations/customizations should be treated
separately.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 29 May 2002 20:59:51 -0700

Rajeev,

> issues. Link-specific optimizations/customizations should be treated

Does this mean you do not want to mention anything about L2 security in
the base draft? If so, I think it may be necessary to then refer to the
L2 triggers draft or have a separate draft, as I believe the security
directorate will require some statement about security of L2 triggers. I
believe this is so regardless of which algorithm is considered.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 30 May 2002 09:47:15 -0700

> believe this is so regardless of which algorithm is considered.

Actually, I would like to keep the focus on IP protocol messages, while
keeping room for using L2 triggers. I don't see any problem in
(informatively) referencing L2 triggers draft.

Regards,

-Rajeev