RE: Where NAT disenfranchises the end-user ...

From: Jim Shankland []
Sent: Friday, September 07, 2001 12:35 PM

Roeland Meyer <> writes:

> You've just described a NAT proxy daemon. I've spent years
trying to write
> one. If you are that good, send code. Or better yet, send it to
> The fundimental reason that you can't
write one is that
> it requires a whole other protocol that 1) deosn't exist, 2)Isn't
> implemented, 3)Violates more than one of Dykstra's laws.

Don't mean to nitpick, but I was describing no such thing. I was
suggesting the development of a protocol. Saying that can't be done
because the protocol "1) deosn't exist, 2)Isn't implemented" seems
a little circular :-). Don't know which of Dijkstra's laws
that might
violate, either (except maybe "Don't misspell my name" :-)).

I'm also dutch and should know better. However, neither can I type, as the
quoted portion clearly shows. .. cna't spell, can't type, I must write code
<g>. lint will save me.

I'm also too terse for my own good, sometimes. Item 2 is looking forward to
deployment. Adoption will be supremely difficult and unless universally
adopted, it won't fly. It's a flash cut-over scenario with disparate
implementors. Success is estimated at around 0.001%, in such cases.

The law I am thinking of is the one where the application can't tell where
the failure is until it fails. It is fundimentally unpredictable.

The argument, roughly, is that there is a small set of operations
(identifying an <ipaddr:port> tuple in a network-portable way, and
dynamically allocating a new port to an application, are two
that come
to my mind) that make NAT and firewalls difficult for games,
audio/video, etc.; and that providing a standard protocol for these
operations would make building such applications, and having them
interoperate well with NATs and firewalls, much easier.

I'm not convinced this argument is correct, though it passes the
first-tier plausibility test in my mind. I just thought I'd float
the trial balloon.

The problem is in how to deal with the legacy. Also, most FW builders don't
want to give out any clue to a potential attacker, so they silently discard
the packets. In this case, how is a feedback mechanism supposed to work?