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

Re: IPsec Architecture -- proposed changes

Ran,

	The MLS-related text from the last draft that you authored was not
complete and it spread throughout the old text.  It cannot be carried
forward into the new text without significant additional work, both
editorial and technical.   Since we are under considerable pressure to get
this document out, we don't have the time to do the necessary work to
create and integrate new material.  Spreading out the MLS-relevant text
into the re-organized document would make the new document hard to read, so
I'm not in favor of that.  Consolidating it into a separate section, which
is what we had planned when we developed the outline for the first draft
that we published (in late July) requires more work than we can offer.

	If you or other with interest in this aspect of the architecture
cabn supply appropriate text we could incorporate it, but I don't want to
incorporate something superficial.  I question the notion that the
assertion that the previous text was "mininmal but sufficient."  Sufficient
to enable independently developed, interoperable implementations over a
range of MLS environments, or sufficient for one vendor to develop an
implementation that works in a small set of MLS contexts?  The former is
the goal for RFCs; the latter is much easier to accomplish and is
characteristic of all the network layer, MLS security devices that I've
seen over that last 20 years.

	I agree with Steve Bellovin's observation that the current
multicast technology is not sufficiently mature to warrent inclusion at
this time.  The GKMP work may be good, but the RFC is experimental.  The
CBT multicast design of Ballardie distributes keying material to routers
along a multicast path.  This would be appropriate a a means of controlling
access to multicast groups for resource control purposes, but it is not an
ideal approach for confidentiality, integrity and authenticity of multicast
traffic per se.  A more recent paper by a Stanford PhD student suggests an
analogous approach, but with distributed multicast controllers, rather that
routers.  There is sufficient uncertainty here to warrent deferring
standardization for now.

	Finally, you repeat your comment that a major constraint on the
rewrites of the IPsec document set was that no changes be made that were
not backward compatible.  While I agree that this was the initial intent,
the WG has agreed to a number of changes over the last year, as more
details were worked out in analysis and implementation, so that this intial
goal is not really applicable.  Thus I would not refer to it as a basis for
evaluating the suitability of inclusion or exclusion of any material at
this point.

Steve

Steve
Follow-Ups: References: