RE: Why Scopes? (was: Re: [saad] About saad)

Erik Nordmark <Erik.Nordmark@sun.com> Tue, 21 October 2003 15:46 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24057 for <saad-archive@odin.ietf.org>; Tue, 21 Oct 2003 11:46:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByhw-0006rN-EM for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 11:46:04 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFk4am026363 for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 11:46:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByhw-0006r8-8m for saad-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 11:46:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24050 for <saad-web-archive@ietf.org>; Tue, 21 Oct 2003 11:45:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByhv-0005Eg-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 11:46:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AByhu-0005Ed-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 11:46:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByht-0006oW-B7; Tue, 21 Oct 2003 11:46:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByh9-0006dX-1v for saad@optimus.ietf.org; Tue, 21 Oct 2003 11:45:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24002 for <saad@ietf.org>; Tue, 21 Oct 2003 11:45:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByh7-0005Dj-00 for saad@ietf.org; Tue, 21 Oct 2003 11:45:13 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AByh6-0005Df-00 for saad@ietf.org; Tue, 21 Oct 2003 11:45:12 -0400
Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9LFZuPh019061; Tue, 21 Oct 2003 09:35:57 -0600 (MDT)
Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9LFZtS14516; Tue, 21 Oct 2003 17:35:55 +0200 (MEST)
Date: Tue, 21 Oct 2003 17:29:48 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: RE: Why Scopes? (was: Re: [saad] About saad)
To: Michel Py <michel@arneill-py.sacramento.ca.us>
Cc: Erik Nordmark <Erik.Nordmark@sun.com>, James Kempf <kempf@docomolabs-usa.com>, saad@ietf.org
In-Reply-To: "Your message with ID" <DD7FE473A8C3C245ADA2A2FE1709D90B06C69A@server2003.arneill-py.sacramento.ca.us>
Message-ID: <Roam.SIMC.2.0.6.1066750188.31182.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: saad-admin@ietf.org
Errors-To: saad-admin@ietf.org
X-BeenThere: saad@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/saad>, <mailto:saad-request@ietf.org?subject=unsubscribe>
List-Id: Scope Addressing Architecture Discussion <saad.ietf.org>
List-Post: <mailto:saad@ietf.org>
List-Help: <mailto:saad-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/saad>, <mailto:saad-request@ietf.org?subject=subscribe>

> Perhaps, but this is not typically what enterprises are interested in
> when they want scoping. The purpose of scoping is to make no
> communication possible, not egress-only (because egress-only could be
> used to create a tunnel).

Having a conceptual model with 3 top-level classes defined in the firewall 
 1. no communication through the firewall
 2. outbound only
 3. open
is simple enough to prevent unintended side-effects of other filters.

Then you can have the ability to further *restrict* the classes with more 
detailed rules (e.g. to restrict certain IP addresses in 2 to not allow
outbound for certain protocols and ports) but no ability to have rules which
are less restrictive that the basis for the class.

This is not rocket science - just sound conceptual models for a UI.

> Keep in mind that at times firewalls that do not NAT could be replaced
> by a cross-over cable (for short periods of time, in case of upgrades
> for example). I know, nobody is supposed to do that; nevertheless it is

And people rewire light switches at home without turning off the power too.
In many cases that works if you are careful, even though it isn't recommended
practise!
Point being that neither household electrical appliances nor the nationwide
electrical grid had any additional requirements placed upon it
to make it safer rewiring with the power on.
I don't think it makes sense placing additional requirements on
the Internet applications or the IP infrastructure to make firewall 
temporary replacement with a cross-over cable any safer either.

  Erik



_______________________________________________
Saad mailing list
Saad@ietf.org
https://www1.ietf.org/mailman/listinfo/saad