Re: Comments on NAT RFC - 4787

On Feb 6, 2007, at 14:33, Darren Reed wrote:
>
> A new RFC has been published with requirements for NATs:
>
> http://www.rfc-editor.org/rfc/rfc4787.txt
>
> Which requirements do people think are important to IPFilter,
> where they actually apply?

I wish I had seen this RFC while it was still in draft form, and
while I could have argued with the authors about it.

p1. I think the recommendation in REQ-4 is a poor strategy for
solving the basic problem. Rather, NAT devices should just implement
a decent ALG for RTSP and RTP sessions. Anything less is really
silly, if you ask me.

p2. I think the requirement in REQ-7(1) is a bad idea, and I think
REQ-7(2) is fraught with ill-considered peril. I very much doubt
that REQ-7 will ever be met in practice with a reasonable
implementation of REQ-7(2), i.e. twice-NAT, and the requirement in
REQ-7(1) implies that the "internal" network (bad terminology there)
has to be renumbered whenever a change in the dynamically assigned
external addresses causes a conflict. I'm opposed to REQ-7
altogether, and I don't see it as a "best current practice" at all.
IPFilter should give it a raspberry.

p3. I think REQ-8 looks like the result of a typical IETF
clustergrope. A more sensible draft would simply say that filtering
and translation are orthogonal problems. I would have left out
section 5 altogether, and I'm disappointed that the IAB didn't react
to this language about "a more stringent filtering behavior" being
"most important" by whipping on its big, steel-toed jackboots and
curb-stomping its authors like narcs at a biker rally. Application
transparency is the only thing that's important in NAT behavior.
Full stop. Next question.

p4. I think REQ-9 is under-specified. It really needs explicit
language to require proper translation of ICMP error responses.

p5. I think REQ-10 is a joke^H^H^H^H great idea. Thank you for the
recommendations. I will bring them up in my next meeting with the
user interface specialists in our product design department. (Of
course, the issue is moot for IPFilter, which already complies.)

p6. I think there are several sections missing, that need to cover
what used to be called "basic NAT" translation, i.e. what IPFilter
does when you give it a BIMAP rule. It plays hell with "port
preservation" and makes "non-determinism" impossible in the presence
of "address-dependent" mapping to internal hosts that are not subject
to the "basic NAT" translation mapping.


--
james woodyatt <jhw@apple.com>
member of technical staff
apple computer, inc.