Subject: Re: [mobile-ip] on using IPsec to secure Binding Updates

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 1 Aug 2001 10:09:53 -0700 (PDT)

Thomas,

If you separate the key management from using AH and ESP for
securing binding updates, you have raised two issues about
using AH or ESP itself :

1) There is no policy selector for securing just binding update
2) The state maintained by IPsec could be large.

(1) is not really a big issue if we could come up with a new
next header value. At least IPv6 was designed to do such things
i guess.  We really have to think about (2). At least any new
solution that does not propose to use IPsec should not maintain
state larger than what IPsec would need. Should this be in the
requirements draft ?

-mohan

> Michael Thomas <[email-masked]> writes:
> 
> >    Actually, I don't think there's consensus about _not_ using IKE
> >    etc. There is clear direction from the IESG that PKI/centralized
> >    keying cannot be the _only_ method of protecting BU's, especially
> >    for random MN/CN situations. Where you can use strong crypto
> >    (same administrative domain, say), it should be used in
> >    preference to a scheme based on a return routability test.
> 
> This is from the top of my head, and may be incomplete, but there have
> been a number of issues raised with using IPsec. That doesn't mean
> that using IPsec for securing BUs is completely DOA, but it does mean
> we may well want to to consider an alternate approach. Some people
> feel more strongly about this than others.
> 
> Issues:
> 
> 1) absence of global PKI (which is needed to avoid MITM) note: this is
>    likely a "problem" with all proposals.  Unless the two endpoints
>    have some sort of shared knowledge (e.g, key, CA, etc.), there is
>    no way to avoid MITM.
> 
>    Thus, IPsec (if used between MN and CN) would not in practice avoid
>    MITM. Thus, it may provide less protection that folks assume, and
>    may be a bit more expensive than other approaches that provide the
>    same protection.
> 
> 2) cpu cost of operations is significant, and perhaps overkill given
>    the function. (see point 3)
>   
> 3) cost/number of packets involved in setting up SAs. Again, this
>    seems to be overkill for the need at hand. It takes a lot of work
>    and packets to set up proper state before the BU can be
>    authenticated. Has someone done the math to make this clear?
>    Maintenance of state on large servers is also an issue that has
>    been raised.
> 
>    It is one thing to setup state for flows that will use that state
>    heavily (e.g., a TCP connection that encrypts the entire flow). It
>    is another to setup state that is only used for occasional packets
>    (i.e, the ones with BUs).
> 
> 4) incompatability of how filters are coded compared to what is needed
>     As currently specified (and implemented), the IPsec policy
>     database doesn't support the desired granularity of filtering. For
>     example:
> 
>    - It doesn't allow filtering on packets with just a BU. 
>    - The current filtering rules do not support selective filtering of
>      packets. I.e., either all the packets for a particular flow would
>      need to be protected by IPsec (in case one contained a BU) or
>      none would (in which case the BU would need to be ignored)
> 
>    Note: some these issues could be addressed by writing a
>    MIP-specific IPsec document that added more functionality. This
>    would need to be done for correspondances between the MN and HA,
>    but that might be OK. I.e, implementations of MNs aren HAs are
>    presumably special devices and putting extra requirements on them
>    are perhaps acceptable. However, it is not clear that it would be
>    appropriate (in general) to require all CNs (and by implication
>    *all* nodes) to also implement this. But we *are* looking for a
>    solution that allows arbitrary MNs and CNs to do route
>    optimization.
> 
>    In any case, the current (and previous) version of the spec didn't
>    have enough details on how to use IPsec in this manner and these
>    issues would need to be clarified to fully evaluate this approach.
> 
> Thus, while one certainly could imagine making IPsec fit, it is not at
> all clear that it is the most desirable approach given the actual
> function at hand.
> 
> The idea of only allowing BUs as standalone issues would appear to
> address some of the issues above, but not all. Of course, eliminating
> piggy backing, removes an optimization that also has benefits.
> 
> Thomas

---

From: Michael Thomas <[email-masked]>
Date: Wed, 1 Aug 2001 15:20:46 -0700 (PDT)

Jari Arkko writes:
 > Thomas Narten writes:
 > > ...
 > The list of issues is fine, but I think the discussion would benefit
 > if we keep the key exchange and the packet protection issues
 > separate. Global-PKI-as-the-only-BU-key-exchange -issue has
 > been discussed at length earlier, as is many roundtrip and RSA/
 > Diffie-Hellman efficiency issues. But these aren't necessarily
 > reasons to throw out AH, even if they mean IKE isn't applicable.
 > For instance, the separate-packet-with-new-next-header-value -approach
 > seems to solve all issues related to the use of standard AH with
 > RFC 2401 policies. Or did you Thomas have additional problems
 > even for this case?

While I agree that they are orthogonal problems,
without well defined mechanisms for key
distribution -- especially considering the scaling
implications of small/cheap mobile devices -- key
distribution is likely to be the real problem with
actual deployment. Retaining standards based key
distribution mechanisms with some deployment track
record is the safest and quickest way to
deployment that I can see. And I'm hardly what
you'd call an IKE evangelist (are there such
creatures? :-)

 > As far as the key exchange discussion goes, I would like bring
 > up one point, though. In the global Internet, we can't use PKIs
 > and other schemes. However, do we have requirements for
 > smaller parts of the network being able to do this? For instance,
 > assuming organizations like the DoD have a internal authentication
 > infrastructure in place, can they secure their internal BUs using _their_
 > PKI, or are they forced to rely on BAKE only? That is, assuming BAKE
 > is the scheme for the global world, do the protocols allow DoD to provide
 > better protection in their network? If so, how?

My interpretation of the IESG's general position
is that if strong authentication is pragmatic
(with fairly high standards for what is not
pragmatic), it must be provided for by the
protocol in order to advance. For MIP, it's a
mixed bag: in some cases it's possible (MN/HA) and
in some cases it's not pragmatic (random
MN/CN). Given that, it seems that we need to
provide for both options.

I'll add that the MIP working group is not the
only one to feel the heat because of this general
requirement, much to the chagrin of many working
group chairs.

       Mike