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

Re: Proposed changes to ESP (andf a little AH too)



Dan,

	The "we" working on the revisions include two folks from my network
security departement at BBN (Karen Seo and Nina Yuan), plus Charlie Lynn, a
protocol expert who has been involved in Nimrod, IPv6, host requirements
and many other TCP/IP activities at BBN for over 15 years.  Nina will be at
Memphis (I have a prior engagement in Singapore) to brief the AH and ESP
I-Ds, plus to go over some of the architecture document open issues.

	I agree with your observation that we have to look at every
proposed change to AH and ESP with an eye toward the percieved benefit and
to the cost (including time to market) for vendors.  However, in working on
the architecture document, we have uncovered a lot of issues that have not
been well addressed to date, and I suspect that resolving these issues will
actually cause more potential delays than the format changes we're looking
at for AH and ESP.  For example, the list had a brief discussion of PMTU
and DF bit conventions, but our analysis has come up with a pretty good
rationale for what  various implementations should do, and when.  Also, the
currently posted architectuire I-D calls for being able to use a variety of
IP header fields (and TCP/UDP port fields) as selectors for defining SAs or
nested sets of SAs (I like the term "SA bundle" as suggested earlier).
Yet, I have not seen any implementations that support these features, so
far, even though the I-D has been out for over 6 months.

	As for the window size issue, I agree that one can simply decline
to negotiate a size of 1, as a means of addressing this issue.  However, I
really believe that a size of 1 is so awful that it ought not be allowed.
Moreover, only a size of 1 is proposed as required so far, and if we say
dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof)
instead.  So, that's why I'd like to change to make 32 a MUST support, and
multiples of 32 be recommemded optional window sizes.

	Your question about tranform document vs. transforms deserves a
thoughtful reply.  The revised specs (its more of an issue for ESP, but it
applies to AH as well) will contain the details for (optional) anti-replay
counter management.  They also will describe how to do (optional) HMAC
computation, with appropriate references to base spec by Hugo.  There will
be a definition of the required padding technique for ESP.  Default
algorithms will be cited and referred to via base algorithm specs.  The
goal is to no longer have "transform" documents, but only these specs and
algorithm documents.  In that sense, the number of transforms will
diminish, since we will have made the combinations of algorithms and
processing morr modular.  However, one will still need to negotiate
"transforms" as part of SA management, and it's up to the Wg to decide how
many of these MUST be supported, vs. ones that MAY be supported, etc.  So,
I do think my goal is consistent with yours, in that I hope to have
algorithms plus options within each protocol. One selects the combinations
of algorithms and options via SA management, and we have chosen to label
the bundled combinations "transforms."

Steve

P.S.

I hope this explanation lays to rest any rumors about the demise of AH.  I
do see a diminished role for AH once we have ESP implementations that
support encryptionless SAs, but there will still be uses for AH.




Follow-Ups: References: