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

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 31 Mar 1998 09:51:59 -0500 (EST)

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?  I recognize
there are other working documents, but this is Last Call for a specific
one, which doesn't appear to reference certain issues.  Issues about which
prominent members of the community are extremely vocal -- well, more vocal
than usual :-)
>
>> but the two quotes below add to my feeling there needs to be a clear
>> architectural discussion of:
>
>The issues you raise are discussed in the documents. Please read them.
>
>Perry

Yes:  such as

>.  This document does not address all aspects of IPsec
>   architecture.  Subsequent documents will address additional
>   architectural details of a more advanced nature, e.g., use of IPsec
>   in NAT environments and more complete support for IP multicast

NAT and routing are more my areas than the satellite issues.  Nevertheles,
in an architecture document, I would like more meat that a "To be
addressed."  I'd like an initial statement of problems in the interctions
between NAT/firewalls and IPsec, with emphasis on vulnerability.  Sandy
Murphy;s BGP Security Analysis is the sort of document I have in mind.  The
architecture document doesn't need to contain this, but there should be a
reasonable pointer, which I don't see.  The emphasis is on the protocols
and protocol entities rather than their deployment.

Howar

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 31 Mar 1998 14:07:09 -0500 (EST)

At 10:02 -0500 3/31/98, Perry E. Metzger wrote:
>> 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.

---

From: "C. Harald Koch" <[email-masked]>
Date: Tue, 31 Mar 1998 14:46:25 -0500

> space, under various scenarios of IPsec tunneling, should be considered.

None of these were in the Charter for the IPsec working group. This was
deliberate; they're hard problems.

Many of them are (or will be) in the Charter for the IPsecond working group,
and I'm sure we'd love to have you participate in those discussions.

There's precedent for splitting work like this, after all. We're up to RIPv2,
SNMPv3, and BGPv4 right now, after all.

-- 
Harald

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 31 Mar 1998 15:06:17 -0500 (EST)

>deliberate; they're hard problems.

I can get along with stating thing in those terms, although I would suggest
that this conscious limiting doesn't come across in the architecture
document.  Again, my concern is that the enterprise network architect
realistically is not going to go back to the charter.  If things are
consciously out of scope, a pointer to that would help enormously in
getting deployed.

Your points are well taken and my comments are meant to be supportive of
the overall effort.  I do in fact monitor IPsec drafts, but, I think
realistically as do many others, I actively comment in only a certain
subset of the WGs. If something reaches last call, and especially if it is
impacting other areas of work, it seems appropriate to me to try to build
consensus and clarity.  That is the point of my comments, I want the work
to be used.  I don't want to see things happen such as people coming into
NAT, etc., and saying "you can't do this because it breaks IPsec."
>and I'm sure we'd love to have you participate in those discussions.

I'd be happy to do so, especially within my area of specialization, which
is more routing and addressing.  I fully recognize the need to limit the
scope of work in order to get things done.
>SNMPv3, and BGPv4 right now, after all.

Given the IPsecond effort is being formed, does it make sense to identify
the current document as IPsec V1?  Seriously, I think that would help among
nonspecialists.

Your comments are valid, and I hope mine are taken in the constructive way
they are meant.  I've killfiled Mr. Metzger.

Howard