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

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 12 Mar 2003 09:13:08 -0600

Hi Alper,
-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2003 2:32 PM
To: Khalil, Mohamed [RICH2:2N51:EXCH]; 'Rajeev Koodli'
Cc: [email-masked]
Subject: Re: [mobile-ip] FMIPv6: Sending FBU from the new link

Hi MK,

However we are thinking that we can build an SA between MN and currentAR,
why
couldn't it help to build one between MN and oldAR when MN was there? It is
not
hard to think that we can use it 9at least for a while) after MN leaves the
link.

The state change is on the oldAR. Somehow oldAR needs to authorizes MN's
request to
change forwarding state. This is why I think they should be talking
directly.
Without getting some state from oldAR for this particular MN, currentAR
cannot
authorize, or suggest a change on the oldAR. oldAR needs to get some
credentials
specific to MN before it can authorize the change. This is best done when
they directly communicate. It is doable if we have to break the end2end
comm. into two: MN to currentAR, currentAR to oldAR, but not desirable.

alper

 MK>> I agree that letting the MN talks directly to the oAR is the approach
which maps better to the the current MIPv6 specification. However, the
approach of breaking down the end2end comm into two, which I presonally
don't like, migth simplify the security model. I gree that  we should not go
through this route unless we prove without any doubt that the direct
approach, which match better the MIPv6 spec, is infeasible.  

-Mohamed

On 3/11/03 11:39 AM, "Mohamed Khalil" <[email-masked]> wrote:

Hi Rajeev, 

After thinking more about the new approach for sending FBU, I think this
approach might simplify the security model by eliminating the need to have a
SA between the MN and pAR. The new proposal will require to use a SA defined
by a protocol such as SEND to secure the FBU to the current AR. Then another
SA to secure the HI message encapsulating the FBU which is not difficult to
have if we assume that those ARs belongs to ISPs who have some sort of
service level agreement between each other.

-Mohamed 
-----Original Message----- 
From: Rajeev Koodli [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2003 11:38 AM 
To: Alper Yegin 
Cc: [email-masked] 
Subject: Re: [mobile-ip] FMIPv6: Sending FBU from the new link 

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 

Alper Yegin wrote: 

> 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 
> 
> > 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: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 09:30:31 -0800

Hi Alper,

If you think a better approach is for the MN to establish a separate security
association with the AR, then I would suggest you might want to propose the
ISAKMP and IKE signaling in order for that to be established, and the SAD and
SPD entries. See draft-ietf-mobileip-mipv6-ha-ipsec-03.txt for how that was done
with the HA, which is I presume what you would want to do with the AR. I'd also
suggest to keep in mind that the goal is to optimize handoff and it would be
worthwhile thinking closely about how interposing a 4 message aggressive mode
IKE key exchange (should you choose to use aggressive mode) with the AR as part
of that goal.

Finally, if you are thinking about using some alternate method of establishing
the security association, AAA, context transfer, etc., then having a specific
proposal with details as to the signaling, security on the signaling, etc. would
make it easier to compare with the current proposal, namely
draft-ietf-send-ipsec-00.txt.

            jak

----- Original Message -----
From: "Mohamed Khalil" <[email-masked]>
To: "'Alper Yegin'" <[email-masked]>; "'Rajeev Koodli'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 12, 2003 7:13 AM
Subject: RE: [mobile-ip] FMIPv6: Sending FBU from the new link

---

From: Alper Yegin <[email-masked]>
Date: Wed, 12 Mar 2003 12:19:52 -0800

Hi James,

Actually I don't have a detailed mechanism for building the desired SA
between the MN and currentAR in my mind. Using IKE is definitely costly, and
should be regarded as last resort (maybe not even that :).
My general point is, as soon as we figure out how to do that efficiently,
this not only gives us the SA between MN and the currentAR, but also an SA
between MN and the oldAR, becuase MN just came from the old-link. It must
have established that SA while it was there. Some details are important,
like SA should not expire when MN moves off-link, and it should not assume
MN's on-link id (such as link-local addresses).

alper

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Mar 2003 10:25:14 -0800 (PST)

> should be regarded as last resort (maybe not even that :).

Maybe we should have a reality check about
IKE-hatred because SA establishment is, IMNSHO,
one of the large issues looming for realtime
mobility. Let me throw out a couple of
observations:

1) TANSTAAFL: that is, you get what you pay for
   with key management. On the impoverished end of
   pre-shared keys, you get the fastest
   establishment at the cost of key management
   capabilities, etc. IKE has two main costs,
   round trip count and crypto cost. IKEv2 is
   better on the round trip count (it's either
   4/6 or 6 messages, I forget what they settled
   on), but gets you real key management. KINK is
   sort of inbetween with 2/4 messages (2 if you
   already have a service ticket).

2) Critical Path Considerations: for real time
   handoffs, the optimal number of messages is
   zero. Given that routers aren't prescient we
   know the total number of messages will be > 0.
   The real question is how many messages total
   can a mobile node/AR exchange and still fit in
   the window for real time service. Probably not
   many. Thus the question is whether *any* key
   exchange protocol is reasonably practical in
   the critical path (cf KINK). If the answer is
   no or marginal, then we probably need to look
   for alternatives such as spectulative SA
   building to candidate handoff targets. In this
   case, IKE's message count may not be
   prohibitive.

Part of the problem with stovepiped views of the
world is that each protocol which needs to play a
part in discovery, initial contact, access
control, QoS restoration, etc, has a tendency to
think of their set of messages in isolation. Put
all together, I have grave doubts that a real
system is going to be able to function well. 

Thus, I think it's probably a better mindset to
ask questions about whether message exchanges can
be done ahead of possible moves, and whether the
protocol under discussion is well equipped --
including security! -- to handle that. This is at
odds with traditional IETF modularity, but I think
we need to finesse this as much as possible.

Sorry for the polemic.

	  Mike