Re: end2end? (was: RE: Where NAT disenfranchises the end-user ... )

[Leo Bicknell <bicknell () ufp org>]

On Fri, Sep 07, 2001 at 08:16:21PM -0400, Dickson, Brian wrote:
> IP is the transport layer. While many programs may let us type IP addresses
> at them, any protocol higher up the stack which involves or relies on IP
> addresses is, IMHO, badly broken. It would be just as bad to involve MAC
> addresses. At the very least, it defeats the whole purpose of having a
> *stack*.

While thinking about IP's specifically, I don't find it so gross
that they are included in protocols.  There are legitimate reasons
a protocol may want to say 'I want you to establish a connection
back to me if you want this service, please contact me at xxxxxx'.
That could be an IP, or a hostname, or (possibly) something like
a e-mail address.

Many protocols do this for _no good reason_, which is stupid on
the protocol designers part.  Some protocols do this for very good
reasons, and need this sort of functionality.

> It's really this simple: If you need to do non-TCP, server-server stuff, you
> need a static IP. It doesn't matter whether dynamic IP and port comes from
> NAT or DHCP - there will always be things you can't do behind those. If you
> want to do those things, don't go behind one of them.

This isn't true.  I can think of another way to solve this problem.
End systems could be 'told' (manually, automatically?) that they
cannot be contacted at the address configured on their NIC.  For
hosts behind two way NAT systems this could be the NAT outside
address, for hosts behind one way NAT this could be blank, so
applications know such communication isn't possible, and fail
gracefully.

> Or implement better protocols that don't break when NAT is used, or place
> ridulous burdens on ports that need to be opened on firewalls (H.323 ?!?),
> or better yet, use some kind of 3-way, 3-party handshake to establish
> peer-peer between NAT'd client-type boxes (for programs that facilitate

Yes, most protcols are unnecessarily complex, and that should be fixed.

> copyright violations.) And by the way, whatever happened to the notion that
> the firewall should also be a proxy at the application layer rather than a
> mere packet-forwarding-and-munging box?

Most people implementing security have no idea what they are doing.
If I had a nickle for every time I was told 'that machine is on private
address space so it doesn't need to be secured' I'd be a billionair.

-- 
Leo Bicknell - bicknell () ufp org
Systems Engineer - Internetworking Engineer - CCIE 3440
Read TMBG List - tmbg-list-request () tmbg org, www.tmbg.org