new I-Ds, etc.

[Stephen Kent <kent@bbn.com>]

Folks,

	Extensively revised versions of the AH and ESP specs have been
submitted as I-Ds.  I'll send out the formatted versions to the list as
well, to help speed up the distribution process.  Please forgive the
receipt of moderately large documents later today.  The changes to the
documents represent an attempt to unify the document structure for IPsec
(to do away with the proliferation of "transform" documents), and to make
some substantive changes that promise better efficiency and effectiveness,
and simplier impelmentations.

	For example, the new AH spec should suffice, with its reference to
HMAC and the indirect references to MD5 and SHA-1, to encopmass all of the
previously described AH transforms.  Any new algorithms that might be added
for AH use can be described in very brief documents that need not reproduce
packet syntax, etc.  Similarly, the new ESP spec attempts to capture all of
the essential features of all of the proposed ESP transforms. (No inclusion
of compression for now, but it will be easy to add the necessary
placeholders if the WG elects to do so.)  We do need a revised spec for DES
CBC, with explicit and implicit IVs but without reference to all the other
fields, and then the transition to the revised spec format shold be
complete (for the default algorithm sets).  New algorithms should be
described in short, focused documents that need not describe the rest of
the packet, other security services, etc.  Combinations of services and
algorithms are definbed through the ISAKMP negotiations, thus doing away
with the need for additional documents to describe all the precommended
combinations of services and algorithms.  If nothing else, we will save
lots of trees (and electrons?) through this consolidation strategy.
Implementors will have fewer documents to read and there will be fewer
opportunities for inconsistency.

	All of the sunstantive changes to the AH and ESP specs have been
discussed on the list, and most were briefed at the last WG meeting, in San
Jose.  Although I will not be in Memphis, Nina Yuan has worked with me on
these specs and will be there to provide briefings on the I-Ds and on the
architecture document (see below).  We look forward to receiving any
feedback that will further improve the quality of these important specs.
We hope for speed approval by the WG, so that we can move to last call and
issue new RFCs that reflect the nature of the current, evolved AH and ESP
designs and implementations.

	I am sorry to say that the architecture document is not among the
newly released I-Ds.  I have decided to re-write this document from
scratch: (zero-based budgeting?).  This decision was motivated by several
observations:
	- the extensive changes in the AH and ESP documents
	- descovery of a number of architectural issues that need to be
addressed but were not included in previous versions of the document (and
some of which have not received extensive discussion on the mailing list)

In this latter category are several important issues that we will be
raising on the list (after Memphis).  The plan is to propose language for
the architecture document for each major issue, with supporting analysis
for the proposal, and to reach concensus before incorporating the text (or
a revised verison of the text) into the new document.  The list of issues
to be addressed in this fashion include:
	- proper handling of the DF bit and processing of ICMP PMTU messages
	- requirements for selectors (filters) for SA bundles, in
integrated host, bump-in-the-stack, bump-in-the-wire and security gateway
implementations
	- header and option copying in tunnel mode, for both inbound and
outbound traffic, in hosts and gateways
	- a uniform mechanism for extracting autehntication and/or
encryption keys for use with AH and ESP, based on ISAKMP exchanges
	- a mechanism for discovering and verifying the authorization of
security gateways

	As you can see, we have a few things to discuss and resolve before
we can calim to have a complete architecture for IPsec, even though we have
made a lot of progress so far and we have nailed down a number of
architectural issues.  As noted above, we will begin sedning out messages
(one per topic) for each of these issues, after Memphis, with the intent to
having resolution of the issues and a new architecture I-D well before
Munich.

Steve

---

• Prev by Date: Re: replay mandatory?
• Next by Date: new AH spec (big message)
• Prev by thread: Re: replay mandatory?
• Next by thread: new AH spec (big message)
• Index(es):
  • Main
  • Thread