Subject: [mobile-ip] on FMIPv6 signaling

From: John Williams Floroiu <[email-masked]>
Date: Fri, 08 Nov 2002 14:51:05 +0100

Hi,

     There is one comment I would like to make relevant to the mipv6
     fast handover draft (draft-ietf-mobileip-fast-mipv6-05.txt).

     I would start by reproducing the signaling which takes place in the "no
     anticipation" case:

               M N                   NAR                  PAR
               ---                   ---                  ---
                |                     |                    |
           attach via                 |                    |
               NAR                    |                    |
                |                     |                    |
                |-------------- F-BU -+------------------->|
                |                     |<------ HI ---------|
                |                     |------ HACK ------->|
                |                     |                inter-AR
                |                     |                 tunnel
                |                     |                 estab.
                |<--------------------+- F-BACK -----------|
                |                     |                    |

     The signaling for "anticipation" case looks to me a little bit
     cumbersome and I would like to propose a slight variation aimed at
     achieving an uniform signaling of the two cases.

     I am basically proposing RtSolPr to be piggybacked (contained) into F-BU
     and PrRtAdv into F-BACK.

     A F-BU containing RtSolPr indicates PAR that the MN anticipates the
     layer 2 handover and consequently PAR will send F-BACK both over the
     radio link and through NAR.

     If the MN receives the F-BACK directly from PAR and the contained PrRtAdv
     indicates that the prospective access point operates under a different AR
     then MN will immediately initiate a layer 2 handover, since the inter-AR
     tunneling is already in place, and the data traffic is already diverted
     towards NAR. In all other cases initiating a layer 2 handover is not
     necessary because it either took place already or it does not involve a
     layer 3 handover.

     The figure below depicts the situation when the MN moves to a different AR.

          M N           NAR           PAR                    M N
          ---           ---           ---                    ---
           |             |             |                      |
           |             |             |<-- F-BU | RtSolPr ---|
           |             |<---- HI ----|                      |
           |             |---- HACK -->|                      |
           |             |         inter-AR                   |
           |             |          tunnel                    |
           |             |          estab.                    |
           |<---- F-BACK | PrRtAdv ----|- F-BACK | PrRtAsdv ->triggers
           |             |             |                      L2
           |             |             |                      handover
           |             |             |                      |

     Regards,
     John.

---

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

What's the MAC address and source address on the BU packet? How does the MN get
the router's address to put in as the altCoA which I assume is what you are
proposing to put in the BU. Must the MN do RR with the router before using the
altCoA, as the base MIPv6 spec says?

I think this would be a lot easier if the tunnel establisment in the no
anticipation case were piggybacked on the RS/RA that starts getting the MN up on
the current link.

            jak

---

From: John Williams Floroiu <[email-masked]>
Date: Sun, 10 Nov 2002 20:21:54 +0100

James,

> What's the MAC address and source address on the BU packet? 

The IP source address is PCoA. The MAC address depends on the path F-BU will actually follow (over the previous radio 
link or over the new radio link).

> How does the MN get
> proposing to put in the BU. 

In case of "anticipation" PAR must be able to infer NAR's IP address based on the prospective access point's identifier. 
In case of "no anticipation" NAR could for instance piggyback its own IP address into the F-BU. Then PAR can include 
NAR's IP address into the F-BACK.

 > Must the MN do RR with the router before using the

I am not sure about RR in this context, I do not see the benefit.

> anticipation case were piggybacked on the RS/RA that starts getting the MN up on

1st argument against:
I am afraid that wouldn't be safe. I believe tunnel negotiation must take place between PAR and NAR during the HI/HACK 
exchange because in a real life deployment PAR and NAR would typically share a security relationship. Otherwise bogus 
RSs may trigger nasty redirections (DoS).

2nd argument against:
I believe the signaling for the "anticipation" and "no anticipation" schemes must be identical (except for a few 
parameters) because due to the undeterministic radio conditions an "anticipated" handover may be initiated over the 
previous radio link and completed over the new radio link, or may be carried out completely over the new radio link if 
the quality of the previous one decreases abruptly.

John.

---

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

> link or over the new radio link).

See my previous comments on ingress filtering w.r.t. the PCoA.

Also, if the F-BU follows the new radio link, it must use the MAC address of the
router, right? If there is no prehandover signaling, where is it going to get
that?

> In case of "anticipation" PAR must be able to infer NAR's IP address based on
the prospective access point's identifier.

I'm not talking about anticipation, it's clear what happens in that case.

> In case of "no anticipation" NAR could for instance piggyback its own IP
address into the F-BU. Then PAR can include
> NAR's IP address into the F-BACK.

So you are proposing that the new AR snoop traffic coming from the MN and modify
the packets? That sounds like a bad idea to me. It is a pretty basic violation
of end to end.

> I am not sure about RR in this context, I do not see the benefit.

The base spec says it MUST do RR in order to use the altCoA.

> 1st argument against:
> I am afraid that wouldn't be safe. I believe tunnel negotiation must take
place between PAR and NAR during the HI/HACK
> RSs may trigger nasty redirections (DoS).

Are you saying that the MN would be allowed on the new access point without
having any security set up? I doubt it. The MN must be able to trust the AP and
vice versa. 802.11 provides this via 802.1x, for example.

> parameters) because due to the undeterministic radio conditions an
"anticipated" handover may be initiated over the
> previous radio link and completed over the new radio link, or may be carried
out completely over the new radio link if
> the quality of the previous one decreases abruptly.

I agree. As discussed in draft-kempf-mobileip-fmipv6-sem-00.txt, the signaling
can be identical if the F-BU and F-NA are dropped.

            jak

---

From: John Williams Floroiu <[email-masked]>
Date: Tue, 12 Nov 2002 13:14:59 +0100

James,

>>The IP source address is PCoA. The MAC address depends on the path F-BU will
> 
> actually follow (over the previous radio
> 

I learned about your opinion on this matter, but I believe enabling a pinhole for datagrams originated at PCoA and 
addressed to PAR produces no security breach. There is no problem for PAR to discard them if necessary, especially if 
such datagrams are authenticated (and I think this is going to become the rule rather than the exception).

On the other hand, for an attacker there is no problem to guess a "good" IP address on the new link and pass through the 
ingress filtering, if it really wants to. So, ultimately from whom is ingress filtering protecting us, in this case ?

> router, right? If there is no prehandover signaling, where is it going to get

Right, a RS/RA is necessary in this case. Or maybe an "any AR" MAC address could be used ??? Although this will conflict 
with MAC addresses-based filters deployed in some APs.

I actually had the wrong impression that the destination MAC address is the AP's MAC address.

Anyway, this basically means that the IP stack should send a RS each time a layer 2 handover notification is received 
(and should do that regardless of whether fast handover is being implemented or not). It is the notification from the 
WLAN card which is currently missing, as far as I know polling is used for the purpose of detecting layer 2 handovers.

> the packets? That sounds like a bad idea to me. It is a pretty basic violation

Basically yes, snooping the signaling of "lost" MNs. But this is somehow equivalent to "record route", or not ?

However since a RS/RA exchange over the new radio link is necessary, this provides also MN with the mean for learning 
NAR's IP address.

> The base spec says it MUST do RR in order to use the altCoA.

I know, but I am not sure why is altCoA set to NAR's IP address and requires RR. Performing RR for NCoA, that's obvious, 
but until NCoA is acquired, the traffic heads PCoA and is diverted by PAR.

Besides that, I was thinking that also nomadic nodes could benefit from fast handover, not only mobile nodes, that's why 
in my view fast handover must not be an exclusive feature of Mobile IP (and consequently not rely on Mobile IP specific 
mechanisms). A nomadic node moving from one AR to another would for instance need no more than completing a ftp transfer 
initiated while connected to PAR. For all future data traffic it will use an local (NAR allocated) IP address. I am not 
sure however whether this is a realistic "business case".

>>exchange because in a real life deployment PAR and NAR would typically share a
> 
> security relationship. Otherwise bogus
> 

There are different levels of trust to be considered here and I believe you are not saying that a MN must be considered 
by NAR as being authentic if the new AP has authenticated it (via 802.1x, for instance).

MN has a security relationship with PAR. And NAR and PAR trust each other, therefore PAR could mediate the setup of a 
trust relationship between MN and NAR as well. Datagrams injected by bogus "lost" MNs will pass at first through NAR, 
okay, but they won't make it beyond PAR.

As for 802.1x, if I got it right, the nodes are identified by MAC address alone, which for authentication is as good as 
WEP for encryption, or even worse. Besides that, 802.1x typically uses a Radius server, so if a MN has been 
authenticated by the prev. AP then its MAC address is already recorded somehow, and the new AP is going to authenticate 
it as well, assuming both APs (and ARs) are located in the same administrative domain and therefore serviced by the same 
Radius server. As for inter-domain handovers, these won't be probably "fast" (specifically because of all required 
security setups).

John.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 05:34:22 -0800

> such datagrams are authenticated (and I think this is going to become the rule
rather than the exception).

I may not have been clear.

My comments were that unless the new AR learns that the PCoA is valid from an
entity that it can trust, like the old AR, there is no reason for it to modify
the ingress filter in this way. Why should it? The address may be used by an
attacker. As a result, unless there is prehandover notification, using HI/HAck,
to set up the tunnel, the new AR should not trust the PCoA.

This is a problem for link protocols like 802.11 where there is no prehandover
signaling. If the MN uses the PCoA on the F-BU in 802.11, there is no reason for
the new AR to let the F-BU pass, because it doesn't know that it can trust the
PCoA.

> On the other hand, for an attacker there is no problem to guess a "good" IP
address on the new link and pass through the
> ingress filtering, if it really wants to. So, ultimately from whom is ingress
filtering protecting us, in this case ?

Separate issue. The network provider can use DHCP to control what addresses are
"good", and use an L2 to IP address mapping to determine who has what address.
The attacker can spoof a known L2 address, of course, but if on the air L2
encryption is used, it can't find out the L2 to IP address mapping.

> Right, a RS/RA is necessary in this case. Or maybe an "any AR" MAC address
could be used ??? Although this will conflict
> with MAC addresses-based filters deployed in some APs.

So why not leverage the RS/RA to start the tunnel immediately and not send the
BU? Result is less packet loss.

> Anyway, this basically means that the IP stack should send a RS each time a
layer 2 handover notification is received
> WLAN card which is currently missing, as far as I know polling is used for the
purpose of detecting layer 2 handovers.

Having a link up L2 trigger on the MN would be good. We've implemented this for
802.11.

> There are different levels of trust to be considered here and I believe you
are not saying that a MN must be considered
> MN has a security relationship with PAR. And NAR and PAR trust each other,
therefore PAR could mediate the setup of a
> trust relationship between MN and NAR as well. Datagrams injected by bogus
"lost" MNs will pass at first through NAR,
> As for 802.1x, if I got it right, the nodes are identified by MAC address
alone, which for authentication is as good as
> authenticated by the prev. AP then its MAC address is already recorded
somehow, and the new AP is going to authenticate
> it as well, assuming both APs (and ARs) are located in the same administrative
domain and therefore serviced by the same
> Radius server. As for inter-domain handovers, these won't be probably "fast"
(specifically because of all required

Right. So it adds up to this:

    - The MN must do authentication to get on the new AP anyway, so doing the
signaling with the old AR provides no security advantage.
    - The MN must send RS/RA anyway before it sends F-BU so that it has the L2
address of the new AR, so why not get rid of the F-BU and have the MN send its
PCoA and address of the old AR along with the RS, thereby saving a message and
speeding up tunnel establishment?

The result is architecturally cleaner, because it maintains a nice distinction
between a node to routing identifier change and a change in routing due to a
link switch without any routing identifier change, and it results in a shorter
outage period because the tunnel is established right away after RS, rather than
after RS/RA/F-BU.

            jak

---

From: John Williams Floroiu <[email-masked]>
Date: Tue, 12 Nov 2002 19:23:57 +0100

> signaling with the old AR provides no security advantage.

still, oAR is able to authenticate the MN and, based on that, setup a forwarding tunnel.

 > speeding up tunnel establishment?

so, if I got it right:
1) RS * you send PCoA and PAR along with RS, to NAR;
2) HI * NAR informs PAR that a MN presently using PCoA as CoA is now on a radio link services by itself, and also sets 
up a tunnel --- but NAR has no proof yet that MN is authentic;
3) HACK * if MN is authentic (but then you have to send MN's home address along with RS as well) PAR sets up the other 
end of the tunnel, starts forwarding and answers back; if MN is not authentic, PAR indicates an error code and NAR tears 
down the tunnel set up at point 2.

But what happens if an attacker who knows the location of a MN goes to another AR and sends a RS containing the victim's 
  PAR, PCoA, home address. Isn't this an easy mountable DoS ?

John.

---

From: John Williams Floroiu <[email-masked]>
Date: Tue, 12 Nov 2002 19:23:57 +0100

so, if I got it right:

John.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Nov 2002 00:34:56 -0800

> 2) HI * NAR informs PAR that a MN presently using PCoA as CoA is now on a
radio link services by itself, and also sets
> up a tunnel --- but NAR has no proof yet that MN is authentic;

If the AP hasn't already done this (i.e. as in 802.11) then the router checks
with the Diameter server. Besides, if PAR doesn't recognize the PCoA, it can
reject the HAck.

> 3) HACK * if MN is authentic (but then you have to send MN's home address
along with RS as well) PAR sets up the other
> end of the tunnel, starts forwarding and answers back; if MN is not authentic,
PAR indicates an error code and NAR tears
> down the tunnel set up at point 2.

Why does NAR need to know the home address?

> But what happens if an attacker who knows the location of a MN goes to another
AR and sends a RS containing the victim's
>   PAR, PCoA, home address. Isn't this an easy mountable DoS ?

So, like I said, the AP shouldn't let the MN on unless it is authenticated.
802.11 does this via 802.1x, in a very cumbersome way.  The MN needs to have
security set up with the router for the router to forward. We're looking at this
in SEND at the moment.

            jak

---

From: John Williams Floroiu <[email-masked]>
Date: Wed, 13 Nov 2002 11:30:44 +0100

> If the AP hasn't already done this (i.e. as in 802.11) 

I wouldn't trust an AP...

> then the router checks
> with the Diameter server. 

Okay, so you need a Diameter server too.

> Besides, if PAR doesn't recognize the PCoA, it can
> reject the HAck.
> 

I was thinking that the MN is authenticated by PAR and therefore PAR needs to identify the proper SA and therefore use 
the MN's home address for this purpose (as PCoA might for instance be reused, especially if stateful address allocation 
is performed).

> 802.11 does this via 802.1x, in a very cumbersome way.  

In 802.1x, if you use the victim's MAC, you are authorized to access the network behind the AP and this is really no big 
deal to mount (or maybe I am not well informed about 802.1x).

> The MN needs to have

My opinion was that PAR could support this (without the need to invoke Diameter servers or the like) since it currently 
shares a SA with MN, but I agree there are other alternatives as well.

John.