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

Re: notes from developer's portion of IETF meeting



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


>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
    Stephen> consuming task.  My guess is that use of ESP in tunnel
    Stephen> mode will be popular, with one end of the SA at a
    Stephen> firewall.  Under those circumstances, AH in tunnel mode
    Stephen> does not buy one much, because the outer header is not
    Stephen> very interesting, i.e., it will be discarded.  (Only
    Stephen> rarely would it make sense to copy portions of it into an
    Stephen> inner header.)  Thus tunnel mode ESP would provide
    Stephen> suitable protection for traffic with greater efficiency
    Stephen> and less per-packet overhead. What I'm hearing from this
    Stephen> discussion is that the motivation for not offering ESP
    Stephen> w/o encryption is added complexity.  I'm all in favor of

  As long as you are optimizing in favour of the VPN application, then
let's be explicit and do that.
  The reason why ESP without encryption is not interesting is because
the P in VPN means private. If there comes to exist a strong
encrypting transform with built in integrity, VPN people will want 
that. 

    Stephen> reducing complexity, if it doesn't cost functionality,
    Stephen> but I'm really surprized to hear that offering ESP w/o
    Stephen> encryption is percieved as a significant increase in
    Stephen> complexity.

  We know AH is complex. Fine. AH isn't interesting for VPN
applications. Fine. 
  Let's allow a VPN-only to deal with lower complexity, and do only
what it needs to do. That means it might not do AH. It will encrypt.
  I realize that is in oposition to the IPv6 MUST implement (AH, but
not ESP). An encryption-less ESP could then become a MUST implement
for IPv6. 
  Remember: fewer options == interoperability.

    Stephen> support is an important feature.  Thus the flexibility
    Stephen> offered by modular use of ESP and AH is important to
    Stephen> these folks and is in keeping with the original intent of
    Stephen> IPSEC.

  Authentication-less ESP was left as an option. I'm not sure I
completely agree that audio data is not that sensitive to integrity
problems, but I see your point. You have provided a motivation for
continuing to include authentication-less ESP. I'm not convinced that
if you are encrypting, that authentication costs that much more:

  I know Stephen saw this talk at NDSS, but for others:
  
@inproceedings{Nahum1996,
	AUTHOR="Erich Nahum and David J. Yates and Sean O'Malley and Hilarie Orman and Richard Schroeppel",
	TITLE="Parallelized Network Security Protocols",
	BOOKTITLE="Proceedings of the 1996 Symposium on Network and Distributed Systems Security",
	YEAR=1996,
	note = "NDSS online proceedings \htmladdnormallink{http://bilbo.isu.edu/sndss/nahum.ps}{http://bilbo.isu.edu/sndss/nahum.ps}",
}

  
   :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 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

iQB1AwUBM1zUiaZpLyXYhL+BAQGFngL+JKb0Qn11mdj6kTkzm8IoGW4rics3KFDX
dB48gnvVrng95AuRMxWL/3ys31lsmEX40N6tunvOg/Xr0I6dvaX6Uy2mSPnZF4ou
Ma3lmSX6FXqAue6L4bB9rWXg4Xo+tZJK
=5dZ1
-----END PGP SIGNATURE-----


Follow-Ups: References: