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

more on IPSEC architecture

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