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]

 




On May 15, 2006, at 6:23 PM, Sam Hartman wrote:

"Keith" == Keith Moore <moore@xxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]