Home page logo
/

nanog logo nanog mailing list archives

Re: end2end? (was: RE: Where NAT disenfranchises the end-user ... )
From: Leo Bicknell <bicknell () ufp org>
Date: Fri, 7 Sep 2001 20:42:29 -0400


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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]