Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec

From: [email-masked]
Date: Thu, 26 Sep 2002 12:17:59 +0300

Francis Dupont wrote:
>  In your previous mail you wrote:
>    2. It appears that the care-of address in BU is not properly
>   protected, if ESP is used for protection. I looked for a requirement
>   to use the Alternate Care-of Address option in the BU if ESP
>   protection is used, but could not find it.
> 
> => this was discussed in the list and was considered as a good use of
> the alternate CoA sub-option.
> 

So is there a plane to make this a requirement?

>    Also, with ESP the Home Address seems to be protected via the
>    pseudo header (used in the checksum calculation) only. Is this by
>    design?
>    
> => this is a mistake and to put (or not) the HA in the BU is 
> still an open
> issue (it was before the draft 18).

IMO HA should be in the BU, in general the BU should be as self contained
as possible.

> 
>    4. One approach could be to utilize the MN-HA ESP tunnel also for
>   Mobility Header protection. At the minimum, all MH-headers in the
>   tunnel regardless of the source and destination address should be
>   encrypted. This would protect the MN-HA BU/BA signaling, as well as
>   return routability messages sent through HA.
> 
> => the MN-HA BU/BA signaling must not be protected this way because
> this opens a trivial chicken and egg issue (as it is used to build
> the tunnel). In fact, the BU/BA signaling is the only thing which
> needs a special processing (i.e., which can't enter into a mobile
> IPsec VPN stuff for instance).
> 

As the IPsec SA is identified with the SPI, destination address, and the 
IPsec protocol, wouldn't it be possible to use a wildcard source address 
for the HA's incoming SA for each MN? Naturally each MN should have a 
separate SA, but the SPI field should be enough to multiplex them. If 
this is possible, then the HA's incoming SA would just ignore the source 
address, and would thus work from any address (home address, care-of 
address, new care-of address, etc.). The outgoing SA could be updated 
by the BU the same way as is currently done for the MN-HA tunnel SAs.

>   Optionally, ALL packets in the tunnel could be protected.
> 
> => this is what I call "mobile IPsec VPN" convergence.
>    
>    6. The MH Authenticator option SHOULD be an option for MN-HA MH
>   protection, should the security relationship between MN and HA say
>   so. Why not?
>    
> => the draft 18 mandates IPsec which is available (in IPv6 compliant
> implementation) and easier to use (no need for a new DOI for 
> instance).

Is it really easier? To me the current method seems rather complex! 
Is there any Mobile IPv4 experience we could learn from?

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Sep 2002 13:47:15 +0300

[email-masked] wrote:
>>the alternate CoA sub-option
> 

Yes. Text in:
   http://www.piuha.net/~jarkko/publications/mipv6/issues/issue70.txt

> Is there any Mobile IPv4 experience we could learn from?

I'm also beginning to think the use of IPsec for this was tougher
than expected. However, I'm not sure we have any easy alternative
either. MH authenticator option does not offer protection for HOTI/HOT
for instance.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Sep 2002 14:32:55 +0200

> the alternate CoA sub-option.
   
   So is there a plan to make this a requirement?
   
=> yes. I believe it is already somewhere but it must be clearer.

=> I fully agree.

   IPsec protocol,

=> this is an illusion and a common confusion. The IPsec SA is identified
by between 0 and 4 addresses (I can give a reference for each of the 5 cases).

   wouldn't it be possible to use a wildcard source address 
   for the HA's incoming SA for each MN?

=> you forget that IKE builds SAs by pairs so this doesn't work for the
reverse way.

   Naturally each MN should have a 
   separate SA, but the SPI field should be enough to multiplex them. If 
   this is possible, then the HA's incoming SA would just ignore the source 
   address, and would thus work from any address (home address, care-of 
   address, new care-of address, etc.).

=> this argument applies to tunnels and in these cases the address is
the outer one (which should not be checked according to RFC 2401 even
if many implementations are too paranoid about this point).

   The outgoing SA could be updated 
   by the BU the same way as is currently done for the MN-HA tunnel SAs.
   
=> unfortunately this kind of integration between IPsec and Mobile IPv6
is only available in some dreams.

   > implementation) and easier to use (no need for a new DOI for 
   
   Is it really easier?

=> yes because you have to do the same thing (create a shared secret
and use it for authentication & integrity).

   To me the current method seems rather complex! 

=> it should not... the only problem is that IPsec is not well
known by Mobile IPv6 people (and the opposite).

=> this experience shows the security should be handled by
the security stuff and not vaguely hacked. So the choice of
IPsec is the right one (the global PKI argument applies only
to general correspondents in an open network).

Regards

[email-masked]