[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
going forward
> From: Steve Kent <kent@BBN.COM>
> ... written swipe I-D, ... verbal presentations ...
> people may reasonably support or reject the proposal based not just on
> the mechanism but also on the rationale provided.
>
Fine, at least you belatedly came to the same conclusion. I simply read
the I-D, and what they wrote made sense to me. Some people just take
more lengthy explainations.
> This would suggest that the data covered by the AH differs, depending
> on where AH appears.
Of course. This was discussed at some length, on several lists. Very
clean approach, easily implementable. Sorry you missed it before.
Water under the bridge.
> It is also confusing that this discussion of
> what data is covered by AH appears not in the AH spec, or in the
> architecture spec, but in the ESP spec.
Yeah, architecture would have been better. Draft Standard would be a
good time to raise this issue again.
> I'd like to see us evolve the
> specs to remove this dual mode usage of AH and focus,
Let's not. Complicates the protocol. Headers should just be processed
as they come.
> instead on
> providing (optional) integrity and authenticity services within ESP.
>
This WG went down that all-things-to-all-people rat-hole for 3 years.
Waste of time. We've made our decisions. Unless there is a
demonstrable security hole, impossible to fix with a simple
implementation note, let's move on.
And how is _your_ AH and ESP implementation coming?
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: