[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: going forward
> From: Steve Kent <kent@BBN.COM>
> It's good of you to be so polite in waiting for the rest of us
> to catch up,
I seem to remember that you are a former IAB member, and heavily
involved in internet security discussions. As a consequence, it rather
surprises me that you have any need to "catch up" on developments and
designs that are 3-5 years (or more) old.
> As for your comments re AH, you seem to have a short term
> memory problem. My message pointed out the two different data regions
> cofered by AH and your response was a resounding "huh?"
Because there aren't two data regions.
> So, I quoted
> the basis for my comment, only to have you respond with a "Oh, sure,
> what's wrong with that" rejoinder.
You quoted a part of the draft that requires the implementor to cover
the data that s/he has available, and is rather more explicit than usual
about what that data needs to be.
If the AH follows an IP header, wherever the IP header happens to be
(inside or outside ESP), it covers the IP header and any other
subsequent headers, too.
If the AH follows an ESP header, it covers the data _inside_ the ESP
header. The ESP payload is "opaque". Pretty damn difficult to mandate
covering an IP header when there isn't one visible.... Particularly
when there was possibly a hardware encryption engine between you and the
interface.
So, we have a push from you to cover non-existant IP headers, and a pull
from others to _not_ cover IP headers at all. I think Ran (with "a
little help from his friends") made an excellent engineering tradeoff
there. Cover all the information you have which is carried end-to-end.
> While you are right that it would have been preferable to make a
> chaneg like this prior to publication of the RFCs, my comments one the
> I-Ds arrived about a week too late for that.
>
Which I find truly amazing, after 2 internal last calls, and an IESG
last call, too.
> As for my the progress of "my" implementation, well, I don't
> write code so there is no progress to report on that front. I'm one
> of the folks who still believes that its better to analyze the specs
> and get them right, using implementation experience to refine them,
> rather than letting implementation experience drive the specs. So,
> each of us has a way to contribute to the specification process.
>
Ahem. Implementation got them done. Years of analysis did not.
If I seem hostile on this topic, that's because I am!
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2