[arin-ppml] IPv6 Non-connected networks
owen at delong.com
Fri Mar 26 13:54:22 EDT 2010
On Mar 26, 2010, at 10:29 AM, Roger Marquis wrote:
> On Fri, 26 Mar 2010, Owen DeLong wrote:
>>> Are you assuming consumers will simply open up their firewalls and
>>> (your) protocols through without inspection, were NAT out of the
>>> way? I
>>> just don't see end users giving SRTP or any other protocol a free
>>> regardless of firewall gear, regardless of NAT. Also doubt that the
>>> alternative packet inspecting and/or other ACLs would be simpler
>> I'm certainly making no such assumption, but, yes, the other packet
>> things are vastly superior to NAT in at least the following ways:
>> 1. Deterministic, predictable troubleshooting
OK... To be more specific:
There are three possible scenarios for IP communication:
Both ends have public IP addresses
This is easy. You know what address means what.
One end is NATted, the other has a public IP address
This is relatively easy to troubleshoot from the NATted end most of
the time, IF you have access to the NAT state table. It can be a real
pain if you are a host administrator and do not have access to the
NAT state table because you cannot easily predict what your packets
will look like to the remote side.
It is almost always problematic to troubleshoot from the public
IP side of the equation because you are usually dealing with a
user who can't even spell NAT trying to figure out why their
ability to use your service is broken, and, they can't tell you
enough about their connection to allow you to even find the
packets they are sending you for examination.
Both ends are NATted
Combine the worst aspects of both of the previous two paragraphs
through a multiplicative operation.
>> 2. They don't require heroic measures in the software to work around
>> the damage introduced by your stateful inspection. Stateful
>> inspection only breaks what it intends to break. NAT breaks all
>> kinds of things whether the administrator wants to allow them
>> or not.
STUN, SNAT, UPNP, and a myriad of other often poorly implemented
incompatible and unreliable NAT traversal mechnisms, Application
layer Gateways, etc.
> Your assertions are vague and general Owen, and not in agreement
> with my
> experience. Exactly what step of RTP/SRTP stateful inspection is
> without NAT?
The stateful inspection is neither easier, nor, more difficult.
However, at the far end when I'm trying to figure out why something
work, any of the following behaviors related to NAT make things more
difficult to debug:
1. RTP packet sourced from 10.x not translated and dropped by outbound
firewall because outbound firewall doesn't handle SIP/RTP well.
2. RTP packet sourced from 10.x leaks onto network and gets dropped
(1 and 2 mean I never see the RTP packet at my side, so, WTF? I have no
idea what happened to it and no easy way to know whether it's a NAT
issue or something else dropping my customer's traffic)
3. RTP packet sourced from 10.x gets a different NAT pool address
than the SIP session and/or STUN setup.
Now, RTP packet doesn't match expected source address for flow
at my end, but, god only knows why on my side. (And if you think
this isn't a real-world situation, think again... I once spent 3 hours
debugging a problem with RingCentral related to this where I was
stuck on the NATted side of the equation. I then spent another 3
days trying to explain the problem to the management. Instead
of resolving the NAT issue, they chose to cancel RingCentral.)
4. There are many many others, but, I think these three that come
to me off the top of my head from my own experience are
enough to make the point.
More information about the ARIN-PPML