Jonathan Rosenberg wrote:
...
I agree that ALGs are not the answer, and I believe the reasons for that
are treated in:
http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-
considerations-00.txt
I have a fundamental problem with an IAB document that implies NAT provides
a firewall. The artifact of lack of state is exploited to prevent inbound
connections, but that has nothing to do with a policy rich firewall, and
even less to do with anything resembling 'security'.
As I said in an earlier post, the entire focus of this document is the wrong
direction for the IAB. It should be focused on simplifying application
operation, so there should be no NAT in the title. The IAB should be looking
at how applications can avoid worrying about the convolution in the network,
not focusing on how to navigate it.
It is also broken in that it focuses on Client/Server application models,
which are generally less of an issue for applications in a NAT environment.
Peer-to-peer applications have more trouble with mangled headers so the
second thing to do (after changing the title & focus) is to rework this so
that P2P issues are up front.
As I mentioned during the plenary, the document above makes a case that
the right answer in many situations are vpn-ish technologies that
include v6 tunnels. However, different applications have different
needs, and there are real differences between the various vpn-ish
solutions (TURN, STUN, teredo, etc.) that are driving their development
and adoption. For VoIP, where the nat traversal issue has been
especially painful, the increase in voice latency, packet loss, and
substantial cost increase of relaying traffic through the tunnel
servers, has driven people to solutions like STUN. Thus, I cannot agree
that there only needs to be a single solution here.
You appear to be too focused on the weeds to notice the path forward. Yes
many of the IPv6 transition technologies have the same issues as the NAT
traversal technologies in IPv4 (in many cases they do exactly the same thing
but with different encapsulated packets). That said if the applications
community doesn't get the point that they can leave all that crap behind
when native IPv6 is available to them then they will never move. If the
applications community doesn't do their part we will always be stuck with
the garbage in the network.
That said, I agree that the IAB nat traversal consideration document
lacks adequate consideration of how evolution plays into this, and I'll
endeavor to improve the document on that front.
I will try to send text, but I am buried for the next couple of months.
Another concern I have is that, in an IPv6-only world, even if you
eliminate NAT, there will still be firewalls, and those firewalls will
frequently have the property that they block traffic coming from the
outside to a particular IP/port on the inside unless an outbound packet
has been generated from the inside from that IP/port.
There is work going on outside the IETF to deal with this issue. There is no
point in wasting years arguing when progress can be made in the real world.
This means that IP
addresses are not globally reachable. You'd still need most of the same
solutions we have on the table today to deal with this problem.
Not necessarily.
Indeed,
in the VoIP space, I believe you'd need pretty much everything,
excepting you'd be able to remove a single attribute from a few of the
protocols (STUN and TURN in particular), which tell the endpoint its
address on the other side of the NAT. The endpoint knows its address,
but all of the protocol machinery is still needed to rendezvous with the
other participant in the call.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711
Cisco Systems
jdrosen(_at_)cisco(_dot_)com FAX: (973)
952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf