[arin-ppml] IPv6 Non-connected networks

[Owen DeLong]

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  
>>> let
>>> (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  
>>> pass,
>>> regardless of firewall gear, regardless of NAT.  Also doubt that the
>>> alternative packet inspecting and/or other ACLs would be simpler  
>>> than
>>> NAT.
>>>
>> I'm certainly making no such assumption, but, yes, the other packet  
>> inspecting
>> 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  
> easier
> 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  
didn't
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
	later.

(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.

Owen