[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: notes from developer's portion of IETF meeting
Dave,
The implementors' meeting notes say that the proposal for
encryption as an optional aspect of ESP was rejected, yet no rationale was
provided. I was surprized to see this recommendation from this group since
I briefed this notion back in San Jose and received no negative feedback at
that time, nor do I recall any negative feedback on the list since then,
with the exception of one message from Ran. Since I expect to see
noticeable performance differences between AH and ESP authentication,
because of the complexity of omitting some fields from the calculation in
AH, I'm surprized that implementors would not consider encryptionless ESP
to be an attractive feature for clients. Also, in light of the message
from Charlie Lynn, it would seem that ESP w/o encryption provides an
important facility in various contexts. So, why did this group recommend
not supporting that security service combination for ESP?
Also under the optional encryption heading, there is a mantion of
tunnel mode needing to be described in the AH specs. Since the current AH
I-D contains an extensive tunnel mode discussion, to what do these notes
refer?
The anti-replay notes do not distinguish between AH and ESP. Is
the intent that this field is mandatory in ESP too, if authentication is
negotiated?
As for the IV comments, these too seem odd to me. Not all
encryption modes require an IV, yet your notes suggest otherwise. Both the
presence and size of an IV is an algorithm/mode dependent feature. The
suggested requirement would undermine the algorithm independence of ESP.
What I assumed the group was moving toward is collapsing the IV into the
payload field (for ESP with encryption) to avoid having another optional
field in the header, a suggestion voiced by Steve Bellovin.
Steve
References: