Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp)
On May 15, 2006, at 6:23 PM, Sam Hartman wrote:
"Keith" == Keith Moore <moore at cs.utk.edu> writes:
REQ-8: If application transparency is most important, it is
RECOMMENDED that a NAT have an "Endpoint independent filtering"
behavior. If a more stringent filtering behavior is most
important, it is RECOMMENDED that a NAT have an "Address
dependent filtering" behavior. a) The filtering behavior MAY
be an option configurable by the administrator of the NAT. ==>
I think this is WAY too dangerous approach. I'd say that the
filtering behaviour MUST be at least address dependent, unless
explicitly configured otherwise.
Keith> I'd strongly disagree with that. I'd say that NATs MUST
Keith> NOT have address dependent filtering unless configured
Keith> otherwise; and even then, filtering SHOULD be configurable
Keith> on a (destination) port-by-port basis. In other words,
Keith> transparency MUST be the default setting.
I have not yet read the document, but believe I understand the context
for this discussion point well enough to contribute.
I think that it is important to separate NAT from firewall
functionality. One device may provide both functions. But if the
intent is to provide only a NAT function,, then Keith is right and
transparency needs to be the default.
If the intent is to provide a firewall function then all the
manageability and configuration concerns of a firewall apply.
The intent was never to describe how to build a firewall or a NAT. It
was to provide a "safe harbor" of assumptions that an application
behind a NAT or firewall could assume "behave compliant" NATs or FWs
would provide. The BEHAVE WG has tried to find a balance between what
had a chance of deploying and what would be enough transparency to
allow some applications to work. Clearly more transparency would
allow more applications to wo9:29:22 -0700
In-Reply-To: <tsl7j4nw92n.fsf at cz.mit.edu>
References: <E1FdTQ1-0006S4-Gw at stiedprstage1.ietf.org>
<Pine.LNX.4.64.0605151333210.2911 at netcore.fi>
<44688C30.6070207 at cs.utk.edu> <tsl7j4nw92n.fsf at cz.mit.edu>
Mime-Version: 1.0 (Apple Message framework v750)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F0C84156-408E-485D-AE6D-6C9D389B444F at cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy at cisco.com>
Date: Thu, 18 May 2006 19:08:37 +0200
To: Sam Hartman <hartmans-ietf at mit.edu>
X-Mailer: Apple Mail (2.750)
X-OriginalArrivalTime: 19 May 2006 02:29:22.0676 (UTC)
FILETIME=[0A169340:01C67AEC]
DKIM-Signature: a=rsa-sha1; q=dns; l=3090; t=1148005763; x=1148869763;
c=relaxed/simple; s=sjdkim6001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=fluffy at cisco.com;
z=From:Cullen=20Jennings=20<fluffy at cisco.com>
|Subject:Re=3A=20Last=20Call=3A=20'NAT=20Behavioral=20Requirements=20for=20Unicas
t=20UDP'=20to=20BCP=20(draft-ietf-behave-nat-udp);
X=v=3Dcisco.com=3B=20h=3DCO1d2UwRqmUM50y5M+s++kySFBs=3D;
b=T8lxrsXrNBxYz4K0XSHM3u55Kfv+i0RP3Iw1yPZH7QL6r1Ao6GN7iGfIGk8Zvi3zFVnG4U6U
eITTudHnkOX+kkLFgmh9KdCM5ma091dLQ3gT/JTlDW86ypg7v0k4q5/3;
Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy at cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: iesg at ietf.org, Keith Moore <moore at cs.utk.edu>, ietf at ietf.org,
ietf-behave at list.sipfoundry.org, Pekka Savola <pekkas at netcore.fi>
Subject: Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP
(draft-ietf-behave-nat-udp)
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org
On May 15, 2006, at 6:23 PM, Sam Hartman wrote:
"Keith" == Keith Moore <moore at cs.utk.edu> writes:
REQ-8: If application transparency is most important, it is
RECOMMENDED that a NAT have an "Endpoint independent filtering"
behavior. If a more stringent filtering behavior is most
important, it is RECOMMENDED that a NAT have an "Address
dependent filtering" behavior. a) The filtering behavior MAY
be an option configurable by the administrator of the NAT. ==>
I think this is WAY too dangerous approach. I'd say that the
filtering behaviour MUST be at least address dependent, unless
explicitly configured otherwise.
Keith> I'd strongly disagree with that. I'd say that NATs MUST
Keith> NOT have address dependent filtering unless configured
Keith> otherwise; and even then, filtering SHOULD be configurable
Keith> on a (destination) port-by-port basis. In other words,
Keith> transparency MUST be the default setting.
I have not yet read the document, but believe I understand the context
for this discussion point well enough to contribute.
I think that it is important to separate NAT from firewall
functionality. One device may provide both functions. But if the
intent is to provide only a NAT function,, then Keith is right and
transparency needs to be the default.
If the intent is to provide a firewall function then all the
manageability and configuration concerns of a firewall apply.
The intent was never to describe how to build a firewall or a NAT. It
was to provide a "safe harbor" of assumptions that an application
behind a NAT or firewall could assume "behave compliant" NATs or FWs
would provide. The BEHAVE WG has tried to find a balance between what
had a chance of deploying and what would be enough transparency to
allow some applications to work. Clearly more transparency would
allow more applications to work but not if it will never be deployed.
This particular item was discussed for a long time in the WG. The
bulk of the running code we have today does not provide "address
independent" mappings because of the associated security properties.
Manufactures are building boxes that are designed for to sit in
houses in front of windows machines run by technically
unsophisticated users. I don't know if these boxes are NATs,
Firewalls, or something else but no manufacture in their right mind
is going to ship these boxes with the default as address independent
mappings.
If we change this to "address independent", close to 100% of NATs
produced will be non behave compliant. At this point applications
will have nothing they can rely on and we will be at the same point
we are now and the BEHAVE WG will have been reduce to an irrelevant
waste of time.
I 100% agree that if we were advising people how to build NATs, we
would recommend "address independent", however this is not the
situation.
Cullen (with my individual contributor hat on)
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
rk but not if it will never be deployed.
This particular item was discussed for a long time in the WG. The
bulk of the running code we have today does not provide "address
independent" mappings because of the associated security properties.
Manufactures are building boxes that are designed for to sit in
houses in front of windows machines run by technically
unsophisticated users. I don't know if these boxes are NATs,
Firewalls, or something else but no manufacture in their right mind
is going to ship these boxes with the default as address independent
mappings.
If we change this to "address independent", close to 100% of NATs
produced will be non behave compliant. At this point applications
will have nothing they can rely on and we will be at the same point
we are now and the BEHAVE WG will have been reduce to an irrelevant
waste of time.
I 100% agree that if we were advising people how to build NATs, we
would recommend "address independent", however this is not the
situation.
Cullen (with my individual contributor hat on)
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
