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

Re: order/nesting of IPsec headers (transport mode)

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Charles" == Charles Lynn <clynn@bbn.com> writes:
    Charles> I think that the question is really two questions humped
    Charles> together, and that the answer(s) depend on which question
    Charles> one is really answering.

    Charles> First, on the originating side, I agree that 1 thru 3 are
    Charles> reasonable, i.e.,

  I agree with your thought, and thank you for including a detailed
explanation of processing.

    Charles> As others have said, I do not think that any combination
    Charles> should be prohibited at the receiver.  This is consistent
    Charles> with the current IPv6 specification.  Consequently,

  One should note that an implementation may refuse to *negotiate*
this kind of a transform. Our kernel could be configured to support
these kinds of transforms, but our key manager will not do so.
  David Wagner had some comments (privately to me I think) that
ESP(des)-ESP(des) was in fact no stronger than a single round of DES
due to the amount of known text.

    Charles> The reason for the procedures given above is to make
    Charles> things work when a sender is using a hybrid stack, and
    Charles> the separate implementations, e.g., bump in the wire and
    Charles> an imbedded or user space implementation, and the two are
    Charles> not aware of the presence of the other.

  There are some deep key mgmt issues which suggest to me that this
won't work at this time. However, they are "merely" key management
things, and can be solved in userland rather than requiring kernel
changes.

    Charles> While the question was specifically directed at transport
    Charles> mode, I think that the same answers should apply to
    Charles> tunnel mode, as the choice of where policy gets
    Charles> implemented should be left to the customers.

   :!mcr!:            |  Network security programming, currently
   Michael Richardson | on contract with DataFellows F-Secure IPSec
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
  


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNAIpBKZpLyXYhL+BAQHE+gL6Ar9A/fxpna51+eAW39F455s2oPq4AQBF
zFL303gsjbFUAEc3bvlzFs4XjD/rUnvJZpIxzj301tzXIXYFUxMHXy4TP3jjCzwT
rAo5DVwM8yDV4W6HZ7i76VKaBNjw8kGE
=kqFl
-----END PGP SIGNATURE-----
References: