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

RE: notes from developer's portion of IETF meeting

ROb,

	Thanks for the responses.  Let me see if I can follow through on
your comments to help close the loop on these matters:

>>	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.

Use of AH is not the same as use of ESP w/o encryption, precisely because
of the coverage issue, and the associated performance hit.  Remember that
to compute AH , one must perform the logical equivalent of copying the IP
header (and all options) over to a new buffer, then zeroing each header
field that is always excluded, then examine every option to see if it is
included or excluded.  For IPv6, with more header extentions/options/etc.
this might be come a more time consuming task.  My guess is that use of ESP
in tunnel mode will be popular, with one end of the SA at a firewall.
Under those circumstances, AH in tunnel mode does not buy one much, because
the outer header is not very interesting, i.e., it will be discarded.
(Only rarely would it make sense to copy portions of it into an inner
header.)  Thus tunnel mode ESP would provide suitable protection for
traffic with greater efficiency and less per-packet overhead. What I'm
hearing from this discussion is that the motivation for not offering ESP
w/o encryption is added complexity.  I'm all in favor of reducing
complexity, if it doesn't cost functionality, but I'm really surprized to
hear that offering ESP w/o encryption is percieved as a significant
increase in 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.

I assume you meat to say that ESP with authentication was useless, but I
have to disagree.  I know folks who are sending packet voice and packet
video on an end-to-end basis.  I recommend use of ESP w/o authentication in
this context.  With an appropriate encryption mode (such as CBC), the
nature of the application makes it unlikely that one can twiddle bits in an
effective manner, given use of a suitable encryption mode (e.g., CBC).
Also, since people are the consumers of this data, we can rely on them to
discard obviously errored traffic.  Reordering and replay will be detected
by the builtin timestamp facility.   However, per-packet overhead is a big
concern here and thus stripping out everyting but the encryption support is
an important feature.  Thus the flexibility offered by modular use of ESP
and AH is important to these folks and is in keeping with the original
intent of IPSEC.

>>	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.

I sent a separate message arguing for why I'd like to be able to negotiate
use of AR for eithe protocol, although I can see merit to adopting a
default window size of 32 to minimize the need for negotiating a window
size.  However, the comment about "no sense in not sending the replay"
counter since integrity is always rerquired puzzles me. As noted above, I
can cite real applications where encryption w/o authenitcation is
appropriate.  Sending it takes up space that may be critical to such
applications, especially when it's not going to be used.

I think the better argument is that AR counter inclusion makes alignment
"work" for AH in the IPv6 context, and in ESP this inclusion aligns the
start of the payload (assuming that we fold the IV into the payload) on an
8-byte boundary as well, to facilitate crypto processing.  Also, by always
sending this field, one simplifies packet parsing, by eliminating
variability.  If these are the reasons for mandating inclusion of the AR
counter in every AH and ESP packet, then so be it, but at least lets agree
on a rationale that makes it clear what tradeoffs were considered in coming
to this conclusion.  Also, even if we do include it in every packet, for
these alignment and parsing reasons, whether we negotiate use of the 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.

This clarifies the last comment.  In general I propose that we remove the
IV as an explcit, optional field and fold it into the beginning of the
payload.  The text will be modified to state this convention, noting that
each algorithm document must state the presence/absence of an IV (or a
sequence space pointer for some types of stream ciphers) and the size of
the IV.  That way we can keep the ESP document simple and algorithm
independent.

Steve
Follow-Ups: References: