more on IPSEC architecture
Stephen Kent <kent@bbn.com> Wed, 30 October 1996 01:40 UTC
Received: from cnri by ietf.org id aa26704; 29 Oct 96 20:40 EST
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa25221; 29 Oct 96 20:39 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa02546; 29 Oct 96 19:55 EST
Received: from relay.hq.tis.com by neptune.TIS.COM id aa02470; 29 Oct 96 19:46 EST
Received: by relay.hq.tis.com; id TAA17225; Tue, 29 Oct 1996 19:50:57 -0500
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma017221; Tue, 29 Oct 96 19:50:30 -0500
Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id TAA15203 for <ipsec@tis.com>; Tue, 29 Oct 1996 19:52:19 -0500 (EST)
Received: by relay.hq.tis.com; id TAA17214; Tue, 29 Oct 1996 19:50:27 -0500
Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma017209; Tue, 29 Oct 96 19:50:21 -0500
Received: from [128.89.30.10] (ARA10.BBN.COM [128.89.30.10]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id TAA19720 for <ipsec@tis.com>; Tue, 29 Oct 1996 19:52:20 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v02130500ae9bc479548c@[128.89.30.9]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 29 Oct 1996 19:54:09 -0600
To: ipsec@tis.com
From: Stephen Kent <kent@bbn.com>
Subject: more on IPSEC architecture
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Folks,
In speaking with Steve Bellovin this morning, he pointed out that
my note from yesterday failed to call out several important details.
First, in expanding on the MIB that Ran initially defined, it is
important to note than not all of the variables should be readable, or
readable by remote workstations. The obvious examples here are the
authentication and encryption keys cited in the MIB.
Second, I did not include the explanatoy text for the various
combinations of modes that I proposed as required for compliant
implementations. These modes are somewhat different for hosts vs. secuirty
gateways and a full discussion takes some space. For example, it strikes
me as useful to be able to have two nested ESP SAs, one tunnel mode and one
transport mode, where the tunnel SA terminates at the security gateway and
the transport SA goes all the way to the target host. If a host is going
to be able to take advantage of this potential, then there must be an
administrative interface of some sort to permit selection of this
combination of modes and SA nesting, as well as allowing for the more
obvious, non-nested SA configurations. (As Steve and I discussed this
morning, the security gateway need not be aware of the nested, transport
mode ESP SA for the above-cited example, so in this case the gateway has an
easier task!)
Finally, although I listed the AH-ESP(tunnel)-ESP(transport)
configuration, I'm not wedded to it. The utility of AH has declined
somewhat since ESP has become more flexible and functional. However, AH
still has advantages with regard to exportability and for circumstances
where the contents of the IP header must be protected, e.g., when security
labels are being carried. On that basis, one might argue for
ESP(tunnel)-AH-ESP(transport) as a more useful configuration, e.g., to
protect such labels within a trusted, MLS network environment.
I hope these clarifications help place my earlier note in context.
Steve
- more on IPSEC architecture Stephen Kent