[arin-ppml] IPv6 Non-connected networks

[Owen DeLong]

On Mar 26, 2010, at 2:02 PM, Chris Engel wrote:

> Owen Delong wrote:
> 
>> 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)
> 
> 
> Not to sound like the village idiot here... and I probably will since I have ZERO experience with VOIP protocols.... but how would this be qualitatevly different from the Remote Admin having a filter rule on his Firewall that silently drops such traffic anyway?
> 
Because the customer can tell me what packets I'm looking for in my log to be able to tell definitively that they
never arrived at my system.

Without NAT:

Me:	What is your IP address?
Customer: 192.159.10.92 (example only)
Me: (greps logs for 192.159.10.92)
Me: Hmmm... I don't see any packets from that address in my logs. Can you check with your firewall
	administrator to see if they might be blocking it?

With NAT:

Me: What is your IP address?
Customer: 10.0.0.5
Me: Um, do you, by any chance know what address or range of addresses your firewall uses on the outside
	to represent that address?
Customer: Uh, what's a firewall?
... Let the games begin ...

No, before you start telling me that I should have the customer go to "whatismyipaddress" or similar, be aware
that is only useful if the firewall presents only 1 consistent address for a given user. Often firewalls have
pools of NAT addresses and they do not.

> I mean, if you aren't getting any traffic through...it's not like you would (in the absence of NAT) have this crystal ball that tells you WHY that traffic isn't getting through. Other then some very basic tests say for general internet connecivity and maybe a tracert to your IP... I would think you'd pretty much HAVE to contact the Admin on the other side of things to work out the issue.
> 
Sure, but, the difference, as illustrated above is that without NAT, I can tell deterministically that the packet did
not arrive based on information the customer can easily provide. With NAT, it becomes much more of a guessing
game which often requires information the customer may not have and often does not know how to get.

> Speaking as an Enterprise Admin... I don't WANT any traffic crossing my network boundary that I haven't specificaly setup mechanisms to allow. I also don't WANT any of my end users working with some outside Tech trying to route something through my Firewall that I haven't specificaly setup and approved.... in fact, around here we consider that kinda a "firing offense" (pretty common rule in Enterprises).
> 
Sure... A deny-all stateful inspection firewall will do that.

You're assuming that the incapable customer above is one of your users. I'm assuming that they're the average IT administrator in the small to medium enterprise. If you think I am wrong about the quality of average IT administrators, I suggest you spend some time working technical support at a service provider.

> The way a scenerio like that would go down if it happaned here would be:
> 
> 1) You'd call up one of my end users to try to figure out why the connection wasn't getting through.
> 
No, your end user called me because his SIP soft phone isn't working while he's at work, but, it works when
he's at the internet cafe and at home.

> 2) They (if they listened to thier training at all) would conference me or one of my staff in to help "resolve" the issue.
> 
It would be nice if they called you, but, when they call me instead, it's my job to try and help them anyway.

> 3) We would inform you (and them) that what you were trying to hookup wasn't a "Supported Application" on our network and therefore wasn't allowed... and wish you a nice day.
> 
That's great, when it works. However, when your user calls me, I don't even know you exist, and, the fact that they have a 10.0.0.5 address doesn't exactly help me find you, either.

> 4) I would then point out to said end user, the section of the security policy which they signed that covers the procedure for requesting new applications/functionality.
> 
That's between you and your user... Whatever.  However, you're spending resources and time at my company to deal with the deficiencies in your training program because of the damage being inflicted by your network configuration. If I can send you a bill for those calls, then, we're all good.  Otherwise, I maintain that, as stated before, NAT is toxic pollution which causes costs in places where they are not paid by the one dumping the toxins.

> 5) Thier supervisor would have a nice private chat with them.
> 
That's an entirely internal matter to your business.

> The whole thing shouldn't take more then 10-15 minutes of time.... and certainly shouldn't involve much pain on your end.
> 
You are assuming a lot more about human behavior by less qualified individuals than is required in my assertion that people should properly configure their firewalls. If I have to tolerate NAT and it's damage because you can't reliably avoid mistakes that fail open on your firewalls, then, you need to allow for a way to reimburse my costs that come from your even less qualified end users that also happen to be my customers.

Owen