Fact: There are NATs and stateful packet filtering firewalls that cause
problems for some applications.
It is quite likely that these devices will not go away.
Phillip also seems to have this view. I replied to him with regard to
the conclusion he draw. He seems to think that the right way to deal
with these boxes is to put application layer functionality on NATs (and
potentially firewalls as well).
I replied to his mail since I don't believe this is the right approach.
Instead, I believe that the current work on legacy NAT traversal is
already doing a good job. There is, however, room for improvement by
allowing the end host to interact with NATs and firewalls. Some folks
are working on this subject already for some time.
Does this make sense to you?
Ciao
Hannes
Iljitsch van Beijnum wrote:
On 13-jul-2007, at 22:11, Hannes Tschofenig wrote:
As Phillip stated, I don't see the problem with future applications.
Compare this with the security aspects that are taken care of much
more than before when developing new applications NAT traversal is
just another thing to think about as a protocol designer.
There is no magical "NAT traversal" switch that you can flip and your
protocol will work through NAT with no problems 100% of the time. Just
like there is no such switch for security.
Yes, there were (are?) protocols that were more NAT-unfriendly than
they needed to be, case in point FTP. I don't think the IETF creates
protocols that fail when used through a NAT when it's just as easy to
make the protocol work though the NAT as is the case with FTP.
However, the reason why MOST protocols/applications have trouble with
NAT is because they need to receive incoming sessions. Short of
rewriting the protocol to work over UDP or through a third-party
server, pretty much the only way to "traverse" NAT in these cases is
to go up to the NAT device, and ask it to open up a TCP port, pretty
please with a cherry on top?
This works well if:
- the NAT device is a fairly modern one created for a market where
this functionality is considered important (i.e., home users)
- the application or the OS implements the necessary open sesame logic
- there is a well-reachable server providing referrals
- there is only a single NAT between the outside and the host trying
to receive incoming TCP sessions
(There could be a firewall in the way, too, but that's not relevant
for this discussion.)
The first three are likely to get better in the future, but more than
one NAT is extremely likely to become more common as we run out of
IPv4 addresses. Note though that even with the above in place there
are still problems caused by NAT that can only be solved by additional
application logic or application layer gateways in the NAT. (The case
where multi-party referrals by IP address happen. Yes, by FQDN would
be better but not every host has a working DNS name.)
So whichever way you slice it, the best case scenario for NAT is that
it doesn't get in the way. The worst case is that it absolutely,
positively breaks your application despite huge amounts of NAT
workaround logic and a lot time spent debugging the problem. As with
most things in life, some people are lucky enough to live in a best
case world, others are prone to be bitten by the worst case more than
their fair share.
What I consider the most important problem with NATs is that they
don't fail gracefully. When a NAT gets in the way, the application
generally doesn't get to do what it wants to do, but without any
feedback as to why. This means the user doesn't know what the problem
is and doesn't have any clue about solving it. It's like a world where
rather than giving you warnings or tickets, police officers sneak up
on you from behind and knock you unconscious without you knowing why
if you break a traffic rule. It's painful and you don't understand why
it happens. Come to think of it, not unlike trying to send files or
videoconference using instant messaging with a NAT at both ends.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf