[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AH and ESP Orthogonality
> From: Stephen Kent <kent@bbn.com>
> Having orthogonal transformations was not necessarily a bad idea,
> but there are benefits to having a better division of responsibility
> between AH and ESP.
I agree.
> For example, the current definition of AH is messy
> because either AH covers the entirity of an IP datagram (minus mutuable IP
> header fields) or it covers just upper layer protocols. The distinction is
> a function of where AH appears relative to ESP. Several of us would prefer
> a verison of AH that applied to the whole datagram (as described above),
> period.
>
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.
As you may remember, I'm an "outy" myself.
> 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.
> Several folks, including yours truly, have expressed a desire to
> add an anti-replay feature into the IPSEC suite. This could be useful in
> either AH or ESP, or both.
I'm included in that "several folks". We discussed this last year, and
again in January of this year. It's in our latest ESP revision, and in
Photuris Extensions. But, as you may remember Atkinson's message:
Date: Thu, 22 Feb 1996 12:29:13 -0800
Message-Id: <199602222029.MAA00276@puli.cisco.com>
5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted.
It is WAY outside the scope of Bill's draft to modify any standards
track protocol and the attempt to do so is more than sufficient grounds
to bar publication as ANY kind of RFC until that section is deleted.
So, the chairs are rather vehemently against adding replay protection,
even as a negotiated option.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: