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

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 26 Sep 2002 14:41:17 +0200

=> I shouldn't try to save text and explain things 
properly :)
I think what you propose (including MPS, MPA, DHAAD
in the MH) is perfectly logical. But I was suggesting 
that we minimise the re-work so that we can save time. 
If time is not critical in this case then I don't
have a problem with it, but before we go ahead and change
things, let's have a complete proposal and not change it
merely because it would make IPsec processing simpler.
If we don't have a complete proposal (including HA
processing of these messages ...etc) we might end
up going in circles because we only look at one 
defect at a time.

Hesham

---

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?