[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: notes from developer's portion of IETF meeting
Bill,
NIce to hear from you again. Here are some responses to your comments:
>> 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.
>(analysis omitted)
>> 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.
>>
>The verbal rationale that I remember was that the main use of AH would
>be for the tunnelling gateways that Moskowitz diagrammed, where you need
>to authenticate the IP addresses of the routers. This keeps the tunnel
>down to a single tunnel across the net. I remember Richardson giving us
>the same (single tunnel level) recommendation over a year ago.
It's good to see an exmaple of the rationale behind the proposal. In
general, if I am tunneling traffic between two security gateways, why do I
need to protect the outer IP header? Would I not generally discard it upon
arrival? The inner IP header is the real focus of protection. There is no
reason why I cannot multiplex the same scope of traffic in a tunnel with
ESP as I can with an AH tunnel, so I don't view that as a differentiator.
>The orthogonal use of AH provides function that would not be available
>with ESP alone.
>
>And, it _also_ reduces complexity in implementation of ESP. You are
>correct, the implementors seemed quite taken with that idea.... :-)
>
>No rationale was given for the practical need for authentication-only
>ESP, and thus it was not chosen as an option. Is there any reason other
>than the minor performance gain that you mention, that cannot be handled
>by AH as it stands?
I guess I look at the question from the opposite perspective: if all I need
is provided by an authentication-only ESP, why pay any additional
performance penalty by requiring AH? I remember when ESP had no
authentication transforms and one had to use AH in conjunction with ESP to
achieve both sets of services. I was among those who argued for
autehntication/integrity features for ESP precisely to avoid the overhead
of using AH. I like the logical completeness of having ESP be modular,
allowing selected subsets of security services to be applied to payloads in
a clean, encapsulated fashion.
>> 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.
>
>Here, the notes are simply wrong (by omission). The group agreed that
>ESP encryption without integrity needs an external AH _only_ where
>required for security!
>
>You are correct, and was elaborated by Bellovin's paper long ago, there
>are many instances where extra authentication for integrity is not
>required.
>
>As I recall, integrity is required for security _only_ when there are
>mutually hostile users on multi-user systems at both ends of the
>connection/path. These multi-user systems "know" that they require
>integrity, and can negotiate it appropriately.
>
>OTOH, a dialup user encrypting to a firewall (or even their target
>multi-user host) from a laptop would _not_ require added integrity. Big
>interactive RTT savings on a low speed link.
Glad to see we agree here!
>> 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.
>>
>Could you put that in the architecture for posterity?
Yes, I'll make sure that the architecture document captures the rationale
that motivates the various combinations of AH and ESP use, etc.
>> 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.
>>
>Could you cite all of the above in the architecture for posterity?
If we decide to mandate inclusion of the AR counter, then rest assured that
the AH and ESP documents will cite the rationale for this, since inclusion
of a field that might not be used by the receiver demands an explanation!
>I will note that there were questions raised by several in the room
>about mandating the field in AH, as this would be a change in bits on
>the wire for older implementations. Perhaps someone could post their
>arguments here for the rest of the group.
>
>I don't think we had agreement on AH. Just ESP.
I'm asking these questions precisely to clairfy the minutes and make sure
that the WG as a whole, not just those attending the most recent meeting,
understand what is being proposed and why.
>> 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.
>>
>Yes, that was my understanding of the agreement; please put that
>rationale in the ESP document.
Will do.
References: