W3C home > Mailing lists > Public > ietf-discuss@w3.org > August 2001

Re: Use ofHTTP to pass firewalls

From: Keith Moore <moore@cs.utk.edu>
Date: Wed, 22 Aug 2001 17:20:50 -0400
Message-Id: <200108222120.RAA07891@astro.cs.utk.edu>
To: Patrik Fältström <paf@cisco.com>
cc: Keith Moore <moore@cs.utk.edu>, Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, jpalme@dsv.su.se, discuss@apps.ietf.org
> I was not talking about NAT's, but things that block traffic on certain
> ports, like normal firewalls, but you are completely right that this can be
> used for NAT purposes aswell.
> But, I get your point. Doing DHCP request, pppoe authentication etc when a
> host "wakes up" and get's an IP address is one thing. Doing the same or
> similar things when it for example starts it's "SIP telephony listener" or
> initiates some other flow is not good.
> That is what I read in your message.

That's true, but there's more to it than that.  Yes, doing a dynamic DNS update
on a per-flow (rather than just a per-login) basis is a pain. But more generally,
expecting all apps to use SRV on a per-connection basis is a bad idea.  DNS names
are ill-suited as endpoint identifiers for a variety of reasons, including that  
DNS lookups are slow (often taking several seconds to complete), they're not 
terribly reliable (servers often falsely report errors and/or are misconfigured)
Putting SRV lookups in the path slows things down and makes the overall app
less reliable.  Port-hopping also makes it more difficult to diagnose and fix 

You might get this to work for specific applications, but it's not a general
purpose solution.    And the last thing we need is for the network to become
more application-aware and application-specific.

Received on Wednesday, 22 August 2001 17:22:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC