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

From: [email-masked]
Date: Thu, 26 Sep 2002 10:10:56 +0300

Jari,

Thanks for making the details explicit. Some questions on this and related issues:

1. It would help if you somehow numbered the requirements, as it would make references to specific requirements much easier.

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. Also, with ESP the Home Address seems to be protected via the pseudo header (used in the checksum calculation) only. Is this by design?

3. It seems that in total 16 entries in SPD and SAD are needed for each MN in the HA. Has anyone calculated how much space these take? What would be max number of MNs that can be supported by a HA with a typical IPsec implementation with these requirements? Should alternative solutions be explored, where each MN would require less IPsec state?

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. Optionally, ALL packets in the tunnel could be protected.

5. To further reduce the number of SAs, all mobility related signaling specified in the Mobile IPv6 spec should be utilizing the Mobility Header instead of ICMPv6 (Mobile Prefix Solicitation/Advertisement, Home Agent Address Discovery messages). IMO this would be very logical, clarifying improvement also from non-security viewpoint.

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?

7. MN/HA SAs could be used both in tunnel and transport modes, if there is desire to send the BU/BA in the transport mode. However, it is likely that better header compression results are achieved with the tunnel mode (IP headers of random BU/BA are unlikely to get compressed, while the tunnel's outer headers are highly likely to be compressed).

With regards,

	Jarno Rajahalme

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: Friday, September 20, 2002 8:53 AM
> To: [email-masked]'
> Subject: [mobile-ip] Protecting the MN-HA signaling with IPsec
> 
> 
> Hi,
> 
> As you recall, issue #69 was a complaint that our specification does
> not describe in sufficient detail how to use IPsec to protect 
> the MN-HA
> signaling. As a result of that, Vijay and myself wrote a note that
> was posted to the list. This note was brief and didn't 
> include everything.
> We also debated some aspects of the note.
> 
> With Francis and Vijay, we have now written an expanded note in draft
> form. The intention of this draft is to become a companion RFC for
> the base MIPv6 specification and to illustrate in detail all aspects
> of the issue: processing requirements, packet formats, configuration
> procedures, and internal processing order. The normative processing
> requirements will stay in the base RFC, however (with some updates
> needed). But seeing only those processing requirements it isn't
> very easy to understand the whole picture, and it may not be enough
> to convince ourselves and the IESG that this actually works ;-)
> 
> The draft has been submitted, but before it appears in the official
> directories, you can access it at the following URL:
> 
>    
> http://www.piuha.net/~jarkko/publications/mipv6/draft-ietf-mob
> ileip-mipv6-ha-ipsec-00.txt
> 
> Writing this draft involved coming up with solutions to certain issues
> such as how to use dynamic keying without causing 
> chicken-and-egg problems.
> You probably also recall Francis' draft which listed a number 
> of issues
> that were either necessary to fix before IPsec and MIPv6 
> worked together,
> or optimized their behavior when used together. Finally, we made some
> design choices (how easy the rules are for BITS 
> implemenations etc) that
> could perhaps be debated. So take a look at Section 10 for a 
> discussion
> of some of these hard issues.
> 
> Jari
> 
>

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Sep 2002 10:17:56 +0200

=> in fact there are many details missing and some edition errors (we
had to publish the draft last week because of the IPv6 ETSI plugtest).

   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.

   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).

   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).

  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).

   7. MN/HA SAs could be used both in tunnel and transport modes, if
  there is desire to send the BU/BA in the transport mode.

=> the choice is to use transport mode for end-to-end protection
and tunnel mode where there is an encapsulation. There is no need
for other options.

   However, it is likely that better header compression results are
  achieved with the tunnel mode (IP headers of random BU/BA are unlikely
  to get compressed, while the tunnel's outer headers are highly likely
  to be compressed).
   
=> the BU/BA traffic is sparse and carries "random" fields so
the compression argument doesn't apply.

[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Sep 2002 11:11:56 -0700

[email-masked] wrote:

>Also, with ESP the Home Address seems to be protected via the pseudo header (used in the checksum calculation) only. Is this by design?

one of the SA selectors is the home address. if the selectors 
dont match, the packet is dropped.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Sep 2002 02:13:39 +0300

Thanks Jarno for your comments!

> the compression argument doesn't apply.

It is true that continuous tunnel traffic would compress better
than an occasional BU by itself. However, the compression applies
only to the outer IP header. And since we don't have that in the
pure BU case at all, the end result is that the tunnel case will
continue at least as much bytes as the pure BU.

By the way, I think ROHC is actually able to have different
contexts for different traffic flows. This means that Payload
BU Payload BU Payload BU .... compresses as well as Payload Payload
Payload ... BU BU BU ... So even the transport mode BUs are likely
to compress at least a little.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Fri, 27 Sep 2002 08:23:15 +0200

=> this is not the proper level of protection we'd like. Using
Michael Thomas' terminology, this is "access-list" security
when we want "cryptographic" security.

Regards

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Sep 2002 12:21:38 -0700 (PDT)

> when we want "cryptographic" security.

   Again, another disclaimer about how far behind I am,
   but why wouldn't access-list style security be
   sufficient? Is it to prevent different user on
   the same home agent from hijacking each other's 
   session?

   In any case, since MIP and IPsec are typically
   in the kernel I'm not sure that there's really
   much of a disconnect here. That is, it seems
   pretty plausible that the MIP code could look
   into SADB to determine what cryptographic
   identity is associated with a particular home
   address.

		Mike