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

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 22 May 2002 23:45:58 -0700 (PDT)

> 
> 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: Francis Dupont <[email-masked]>
Date: Thu, 23 May 2002 13:53:40 +0200

=> you have the choice between ESP transport mode with the COA
protected (i.e. repeated) and AH transport mode. Tunnel modes
give nothing more than complexity.

   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.

=> I disagree: you have the same problem with the COA for the HA.

   In CN case, separate COA RR check is necessary to avoid reflection
   attack from another malicous MN.
   
=> so the COA RR check should be necessary for HA too???

   section, where it says that BU home-addr and HOA-dst option both
   contain the previous COA address.

=> yes, the previous COA takes the role of the home address.

   So, the question is how does HA

=> this HA is on the previous visited link.

=> here the HA is the HA on the home link.

=> this is not the same HA than in 1.

=> it should be but the real question is how the SA pair is established...
Even if this is done before the movement this is not easy.

Regards

[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 May 2002 07:21:05 -0700 (PDT)

> match the security association in this case ? 

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 [*]. 

 >    security association with the previous COA and HA.

The incoming COA should have never played a part
in the decision [**]. It's ex/implicit authorization
from the *credential* which established whether a
node is allowed to rebind itself to another
location.

		Mike

[*] there is obviously the access control aspect
    of IPsec here too, but a wildcarded filter
    on the source would allow it to pass

[**] other than internal for policy reasons, of
     course.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 May 2002 07:59:17 -0700 (PDT)

> give nothing more than complexity.

   I hope this is not to imply that a tunnel mode
   SA's aren't sufficient to protect BU's. It should
   be, and should be allowed. If you already have
   a tunnel mode SA back to your home agent
   (because it's, say, at the edge of your home
   network which is walled off), it would be
   pretty wasteful to force the use of a transport
   mode SA as well.

	   Mike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 23 May 2002 19:12:45 +0200

I hope this is not to imply that a tunnel mode
      SA's aren't sufficient to protect BU's. It should
      be, and should be allowed.

=> there are allowed but when there is no already available SA and
the SA will be setup only to protect the BU then a transport mode
should be used.

      If you already have
   
=> we agree: MAY for tunnel, SHOULD for transport.
BTW I don't know how to encode this in a policy (:-).

Regards

PS: my main target in this discussion is to not go backward, i.e.,
to get *no* requirement for a RR check when IPsec protects the BU.