[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: going forward
Bill,
This correspondence is getting us nowhere, Bill. I'll attempt
to respond to your most recent message, but with great trepidation.
>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.
Now, Bill, we both know that I was active in the initial IPSP
discussions, over the past 2 years, both at IETF meetings and on the
mail list. Unfortunately, my time was devoted to other activities
(for those of us who are not independent consultants, others have some
say over how we spend our time) during the last phases of the work,
which resulted in the final round of I-Ds and then the RFCs. Thus my
comments are in the context of the last phases of this work, something
I think you really do recall.
>Because there aren't two data regions.
...
>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.
Your characterization is what is covered by AH exactly matches my
interpretation, and it sure sounds like two different sets of data
being covered, depending on context. The suggestion I made was to
make the definition of AH more consistent by not requiring its use
within ESP when what is encapsulated is only ULP, not a whole
datagram. This suggestion does not conflcit with any of the scenarios
you, or others, have put forth, and other contributors to the list
have made similar arguments.
>Which I find truly amazing, after 2 internal last calls, and an IESG
>last call, too.
Well, Bill, as I said earlier, some of us have bosses who like to
believe that they get to set priorities for what we do. I may be old
fashioned in this, but since they pay me for my time, I tend to agree
with this basic philosophy. So, my comments were late, as I admitted.
>Ahem. Implementation got them done. Years of analysis did not.
I didn't realize that implementation got the specs done; I thought it
was mostly the work of people like Ran and Perry who took the time to
sit down and do the writing, trying to codify the discussions from the
WG meetings and the mail list. I don't mean to minimize the important
contributions made by implementation experience, but it should be
viewed in perspective.
For exaple, I recall that Phil Karn, as an early implementor of a
precursor protocol, came to one WG meeting and noted the substantial
performance impact he encountered as a dialup user. The reason for
the impact was pretty obvious, i.e., with encryption enabled the link
layer compression provided by the modem was defeated. This was not a
result that required implementation experience to predict, and I hear
folks still arguing for inclusion of compression as an option in ESP
to help counteract this throughly predictable effect. However, the WG
has not chosen to include that facility in the specs, despite the
early implementation experience.
>If I seem hostile on this topic, that's because I am!
I don't interpret your comments as being hostile, Bill, just in
character.
Steve