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

"Howard C. Berkowitz" <hcb@clark.net> Tue, 31 March 1998 15:00 UTC

Delivery-Date: Tue, 31 Mar 1998 10:05:37 -0500
Return-Path: cclark
Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id KAA00394 for ietf-outbound.10@ietf.org; Tue, 31 Mar 1998 10:00:03 -0500 (EST)
Received: from mail0.tor.acc.ca (mail0.tor.acc.ca [204.92.54.110]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA00317 for <ietf@ns.ietf.org>; Tue, 31 Mar 1998 09:52:34 -0500 (EST)
Received: from [142.154.136.3] (ppp-034.m4-1.cgy.ican.net [142.154.136.34]) by mail0.tor.acc.ca (8.8.8/8.8.8) with ESMTP id JAA29903; Tue, 31 Mar 1998 09:51:59 -0500 (EST)
Date: Tue, 31 Mar 1998 09:51:59 -0500
X-Sender: hcb@pop3.clark.net
Message-Id: <v03007807b1466a67057e@[142.154.136.3]>
In-Reply-To: <199803311402.JAA15841@jekyll.piermont.com>
References: Your message of "Tue, 31 Mar 1998 02:30:45 EST." <v03007802b146019564cb@[142.154.136.3]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: perry@piermont.com
From: "Howard C. Berkowitz" <hcb@clark.net>
Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
Cc: ietf@ns.ietf.org

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