[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AH and ESP Orthogonality
Bill,
Some refinements on our dicussion:
>I understand. You raised this last year. But, other analysts prefered
>the AH "inside" ESP approach. So, there was no agreement. Instead,
>a flexible mechanism was defined, and the orthogonality allowed both
>approaches.
>
>Indeed, the chairs dictated to Jim Hughes in his DES+MD5 draft that the
>MD5 apply to the "inside" plaintext, rather than the "outside"
>ciphertext. There were objections raised from the WG, such as Karn.
>Outside allows detection of modification sooner, rather than after DES.
AH applied to the whole datagram is useful and a necessary facility,
whether provided by the current form of AH or some other header. However,
the inside version of AH, applying only to upperlayer protocols, is
redundant if one defines ESP transforms that provide the same features.
That is why I would suggest that we redefine AH (or define another header)
that has one, well-defined scope.
>> It might be preferable if ESP defined
>> optional, variable length fields for carrying the necessary data to support
>> confidentiality and authentication and integrity. The specific fields used
>> for a given SA would be defined at SA establishment, nailing this down for
>> efficient per-packet processing. The result would be to make transform
>> definition documents more modular.
>>
>The result would be to make the transform documents much more difficult
>to understand and implement. The WG rejected the variable fields
>approach yet _again_ last week.
>
>Instead, we nail down the specific _transforms_ at SA establishment.
>
>Same result, easier to implement, easier to verify.
I don't agree with your characterization of the tradeoffs here. One header
that permitted various combinations of security services, would be more
complex than our existing headers and an individual transform such as
single DES with 64-bit IV. However, as more transforms are added, each one
tends to duplicate significant pieces of previously defined transforms.
Moreover, when the transform includes not just one algorithm, but a
combination of algorithms (e.g., DES and MD5) and algorithm parameters, the
resulting set of documents gets pretty big in a hurry. general
interoperability requires either that everyone uses just the default
transform, or that all implementations support many transforms, many with
very small differences from one another.
It isn't clear to me that there are significant differences in supporting
various transforms (as currently defined) vs. supporting a single header
type with optional, discretely variable length fields. An implementor
still has to deal with some default subset of algorithms and combinations,
and then decide what optional ones also will be supported. I'd like to
think that the result would be better modularity in the transform
definitions, although you clearly believe that the opposite will result. I
guess those who would like to see this approach will have to try to write
the appropriate documents to see how it works out.
As for the cited message from Ran re the Photuris spec, I'm not sure I can
distinguish between criticism directed at those documents and the more
general issue of inclusion of anti-replay features in IPSEC.
Steve