> > what's the point of this exercise?
>
> To try and minimize the damage NATs cause
Well, as far as I can tell, you're not doing that to any significant
degree.
> > to encourage predictable behavior that applications cannot use?
>
> The functionaly here defined here allow two hosts behind tw
On May 18, 2006, at 7:44 PM, Keith Moore wrote:
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 bee
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.
what's the
On May 15, 2006, at 6:23 PM, Sam Hartman wrote:
"Keith" == Keith Moore 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
> On the other hand, there is a proposed WG (they had a BoF at the last
> IETF) -- NEA (Network End-point Assessment) which aims to do
> something about this space.
>
> I'd recommend folks interested in it go take a look:
>
>http://www1.ietf.org/mailman/listinfo/nea
Perhaps this is the solu
ts and management [RE: Last
> Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP
> (draft-ietf-behave-nat-udp)]
>
> On Mon, 15 May 2006, Hallam-Baker, Phillip wrote:
> >> From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED]
> >
> >> Sure
On Mon, 15 May 2006, Hallam-Baker, Phillip wrote:
From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED]
Sure. But a policy enforcement point must necessarily be
configured; otherwise, how is it going to know what policy to enforce?
The policy can be generated automatically from the network
con
> From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED]
> Sure. But a policy enforcement point must necessarily be
> configured; otherwise, how is it going to know what policy to enforce?
The policy can be generated automatically from the network configuration and
the authorized hosts and appli
On Monday, May 15, 2006 12:07:09 PM -0700 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> wrote:
I agree that separating out the NAT and firewall functions is useful and
necessary. Even if the two functions are performed by the same box they
should be considered separately.
I don't think that t
I agree that separating out the NAT and firewall functions is useful and
necessary. Even if the two functions are performed by the same box they
should be considered separately.
I don't think that the idea of zero configuration firewalls should be
dismissed. A firewall is simply a policy enforceme
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
manag
> "Keith" == Keith Moore 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 "
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.
Hi,
I had a flight so I read this. I think the document gives two very
bad pieces of advice: turn off all NAT ALGs and remove all NAT state
mapping filtering unless you require otherwise for security reasons.
Hence, I think wider IETF review seems warranted, and I'd encourage
more folks to
14 matches
Mail list logo
