Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard

["Howard C. Berkowitz" <hcb at clark.net>]

At 10:02 -0500 3/31/98, Perry E. Metzger wrote:
>"Howard C. Berkowitz" writes:
>> At 9:02 -0500 3/31/98, Perry E. Metzger wrote:
>> >"Howard C. Berkowitz" writes:
>> >> I may have missed a writeup that already exists,
>> >
>> >Such as the documents we are discussing, yes....
>>
>> You mean obscure things like draft-ietf-ipsec-arch-sec-04.txt?
>
>If you think that internet drafts are obscure, might I respectfully
>suggest that you familiarize yourself with the mechanism, as it is a
>basic requirement for functioning in the IETF environment?

Apparently the sarcasm mode was missed.  I am quite familiar with the
process, and have authored and coauthored both current I-D's and RFCs.
>
>> I recognize there are other working documents, but this is Last Call
>> for a specific one,
>
>If you are not aware of the other ipsec docs, all of which are named
>consistantly, with draft-ietf-ipsec prefixes, to make them easy to
>find in the internet drafts directory, might I suggest that you
>familiarize yourself with them?

That is not my point.  This is a last call for a specific document, an
architectural one.  As I read the current version of that document, it does
not reference some ongoing work, nor does it deal with certain issues
raised in the last call discussion and elsewhere.  The purpose of an
architectural document is to map requirements into system components.

I am aware that the directory you cite include discussions of the
cryptographic protocols of primary interest to code implementers.  Detailed
knowledge of all of these is not critical when analyzing architecture.
Reading knowledge of other IPSEC documents is relevant; a professional
knows that some selectivity is in order.

Unfortunately, my initial phrasing of my concerns in a more subtle manner
apparently went over Mr. Metzger's head, and he chose the opportunity to
patronize.  I shall not engage in further childish discussion as whether I
do or do not understand the IETF process to which I have contributed.

Stating things more succinctly, I think the architecture document,
specifically, does not either discuss proxy vs. end-to-end functions in the
context of risk analysis, nor does it reference a document that does.
There have been strong arguments about the interactions of IPsec and
various proxy and proxy-like functions, including NAT, satellite spoofing,
firewalls, etc.  Perhaps some guidance from the IESG or IAB is in order,
clarifying how the IETF will build consensus on the interaction of these
security and infrastructure technologies. Specific commentary on the effect
of widespread IPsec deployment on the demand for globally routable IPv4
space, under various scenarios of IPsec tunneling, should be considered.