[84460] in North American Network Operators' Group
Re: Computer systems blamed for feeble hurricane response?
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Tue Sep 13 16:37:50 2005
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: Joseph S D Yao <jsdy@center.osis.gov>
Cc: Mike Tancsa <mike@sentex.net>, nanog@nanog.org
In-Reply-To: Your message of "Tue, 13 Sep 2005 16:20:40 EDT."
<20050913202040.GK16110@core.center.osis.gov>
Date: Tue, 13 Sep 2005 16:28:41 -0400
Errors-To: owner-nanog@merit.edu
In message <20050913202040.GK16110@core.center.osis.gov>, Joseph S D Yao writes
:
>
>On Tue, Sep 13, 2005 at 04:15:29PM -0400, Mike Tancsa wrote:
>> At 03:50 PM 13/09/2005, Joseph S D Yao wrote:
>>
>> >Oh, and also ... please consider that some firewalls try to discern
>> >whether the connection on port 25 is from a mail server or from Telnet.
>> >While I mourn the simplicity of manual debugging of such sites, it
>> >remains that: the fact that you can't TELNET HOST.DOMAIN 25 doesn't mean
>> >that there's no mail service there.
>>
>> Making a network connection using the application "telnet" vs the
>> application "sendmail" (or whatever MTA one uses) seems to be the
>> same when doing a tcpdump on the data. I am not sure how a firewall
>> would know -- purely at the network layer -- what the other side's
>> application was/is that initiated the connection. Yes, the other end
>> could try and connect back to the host, but there is no 2 way traffic
>> as the 3way handshake is not completing and I dont see any other
>> traffic coming back from that host attempting to discern any info.
>
>
>I don't know, myself. I said they try. Perhaps they succeed. Perhaps
>they check the speed of incoming queries. Perhaps they try to use a
>Telnet OPTION. I don't know. Perhaps it's a sales gag. [I think it
>was a telnet OPTION, actually.]
>
Telnet options, and for that matter speed, happen after the 3-way
handshake. We're not getting that far.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
