[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: notes from developer's portion of IETF meeting
After getting a few complaints about the format of my message,
I'm sending it again.. Sorry, Microsoft Outlook got me.. I didn't
realize that the formatting I see isn't what I actually got back when I
received my own reply....
Here it is again.. sorry for the inconvience..
> -----Original Message-----
> From: Stephen Kent [SMTP:kent@bbn.com]
> Sent: Friday, April 18, 1997 9:38 AM
> To: David Carrel
> Cc: ipsec@tis.com
> Subject: 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?
My belief is that the slight gain in performance that you get from not hashing
over the headers isn't worth another option. If you want integrity, use AH. If
we're going to go this route, why not bag AH and always do ESP with an option
for header inclusion in the integrity calculation? One option is the same as
another at this point. I'm not suggesting this because I think it is too late
for this magnitude of change, but it would reduce the complexity.
> 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?
I think this is in reference to the next point that ESP without AH is more or less
useless. If you do ESP without AH you have to at least wrap the thing in an AH
tunnel. I might be stupid here but this is what I remember. Ran, do you recall
what we decided here? You came up with the proposed solution to this problem
if I recall correctly, and at the time it struck me as very well put and spot on.
> 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?
Not negotiated, always sent, regardless of use. Since we
require the packet to have some sort of integrity (tunnel or otherwise)
there is no sense in not sending the replay field.
> 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.
IV is specific to the algorithm correct, and your last assumption
about moving the IV into the payload field is also correct. This comment had
a lot to do with the Hughes transform. We decided to bag the fixed IV you get
from key mangling that Hughes originally did. And because of other changes
to the format, fixed IV's in this context are now deemed very bad. Therefore,
for what was Hughes, we decided to always send the IV.
Somone correct me if I blew it on any of these questions
-Rob
Follow-Ups: