On 2009-11-10 04:11, Chris Engel wrote:
> On Friday, November 06, 2009 6:37 PM, Brian E Carpenter wrote:
>
> "We worked as hard as we could to make the list complete.Can you identify
> exactly which benefits of NAT are not mentioned in section 2 of the document?"
>
>
> On Mon 11/9/2009 7:27 AM, Eric Klein wrote:
>
> "As one of the co-authors of RFC 4864 I would be interested if you could
> itemize that you mean by:"
>
>
>
>
> Eric & Brian, I was under the impression that I had done just that with my
> origional post to the list. Let me provide the relavent excerpt. It contains
> 2 very specific examples (there are more areas, but these 2 really stand out).
Thanks. There are too many words in my unread mail just before an
IETF to pick up everything...
> 1) NAT allows a firewall to "fail closed" rather then "fail open" when there
> is a miscofiguration of rules.
I know of nothing that stops firewalls being shipped with "default deny". In
fact,
that's how my preferred personal firewall is, and I have no hesitation about
connecting to raw Internet as a result.
>
> 2) NAT serves to abstract internal hardware that provides services from the
> external advertisement of those services. Making it very easy and flexible to
> distribute and redistribute the provision of those services among your
> internal hardware.
I though we covered that, though not in those words. Certainly topology hiding,
one of the areas we discuss at some length,is a big part of that (and is part
of the gap analysis, so we tend to agree that is a weaker area).
Also of course ULAs are specifically designed to "abstract internal hardware
that provides services from the external advertisement".
...
> Another very important utility of NAT that I did not see addressed at all in
> RFC 4864 is to abstract the internal hardware that provides a given external
> service from the connection information provided externally for that service.
...
ULAs do that.
...
> "PCI-DSS v1.2 Requirement 1.3.8 - "Implement IP masquerading to prevent
> internal addresses from being translated and revealed on the Internet, using
> RFC 1918 address space. Use network address translation (NAT)
> technologies-for example, port address translation (PAT)."
That's just another expression of topology hiding, see above.
>
>
> It seems that the prime arguements against NAT are...
>
> 1) That it breaks certain applications/protocols.... but if the orginization
> that is deploying NAT has no need or desire to allow those particular
> applications/protocols to traverse thier network boundary anyways, I fail to
> see the harm being done there.
The harm is generic harm to innovation and applications architecture.
The prime example today is the grotesque things that VoIP protocol
designers have been forced to do.
> 2) That when the device implimenting it runs out of resources it aborts user
> sessions.... but I fail to see how this is any different then any device in
> the chain of services running out of resources
...
Mainly because the problems are totally undiagnosable, especially for
the typical home user/help desk combination. And should we really be
pushing technology that we know to be unreliable? As an engineer, that's
actually a violation of my professional ethics.
Enough. Maybe we can get back to honing the NAT66 draft...
Brian
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
