[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ESP New Draft
There has been considerable debate on the "changes" to the ESP specification.
A new draft of ESP will be published before May 23. This new draft should
focus the wide ranging discussions on this mailing list. We will expedite the
progression of this specification and have a "last call" review start as soon
as it is published. When this specification is published I urge the working
group to submit concise and constructive comments in a form that could be
readily incorporated into the specification.
The "changes" in this new specification should not be significant! ESP
implementations conforming to the Memphis implementors agreements will be
conformant to this specification. The only issues for the ESP specification
are the optional "value added" capabilities of ESP that include auth-only-ESP.
These capabilities have been intensely debated because they allow a choice
between the architectural application of the AH protocol versus the ESP
protocol.
As working group chair, I see no clear consensus to forbid the use of ESP with
a null encryption algorithm (a.k.a auth-only-ESP). There have been many
strong statements made to the mailing list recommending that ESP always
encrypt. I've also talked to implementors developing auth-only-ESP as a
"valued added" option. ESP has the flexibility to support any algorithm.
Clear guidelines need to be provided that define the usage of these algorithms
including the use of a null encryption algorithm.
Auth-only ESP does not provide exactly the same security services as AH.
The technical capabilities of AH versus auth-only ESP are best worked out in
the market. The proposed text (from Steve Kent) to document this capability
in ESP as a "MAY elect" is a reasonable compromise. Standards conformance of
IPSEC implementations will not be based on this mode of operation.
The implementors that met in Memphis clearly demanded that there be no options
at all in ESP. These agreements are appropriate for the mandatory to
implement capabilities. The fervor to interoperate should not close off all
options for value added capabilities that "may" be implemented.
The raging debate on auth-only ESP should be represented by only a small
section of text describing when it is appropriate to use a null algorithm
("may" versus "should not"). The release of the new ESP specification next
week should provide an opportunity for clear comments on the text representing
these issues.
Regards,
Paul A. Lambert
<ipsec chair>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 633-2963
Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Follow-Ups: