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

"C. Harald Koch" <chk@utcc.utoronto.ca> Tue, 31 March 1998 19:50 UTC

Delivery-Date: Tue, 31 Mar 1998 14:57:44 -0500
Return-Path: cclark
Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id OAA06128 for ietf-outbound.10@ietf.org; Tue, 31 Mar 1998 14:50:01 -0500 (EST)
Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA05902 for <ietf@ns.ietf.org>; Tue, 31 Mar 1998 14:46:37 -0500 (EST)
Received: by janus.tor.securecomputing.com id <11652>; Tue, 31 Mar 1998 14:47:36 -0500
Message-Id: <98Mar31.144736est.11652@janus.tor.securecomputing.com>
To: "Howard C. Berkowitz" <hcb@clark.net>
cc: perry@piermont.com, ietf@ns.ietf.org
Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
References: Your message of "Tue, 31 Mar 1998 09:51:59 EST." <v03007807b1466a67057e@[142.154.136.3]> <v0300780bb146a2d106bd@[142.154.136.3]>
In-reply-to: hcb's message of "Tue, 31 Mar 1998 14:07:09 -0500". <v0300780bb146a2d106bd@[142.154.136.3]>
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2; hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm; z:NJ7pss)l__Cw+.>xUJ) did@Pr9
Date: Tue, 31 Mar 1998 14:46:25 -0500

In message <v0300780bb146a2d106bd@[142.154.136.3]>, "Howard C. Berkowitz" writes:
> 
> 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.

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