[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Death to AH (was Re: SA identification)

Marcus Leech writes:
 > The assertion was made that the current Mobile IPV6 spec uses
 >   IPSEC in a way that just doesn't scale.  AH was chosen by
 >   Mobile IPV6 because it provides protection of outer header
 >   information, including the bits of IPV6 options goop that carries
 >   Mobile IPV6 binding updates.  It's not *impossible* to use ESP
 >   for this, but it's awkward.

   So, as somebody who thinks that:

   a) the IESG's concerns about using IPsec to
      correspondent nodes to protect BU's are
      well founded

   b) that AH should be nuked in general to 
      simplify IPsec

   c) using IPsec between the mobile node and
      it's home agent for binding updates as
      well as *some* well known CN's (ie, not
      for the random web browsing case) is a
      good thing, especially if it provides
      better security properties than the
      ultimate solution for (a)

   I'd say that we either need to come up with
   an application layer security schemes for
   BU's which address (a) and (c) simultaneously
   or have a means to have base level IPsec
   protect BU's which are not dependent on AH.

   Charlie brought up -- and I think I agree --
   that it would be unfortunate if two nodes 
   that were already running IPsec between 
   them and they didn't raise the "global PKI" 
   spectre couldn't use IPsec to authenticate
   and authorize the BU. A trivial case is a 
   mobile SIP phone with an SA between it and its
   first hop proxy which have the same localized
   PKI properties as the SA between the HA and MN.
   (indeed, between HA and MN, there may be no need 
   for a PKI at all, cf KINK).

   I doubt that naive tunnel mode ESP really fits the
   bill well here. There are a lot of concerns
   about bits in the air that are quite serious
   and using a tunnel would at base add another
   40 bytes to the overhead. I'm also rather 
   suspicious about the contention that ROHC and
   its ilk make tunnel/transport moot: there is a
   huge amount of overhead and state machinery
   to run compressors and counting on them -- 
   especially when you start talking about mobile
   routers -- is dubious at best.

   Maybe we ought to entertain Bruce Schneier's
   suggestions. As far as I can recall, they
   would seemingly address the concerns I outlined
   above. Even if we don't try to deprecate
   transport altogether, an out of band
   negotiation of "the inner header is the same
   as the outer header" compressing tunnel mode
   would be pretty easy to cons up for ISAKMP.

	    Mike
Follow-Ups: References: