[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Death to AH (was Re: SA identification)
Peter,
><snip>
>
>The issues I brought up against AH were based on several issues:
>
>AH is/was fully redundant, and therefore did nothing but bloat the size
>of an "IPSEC compliant" piece of software and hardware. There were
>Silicon vendors who told us that the combination of AH and other
>enveloping (ESP-NULL, tunneling, etc.) would blow the computational and
>datapipe budgets they had in their designs. One large silicon vendor
>asked us to consider not supporting AH in combination with other IPSEC
>and tunneling configurations. Lastly, AH would confuse the "best
>common practice" of deploying IPSEC - do you use AH or ESP with NULL
>crypto or .... Extending ESP was a superior way to address the
>requirements presented in the course of IPSEC development.
AH is not fully redundant. It is fair to say that one can achieve
ALMOST ALL the features of AH through the use of tunnel mode ESP,
sans encryption, but the two are not exactly equivalent. Presumably
the argument we've having now is determining whether the situations
where AH offers unique services warrant keeping it as part of the
IPsec suite, in a mandatory capacity.
Your reference to the difficulty chip vendors envisioned in
supporting AH seemed to be a major motivation for the argument you
put forth, and that's an understandable concern. However, the IETF,
for better or worse, has usually not deferred to hardware vendor
concerns about implementation issues, relying on Moore's law to
address these issues over time. Instead, we often focus on software
implementation issues.
I don't understand the reference to "best common practice .." above.
Extending ESP was never seriously considered. No I-Ds on the topic
were ever published. There was considerable sentiment that making one
protocol (ESP) more complex as a means to avoid the need to implement
another protocol (AH) was not going to result in an overall simpler
system. I think this sentiment is accurate and persists today.
>
>The arguments for AH:
>
>I) the document was already written and we are in a hurry because IPSEC
>can not happen until docs went to PS
I believe the IETF meeting I referred to took place well before we
submitted 2401 as an RFC, so this argument seems a bit out of sync.
>II)there are existing/working implementations
true
>III) and my favorite - and I paraphrase - this AH issue was already
>discussed, and most experts agree that AH was something akin to
>unnecessary/botch/etc., but since the pesky critter was still in the doc
>we needed to move on. It could be fixed at DS or later.
I don't recall that.
>IV) AH was the way to say "no data encryption in this packet" to comply
>with crypto wary governments.
Still true, but given the IAB position on crypto, not a good rationale.
>
>Jeff Schiller asked me if we/they left AH in the arch doc would
>Microsoft build versions of IPSEC without AH? To which I noted that
>this was not a proper question for a standards meeting and that for PC
>and Server implementations this was less of an issue, but for small
>devices (which MS also builds for) it could become a large issue.
Unfortunately, my cursory examination of the MS implementation of
IPsec for PCs and servers last May revealed that it is not compliant
with 2401 anyway, e.g., it fails to provide a means for a user or
administrator to order the SPD entries, a very explicit requirement.
the lack of this facility makes it hard, if not impossible, for one
to determine how the implementation will process traffic.
Steve
References: