Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 28 Mar 2002 13:00:54 +0100

> > => Does it matter? I mean if the COTI is always 
  > > done on the intended CoA then wouldn't it always 
  > > work? So if a BU is sent with an Alt-CoA then 
  > > the COTI is done on the Alt-CoA. 
  > 
  > The question is really if alt-coa is still useful for
  > its intended purpose, which is something that the design team
  > doesn't understand.
  > 
  > So let me spell things out in detail to see if something jumps out.
  > Assume a MN has two CoAs: C1 and C2.
  > It wants to create the binding to C2 but (for whatever
  > reason) it wants to send the actual BU packet with C1 as a source.
  > 
  > It would then do HoTI/HoT as normal.
  > Send a CoTI with C2 as the source, and receive the CoT with C2 as
  > the destination.
  > Then it has the cookies necessary to send a BU for CoA=C2
  > and it can use any source address for that BU by including 
  > the alt-coa
  > option.
  > Thus the MN needs to be able to both send and receive packets
  > on the alt-coa address in order to get the right Care-of cookie.
  > 
  > As long as this is still useful things are fine.
  > But if folks where intending to use alt-coa for cases when 
  > the MN can't
  > (yet) send and/or receive on that address there is a 
  > problem to combine
  > this with RR.

=> Agreed. The screnario that you mention where 
there could be problems (forwarding to an address
that the MN is not in yet) is more relevant
to the Fast Handoffs draft, which is why I think
there needs to be some serious security work
for that draft. 

Hesham

  >   Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 28 Mar 2002 19:23:26 -0800

> there needs to be some serious security work

[Rajeev:] If I may add to this.. In the current version of FMIPv6,
a MN binds (or attempts to bind) its current CoA-1 with a prospective
CoA-2 valid on the new access router.  In other words, CoA-1 is the
temporary HoA. So, the addresses in Fast BU look as follows:

Src-IP = CoA-1, Dst-IP = AR-1, HAO = CoA-1, alt-coa = CoA-2.

For HoTI/HoT test: since the AR-1 is the AR forwarding packets to
CoA-1, this is somewhat simplified. In fact, ProxyRtSol can be HoTI
and ProxyRtAdv can be HoT.

For CoTI/CoT test: here, AR-2 may "vouch" that CoA-2 is valid using
Handover Initiate/ Ack sequence. Only when AR-1 receives such a
confirmation from AR-2 which it trusts, AR-1 will bind CoA-1 to
CoA-2. Note that if AR-2 agrees to "host" CoA-2 until the MN arrives,
you cannot flood any arbitrary node but AR-2 itself. But, AR-2
only maintains a very small buffer corresponding to proxy ND cache for
packets destined for CoA-2.

Assuming that AR-1 and AR-2 have security association, could this
vouching by AR-2 be considered sufficient ?

Regards,

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 29 Mar 2002 16:10:44 +0100 (CET)

> vouching by AR-2 be considered sufficient ?

Rajeev,

Since I don't know much about FMIPv6 let me try to restate an
approximation which should't add any significant new residual threats.
Assume AR-1 and AR-2 have a security association used for these messages.

AR-1 sends something to AR-2 saying "MN coming your way - will have CoA-2
when it arrives".
AR-2 responds with "ok, I will forward the CoT when I get it".
Then AR-2 then forwards the CoT to either AR-2 (which in turn sends
it to CoA-1) or directly to CoA-1 at which point the MN can send the BU.

Basically AR-2 trusts AR-1, under the security association, so that 
random nodes can't get it to forward CoT for bogus CoAs.

   Erik

---

From: "James Kempf" <[email-masked]>
Date: Fri, 29 Mar 2002 08:43:11 -0800

Rajeev,

I think security on the HI/HAck should remove the need for the CoAT.

Currently, I don't think the FMIPv6 draft says anything explicit about
security on HI/HAck, however. It should be made explicit.

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: <[email-masked]>
Cc: "'Erik Nordmark'" <[email-masked]>; "Hesham Soliman
(ERA)" <[email-masked]>
Sent: Thursday, March 28, 2002 7:23 PM
Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16

---

From: "James Kempf" <[email-masked]>
Date: Fri, 29 Mar 2002 09:02:18 -0800

Erik,

I don't think there even needs to be a CoT message. The HI includes the
proposed new CoA-2 within it for stateless, and the HAck includes it for
stateful. If there is a signature on HI, AR-2 will know it came from a
legitimate source. For stateful, AR-2 is providing the address, and a
signature will allow AR-1 to know that it came from a legitmate source.

One of the benefits of having real routers involved is that we can
leverage off the routing security infrastructure.

            jak

----- Original Message -----
From: "Erik Nordmark" <[email-masked]>
To: "Rajeev Koodli" <[email-masked]>
Cc: <[email-masked]>; "'Erik Nordmark'"
<[email-masked]>; "Hesham Soliman (ERA)"
<[email-masked]>
Sent: Friday, March 29, 2002 7:10 AM
Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 29 Mar 2002 19:09:11 +0100 (CET)

> signature will allow AR-1 to know that it came from a legitmate source.

So the BU isn't going to be sent to a CN?
I was assuming it would be in which case the MN would need to correct
Home cookie and Care-of cookie.

   Erik

---

From: "James Kempf" <[email-masked]>
Date: Fri, 29 Mar 2002 10:33:21 -0800

> Home cookie and Care-of cookie.

I'm not sure I understand. The MN does need to send an F-BU to the old
AR. That either happens when the MN is on the old link or on the new.
What I'm saying is that I don't believe there needs to be an RR test on
the new CoA because the HI/HAck exchange allows the old AR, which
is serving as the on link home agent, can be strongly authenticated.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 29 Mar 2002 16:52:47 -0800

> I think security on the HI/HAck should remove the need for the CoAT.

I agree with you. I was trying to draw out parallels using the
RR jargon (hangover:-). In short,

AR-1 trusts CoA-1. AR-1 trusts CoA-2 transitively through AR-2, what
I called vouching. Hence, AR-1 can bind CoA-1 to CoA-2.

Perhaps Erik was thinking that MN may wish to send a BU to CN
from AR-1 itself. Is that right ? This is not needed for FMIPv6, since
BU transmission epoch is not time-critical.

> security on HI/HAck, however. It should be made explicit.

Yes.

Regards,

-Rajeev