[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: notes from developer's portion of IETF meeting
Mike,
>>>>>> "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.
Well, many systems that claim to provide virtual private nets do so without
confidentiality. The closed user group facility in X.25 and frame relay
nets, the analogous facility in ATM nets, and similar soft configuration
options in switched ethernets are all cited as bases for VPNs. Today, we
rely on firewalls to provide access control at the perimeter of
local/campus nets. However, we do so with authentictaion of traffic
sources, or we sdo so based on bind time (vs. continuous) authentication.
So, using IPSEC to authenticate traffic provides a solid basis for making
the same access control decision, a noticeable improvement. We will not
always want to provide confidentiality for traffic at the firewall
boundary. For example, the traffic might be encrypted to the desktop or
server behind the firewall, so the extra layer of encryption might be seen
as unnecessary and an unwarrented performence hit. Higher layer encryption
might be employed, e.g., for e-mail, and here too layer 3 encryption may be
deemed redundant and not worth the cost. So, a flexible architectuire
should allow for SAs that terminate at a firewall and provide just
authentication . The debatem then, is whether it's better to provide this
service using ESP in tunnel mode or AH in tunnel mode.
> 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.
Yes, fewer options does increase the likelihood of interoperability. But,
as my comments describe above, there are valid reasons for
authentication-only tunnels in firewalls. So far we don't have v4
compliance reuqirements re AH and ESP, but we will need to address that
issue later, e.g., must one implement both to claim "IPSEC compliance?"
The architecture document can address this issue.
> 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:
The meeting minutes suggested that ESP must always be used with
authentication, either intrinsic to ESP or via a separate AH, hence my
concern and an example of why I felt such a requirement would be unduly
restrictive. Authentication costs more in packet processing time, and
especially in space for the small packets that characterize compressed
audio. We've been sending packet voice around the Internet in experimental
implementations for well over 15 years. The folks at Lincoln Labs have
been pioneers in this area, in DoD-sponsored work. Their continuing
activities motivated my comments about authenticationless-ESP.
Steve
References: