Subject: Fwd: Re: [mobile-ip] RR and BU to HA

From: [email-masked]
Date: Thu, 23 May 2002 16:04:07 +0800 (CST)

> 
> The current draft identifies a need to verify the
> return routability of CoA when the BU is sent to
> a CN. 
> 
> But it suggests that one can use IPsec between
> the MN and the HA when MN is sending a BU,
> and this should be sufficient.... Shouldn't we be
> doing a RR on the CoA even if we are using IPsec?
> 
 
The draft does not specify, but my understanding is that MN would
use ESP transport mode with srcaddr=COA for sending BU to HA.
As long as there is correct SA between MN-homeaddr and HA and
home-addr in HOA dst option matches with the authenticated BU
MH home-addr part, there is no problem. In CN case, separate 
COA RR check is necessary to avoid reflection attack from another
malicous MN. 

However, I see some issues in :
11.6.6. Forwarding from a Previous Care-of Address

section, where it says that BU home-addr and HOA-dst option both
contain the previous COA address. So, the question is how does HA
match the security association in this case ? 
I assume that the draft assumes the sequence would be:
1. update HA first with your new COA with HoA= MN's home-addr
2. Then send BU to forward packet from previous COA. 
   In this case HA should do a few extra checks to make sure that the
   new COA already has a valid BCE.
   
   But, I am still not sure how would HA do the SA check for homeaddr
   in this case ( since homeaddr=previous COA), I believe there is no
   security association with the previous COA and HA.

   -Samita

---

From: [email-masked]
Date: Thu, 23 May 2002 16:20:06 +0800 (CST)

-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 23 May 2002 12:05:50 -0700 (PDT)

> SA's are matched by the incoming SPI and (somewhat
> uselessly, IMO) the *destination* IP address (ie,
> the HA). The SA lookup logic itself shouldn't
> depend on the source address (ie, COA) being the
> same packet to packet [*]. 
> 

Ok. Since the receiver (HA) would identify SA from <dest, spi>,
so, you're saying, that the same MN would be using the same SPI
while changing care-of-addresses. So, as long as the SPI is authenticated,
we should be safe ? 
 
Thanks.

-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 24 May 2002 11:27:14 -0700 (PDT)

> Erik Nordmark wrote:
> 
> 
> > So requiring the HA doing a CoA RR check doesn't seem to remove the
> > need for adminstrative measures that treat the HA+MN as one unit
> > when it comes to misbehavior.
> 
> This is true, and I agree.
> 
> It considers HA+MN from an outside viewpoint. There
> may be another aspect if you look at things from the
> inside, e.g. from the point of view of e.g. an ISP operating
> a HA. While they have a contractual relationship with the MN's
> owner, they might still wish to _prevent_ forged CoAs rather
> just to send a bill/police to the MN's owner afterwards, if
> someone complains. Still, the ISP could cut the MN's access
> off immediately when a complaint is received. So I'm not sure
> a test is worth the trouble. Certainly not as a mandatory thing
> for everyone.

Exactly. The above comments have explained the rational why there is no
strong reason to have RR COA test for MN-HA registration.

I agree, it is unnecessary to impose mandatory RR COA check between MN-HA
for the home registration.

I wonder, if it makes sense to have a recommendation for HA to dis-allow
*multiple* home-addresses  per globally unique COA, when a BCE already
exists for that COA associating with a different Home-addr.

[This will prevent the case when malicous MN tries to put victim MN's COA
 in the home-registration to fool HA]

> 
> In conclusion, we have the following options:
> 
> (1) Declare that we never need such tests. End of story.

Let's try 1) and move forward.

-Samita

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 24 May 2002 20:37:31 +0200

Jari, 

After writing my email I realised that it 
might be misunderstood. I thought you were
referring to removing the CoA tests for CNs
as well. If that's what you meant then my 
answer is correct. But if you were only
considering the HA then I agree with 1). 

3a is ok, but it might be too much work...

Hesham

  > -----Original Message-----
  > From: Jari Arkko [mailto:[email-masked]]
  > Sent: Friday, May 24, 2002 6:14 PM
  > To: Erik Nordmark
  > Cc: Alper E. YEGIN; [email-masked]
  > Subject: Re: [mobile-ip] RR and BU to HA
  > 
  > 
  > Erik Nordmark wrote:
  > 
  > 
  > I think Francis was saying that we already do something similar
  > in the sequence number resync case. Actually, it seems that the
  > HA could implement a CoA test using existing protocol mechanisms,
  > if they wanted. Just complain about a wrong sequence number,
  > and require the MN to resync. The right sequence number will not
  > be received if the CoA was wrong. (Of course, with some effort
  > you could guess the sequence number with repeated trials, but
  > at this point the HA would probably notice that something funny
  > is going on anyway.)
  > 
  > (2) Declare that we always need such tests, and add this
  >      to the protocol.
  > (3) Declare that you are allowed to run such tests, if your
  >      policy requires it. You could alternatively implement this
  >      with (a) existing mechanisms or (b) design new mechanisms.
  > 
  > My personal preference is either (1) or (3a). I don't think
  > we should spend too many cycles on specifying this or roundtrips
  > on doing it.
  > 
  > Jari
  >

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Fri, 24 May 2002 11:49:27 -0700

Is there a possibility of similar spoofing in the Home Address (HoA) field
in RR/BU ? How should the CN/HA treat a BU/RR  with a "spoofed" HoA  ?

Jari:

I'm not sure I understand the question, but if you are asking
for the basic spoofing attack of claiming a wrong home address,
then in the CN case we make a home address test. In the HA case
we must make sure that the right SA is used together with the
right home address, to prevent another mobile for the same HA
taking over your address.

Subrata:

That is solved when an SA exists. Setting up the SA is another open issue.
Is the SA approach going to scale to large number of MN's ?
In the absences of IPSec SA, it is possible for an MN to highjack a HoA.
This can be made a little more difficult if the HA checks that HoA has not
changed the L2 MAC address (This probably would be a new requirement). It
would not be easy for an MN to spoof both the HoA and L2 MAC at the same
time.

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Fri, 24 May 2002 11:49:26 -0700

If the CoA is not being used, then the HA does not have a BCE for it,
which
implies that the MN can use the CoA if it wants without bothering any
other
MN. The question would be does the HA allow a CoA to be shared between
multiple MN's ?

I don't see a reason to prohibit the same CoA for several MNs. Anyway,

as long as the MN doesn't register its current address in the home
agent, it looks exacly like any IPv6 address and the same rules apply
on duplicate address detection etc.

Yes, but DAD happens in the local subnet. It is the spoofing that is
problem -
does the HA do a DAD for CoA ?

Jari

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 27 May 2002 16:33:24 +0200

=> I'm reviewing the spec right now and I agree with
you. I think something that reflects the contents
of Erik's email and parts of Jari's (above) email 
should be included in the spec to explain the motivation.

  >    option 1) will open the door for reflection attacks
  >    which breaks the 'do no harm' policy. 
  >    
  > => so you are for >1?

=> Actually, in a later email, I explained that I misunderstood
Jari's email to mean (1)remove COT for CNs, so of course
I hastily replied with a 'no'. But since it was only related
to the HA, then I think (1) is fine. Also 3a is ok but
more complex of course.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 29 May 2002 13:39:00 +0200

Works for me. You could add a sentence saying that
if the MN and HA are owned by a single administrator
(home network case), then this approach would
result in treating them as a single entity...
which is reasonable. 

Hesham