Wed, 16 Jul 2003

Dropping IDENT requests causes e-mail delays

Some router/firewall boxes silently drop IDENT requests instead of refusing them. Steve Gibson refers to this as stealth mode. In theory, the advantage is that an attacker can't tell that anything even exists at your IP address if it doesn't respond to any connection attempts, including port 113, the IDENT/AUTH service.

But dropping all IDENT requests leads to long connection delays for many popular services, including outbound e-mail connections to many SMTP servers.

The smart thing to do is drop (or stealth) IDENT connections from hosts you have no active, outbound connections with. Refuse IDENT connections, which requires sending a reply packet, from hosts to which you have established TCP connections. A stateful firewall should be able to do this, but I haven't done any research to discover whether such firewall/router boxes exist short of configuring a Linux or FreeBSD server for that purpose.

An associate of mine has a Netgear RP614 Broadband Firewall/Router box. He complained that his e-mail connections were intolerably slow and asked me to investigate. The problem was dropped IDENT requests. His system made connections through the Netgear box to an SMTP server on the Internet. Upon establishing each connection, but before sending any data on the connection, the SMTP server attempted an IDENT connection back to my associates computer. His Netgear box silently dropped the incoming IDENT packets.

SMTP servers typically handle two situations quite well. The first is an accepted IDENT request. If the host making the outgoing SMTP connection has an active IDENT service, the SMTP server connects to it, request the user ID associated with the outgoing SMTP connection, and adds that bit of information to its logs and/or received headers. This is quite useful for tracking down the responsible party of e-mail abuse on a multi-user system. Without it, the task would be much more difficult.

The other common, and quite valid case, is to refuse IDENT requests. When this happens, the SMTP server gets an immediate response to its request, No! Fine. It simply notes that no user ID is available and proceeds with the SMTP mail transfer.

When the IDENT requests are silently dropped, however, what is the SMTP server to do? It has little choice. It assumes it's un-replied packets are traveling on a slow or congested network. It waits. After it has waited long enough, it decides the IDENT packet may have been lost on the Internet before reaching its destination. Another request is sent. This wait/resend cycle continues, usually for 30 seconds, but is often configurable and can be longer or shorter. In any case, it causes a very noticeable delay before the SMTP mail transfer actually begins.

While searching for a solution to this problem from the source of all knowledge, I found only one reference regarding the Netgear RP614 and IDENT requests, a comparative review of the Netgear RP614 and the D-Link DI-604 by Scot Finnie, publisher of the, apparently, very popular Scot's Newsletter.

In his review, Scot preferred the Netgear box's approach to IDENT requests: silently dropping IDENT packets. In fact, even though his bottom-line choice with the D-Link router, he considered the "closed port" (i.e., refused connections) a bug and encouraged the manufacturer to fix it.

I wrote Scot an e-mail explaining that I was trying to solve a problem created by the very security feature he preferred. I assumed that he may not have been aware of the connection delays stealthing port 113 causes.

What did I expect?

I suppose I expected a reply along the lines of, "Yes, I'm aware of the issue. It is a non-issue, and here's why…"

I hoped for a reply along the lines of, "You are correct. I will let my readers know the pros and cons of stealthing port 113. Some, if not all, would be better served by a firewall that refuses IDENT requests than by one that silently drops them."

What I got was:

…RFCs don't matter to me in the least. What matters to me is something that works.

I'm not against the IDENT functionality; just the way it's been implemented.

To which, I replied:

…Surely, you don't mean what you're say[ing] here. The Internet works as well as it does because of compliance with RFCs. Without them, interoperability between platforms, programs, and networks would be virtually impossible. The fact that you and I are exchanging e-mail at all is because RFCs do matter to the people that created the tools we're using to communicate.

In what way is it implemented incorrectly? How would you implement the functionality it provides in a way that wouldn't create problems for firewalls that blindly drop IDENT packets?

Then I got this retort:

Marc, you're not listening. And you just want to b***** about your e-mail problem. As I said before, most people don't have this problem. If you decide to become a subscriber, let me know. I'll have more time to discuss this with you then.

I meant everything I said. And none of your arguments swayed me. I have thousands of readers. Not everyone has the same problems you do. I represent everyone. Not just one.

Wow! I truly was trying to be helpful by pointing out what I thought was an oversight in Scot's review. This exchange was really not what I expected.

Scot may have thousands of loyal subscribers. I think I only have one (Hi Mom!), but I think she's getting better advice.

No, I won't be subscribing to Scot's newsletter. My first encounter didn't leave me feeling like I'd discovered an expert.

[/internet] [link]

About this weblog

This site is the personal weblog of Marc Mims. You can contact Marc by sending e-mail to:
[email protected].

Marc writes here about cycling, programming, Linux, and other items of personal interest.

This site is syndicated with RSS.

Credits

CSS stolen from Tom Coates who didn't even complain.