[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: