Subject: [mobile-ip] FMIPv6: Sending FBU from the new link

From: Rajeev Koodli <[email-masked]>
Date: Mon, 10 Mar 2003 16:24:23 -0800

Hello folks,

I would like to follow up on the following e-mail.
Specifically, I think it would be better to have FBU
terminate at the new AR, and let the new AR send HI
with the binding authorization from the MN (item 2)
below). Perhaps encapsulate FBU in HI..
That way, the FBU won't have to be forwarded 
with topologically inconsistent source IP address, 
potentially across multiple hops.

Regards,

-Rajeev

-------- Original Message --------
Subject: Re: [mobile-ip] Security Problems with FBU (was: Re:
[mipcharter] Proposed Charter for IPv6 Mobility)
Date: Wed, 05 Mar 2003 17:52:46 -0800
From: Rajeev Koodli <[email-masked]>
Organization: Nokia Research Center
To: James Kempf <[email-masked]>
CC: Mohamed Khalil <[email-masked]>,
[email-masked]
References:
<[email-masked]>
<025001c2e365$4b2eb730$156015ac@T23KEMPF>

I see two possible ways to handle this.

1) rate limit the FBUs sent from new link
2) allow NAR to send HI, as Jim has suggested, but include the
     binding authorization from the MN in HI.

-Rajeev

James Kempf wrote:

> If the MN sends the FBU message on the new AR, then the HI message arrives at
> the new AR after the FBU is routed to the previous AR by the new AR.
>
> Chicken and egg problem.
>
>             jak
>
> ----- Original Message -----
> From: "Mohamed Khalil" <[email-masked]>
> To: "'James Kempf'" <[email-masked]>
> Cc: <[email-masked]>; "Rajeev Koodli" <[email-masked]>
> Sent: Wednesday, March 05, 2003 1:57 PM
> Subject: RE: [mobile-ip] Security Problems with FBU (was: Re: [mipcharter]
> Proposed Charter for IPv6 Mobility)
>
> > The oAR is sending an HI message with the pCOA to the nAR. I am assuming
> > that the HI will be sent securely to the nAR through some type of security
> > protocol such as IPSec (the definition of this protocol is suppose to be
> > outside the scope of this draft). This implies that the owner of this pCOA
> > has been granted access to the old subnetwork and is not an attacker. When
> > the nAR receives HI message it is suppose to verify this message and part of
> > the functionality is to add an entry for the MN's pCOA to the ingress filter
> > table. I agree that there are some more work to be done in the area of
> > securing FBU and HI/HACK which should be addressed by other future drafts as
> > Rajeev indicated before.
> >
> >

[snip]

---

From: Alper Yegin <[email-masked]>
Date: Mon, 10 Mar 2003 18:58:59 -0800

Hi Rajeev,

I don''t think this is a good idea. This complicates the protocol
unnessarily. Allowing F-BU be sent from new link with oldCoA
as the source is a further enhancement or failure recovery to
the base FMIP protocol. I think it is reasonable to expect the access
network to optionally allow some limited packets  be sent with topologically
incorrect source address for this "bonus point". These packets
are such that they must be F-BU sent by an already authenticated MN,
source address must be from a prefix in the access network, destination
address can only be another AR in this network. And if the AR cares, it can
log them in case this mechanism is ever abused. This is not like opening an
access network's ingress filtering, or completely disabling ingress
filtering on the Internet.

So, imho, we shouldn't have to complicate the protocol by doing either
of what you suggested below.

alper

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 11 Mar 2003 09:38:18 -0800

Alper, Mohamed,

I agree that it is possible to selectively allow rate-limited
FBUs. What about routers beyond the new router ?
Wouldn't we end up making additional assumptions about
them ?
Could you also describe what is the additional overhead
introduced by terminating FBU at new AR and perhaps
encapsulating it in a HI ?

-Rajeev

---

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

> potentially across multiple hops.

I agree. I believe that the message should go to the current AR, regardless of
whether that is the pAR or nAR. This eliminates the requirement that the MN must
have a global IP address for the AR, and simplifies the security association.
The MN can use the All Routers Multicast address on the current link when it
wants to start the tunnel, for example, so that the message can be sent to all
ARs on the link, and it can use the SEND security association.  It thus
eliminates the distinction between if the MN is on the old or new AR, a major
complication with the FBU approach.

With respect to the comments that were sent, I don't agree that this complicates
the protocol, in fact, I think it simplifies it. It eliminates the need for:
   a) A global unicast address for routers.
   b) Any distinction to be made for whether the MN is on an old router or new.
This makes it much simpler.
   c) The need for FNA/NAAK, making new address configuration be
       the same for both the FMIP and regular MIP case, simplifying
implemention.
      Once the MN is on the new link, it can perform oDAD to check the new
       address, exactly as in the regular MIP case. How it determines when it is
       on the new link and how long is immaterial, it could be an L2 trigger or
a
       solicited or unsolicited RA, since the MN is getting its packets through
       the tunnel.

In addition, proponents of sending an FBU to pAR have yet to specify:
   a) how MN gets a global IPv6 address when RFC 2461 states that a link local
       address is all that is ever seen on the RA. This is actually trivial to
solve, an
       RA option with the global address, but it hasn't been proposed.
  b) how the security association is established between pAR and MN. If the
routing change
       message goes to the current AR, regardless, the SEND security association
       can be used on the packet. If the FBU approach is used, then we have to
figure
       out some way to set up the security association, equivalent to that
between
       the MN and HA. There is still a debate to be had whether the MN
       must include some kind of "authorization" that it sends to the AR for
changing the
       routing, independent of any authorization derived from the signaling, but
that
      is a separate issue and we can talk about it on a different thread once we
have
      agreement on where the signaling should go.
  c) how to prevent a cycle DoS attack from any node on the Internet against
pAR. In SEND
      and RFC 2461, packets are restricted to on link nodes by setting the TTL
to 255. This
      allows the router to perform a quick, noncryptographic check if the packet
came from
      on link, then use heavyweight cryptography only after. With FBU, the
packet is sent to
      a global IP address on the router, potentially from another subnet, so
this check could
      not be used.
  d) How the ingress filter on the new AR is configured if the new AR has not
yet seen
       the address. M. Khalil's assertions to the contrary, I posted a response
to
       his previous email suggesting that it still remains a chicken and egg
problem. Short of
      some kind of out of band messaging to the new AR prior to sending the
      FBU (like, for example, an AAA exchange at L2), I don't see how the
      the FBU could be sent without compromising security on the new AR. Any
such
      out of band signaling is liable to slow down starting the tunnel, and
complicate it
      because the MN must distinguish between the old AR and new.

Furthermore, I believe the signaling should not be a BU but should be derivative
from the
RFC 2461 signaling, something like a Type 2 Redirect message. As described in
the
architecture draft, this allows the global and local signaling to be modularized
so a
change in one doesn't affect the other. In addition, SEND is defined
specifically
for ICMP extensions such as Redirect, and so could not be used with BU without
modification.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 11 Mar 2003 10:33:33 -0800

> have a global IP address for the AR, and simplifies the security association.

I am not implying that the global address is not to be used. The MN still needs
to supply the PAR's global IP address.

> wants to start the tunnel, for example, so that the message can be sent to all

This is also not implied in my e-mail. Please note that FBU is still sent
to an AR, and not to a group address.
Sending FBU to a multicast address is a separate topic. Let's try to specify
unicast first.

> ARs on the link, and it can use the SEND security association.  It thus

A separate topic.

> complication with the FBU approach.

I don't think so. It sends a packet to its current AR.

>    a) A global unicast address for routers.

I think this is not an issue we are trying to solve. As mentioned, the MN
still needs to supply the PAR's IP address.

> This makes it much simpler.

The MN sends FBU to its current router. If it's on old link, it goes to
PAR, if it is on new link, it goes to NAR.

>        solicited or unsolicited RA, since the MN is getting its packets through

I need to parse this again :-) The purpose of FNA, as repeated before, is to
announce presence to the new AR, and confirm new CoA in case FBAck has not been
received.

I would like to emphasize an important point here. When we propose
a change, it is not meant to overhaul a design resulting from many
months of discusssion and effort. It is virtually impossible to make
forward progress that way. I request all interested folks to please keep
this mind when you contribute. We ought to recognize that the current version
is a reflection of what WG folks (roughly) think, and build  on top of that.

Regards,

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 11 Mar 2003 10:35:12 -0800

>        RA option with the global address, but it hasn't been proposed.

the modified Prefix information format from Mobile IPv6?

Vijay

---

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

> is a reflection of what WG folks (roughly) think, and build  on top of that.

Sorry, I disagree with this.

The current design is kind of like an archeological site. One can see the layers
of old decisions: design team, previous editors, etc. I think we need to rethink
the approach based on new information (for example, Pete's draft on 802.11,
Pekka's and my draft on architecture, etc.) which unifies the design around a
few common agreed upon principles.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 11:47:56 -0800

> the modified Prefix information format from Mobile IPv6?

Sure, that would work. But it would have to be rewritten for ND and put into the
FMIP draft. It currently isn't.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 11 Mar 2003 12:02:18 -0800

James Kempf wrote:
> FMIP draft. 

why?

you just have to reference section section 7.2 of the MIPv6
specification.

Vijay

---

From: Alper Yegin <[email-masked]>
Date: Tue, 11 Mar 2003 12:22:50 -0800

Hi Rajeev,

> FBUs. What about routers beyond the new router ?

This ingress filtering rule is only of concern to ARs.
The ingress fiiltering on the border gateways (to Internet) of this access
network should not have to change, because they won't even see these
packets.
Any other intermediate routers should not have to care about ingress
filtering anyways. 

> Wouldn't we end up making additional assumptions about

I guess we do. See above and let us know if they are reasonable.

> encapsulating it in a HI ?

Unless we really have to, I'd rather not have these changes, because it
deviates from the simple Mobile IP model of using MN and HA, and
piggybacking/tunneling two protocol signaling is not a clean approach.
As MK pointed out, if you are going to piggyback the FBU and smuggle it to
oldAR, you are already punching a hole in the ingress filtering.

alper

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 12:20:01 -0800

OK.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 11 Mar 2003 12:32:47 -0800

Jim,

> few common agreed upon principles.

you didn't explain how the new information didn't add (and hence
make it bigger) to the "archeological site"
And, one might contend that "new information" itself is some such
site :-)

The point is we will not make progress if we keep re-visiting (some might
say re-hashing) the issues that have been discussed at length. One may not
agree with the rest of the folks, but needs to respect the opinion of the
majority of the folks (which is what should be in the draft). Otherwise,
I see no way other than recursing over (and over).

You mentioned common agreed principles. One such thing relevant for
this group is the premise of IP mobility as we know it from Mobile IP:
a MN securely binds an address for another in order to control the flow
of its packets. We have an outstanding issue on how a MN establishes an
SA with its router. Let's solve that and we should be pretty darn close to
finishing this protocol.
If folks want to work on alternative IP mobility models (wrt to Mobile IP),
that needs investigation, perhaps elsewhere!

-Rajeev

---

From: Alper Yegin <[email-masked]>
Date: Tue, 11 Mar 2003 12:50:23 -0800

>      RA option with the global address, but it hasn't been proposed.

No problems here. FMIP spec just mandates use of a modified prefix
information which is defined in the base Mobile IPv6 spec.

> b) how the security association is established between pAR and MN.

The SA established between the MN and its currentAR can be used once MN
moves off-link. Now it is "SA between MN and oldAR".

>     a global IP address on the router, potentially from another subnet, so

Just disallow incoming FBUs on the access network's firewall, so no threat
from the global Internet.
From the inside, the DoS can only come from "authorized MNs that are
connected to an AR". If they are potential threat, they might very well
threaten their currentAR.

>      the address.

I have already responded to that earlier (recently, again).

> M. Khalil's assertions to the contrary, I posted a response
> to

alper