[DNSOP] Proposed text for reverse-mapping-considerations draft

Andrew Sullivan <andrew@ca.afilias.info> Thu, 31 May 2007 21:24 UTC

Return-path: <dnsop-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hts8c-0006dt-1M; Thu, 31 May 2007 17:24:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hts8a-0006dn-0Y for dnsop@ietf.org; Thu, 31 May 2007 17:24:52 -0400
Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hts8Y-0006Vh-E9 for dnsop@ietf.org; Thu, 31 May 2007 17:24:51 -0400
Received: from andrew-vpn.int.libertyrms.com ([10.1.7.6] helo=trilby.local) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Hts8X-00039T-Ua for dnsop@ietf.org; Thu, 31 May 2007 17:24:50 -0400
Received: by trilby.local (Postfix, from userid 1019) id B218C3198F3; Thu, 31 May 2007 17:24:48 -0400 (EDT)
Date: Thu, 31 May 2007 17:24:48 -0400
From: Andrew Sullivan <andrew@ca.afilias.info>
To: dnsop@ietf.org
Message-ID: <20070531212447.GA20747@afilias.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
X-SA-Exim-Mail-From: andrew@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Subject: [DNSOP] Proposed text for reverse-mapping-considerations draft
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Andrew Sullivan <andrew@ca.afilias.info>
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
Errors-To: dnsop-bounces@ietf.org

Dear colleagues,

We received a suggestion that a short section outlining the history of
the use of reverse mapping in security contexts would be a good thing
to add to the reverse-mapping-considerations draft.  I have some
proposed text to add.  Before I add it, I'd like to ask for comments.
I am hoping that this text will be relatively uncontroversial, but if
it proves to be more contentious than the document has been already,
I'll cheerfully leave it out.



2.1 Historical origins of reverse mapping use in security 

.in 3
The growth of the Internet in the late 1980s and early 1990s brought
with it attackers who acquired access to machines without
authorization.  Many systems attached to the Internet up to that time
were poorly prepared for such attacks, and administrators were forced
to react using available resources rather than to redesign the network
to meet the new security challenges.

The popular TCP Wrapper package was originally conceived to discover
the network location of an attacker [Venema1992].  It used the reverse
mapping of a connecting host to provide the hostname of that host in
its output.

During the same period, the so-called "UNIX r* commands", like rlogin
[RFC1282] and [RFC1258], were widely used, in spite of warnings that
they were prone to abuse [Reid1987].  The r* commands allowed users to
employ a list of trusted hosts, from which connections would be
accepted and authenticated without password (sometimes called the
"rhosts authentication" mechanism).  The mechanism remained in
widespread use (in spite of known flaws) because of its convenience.
Since the list of trusted hosts was a simple list of hostnames or
addresses, an attacker could acquire access by intercepting the DNS
query for a hostname, and replying with the IP address from which the
attacker was making the rhosts authentication attempt.  (This was not
the only weakness in the mechanism, but it is the most relevant to
reverse mapping.)

In an effort to strengthen the rhosts authentication mechanism, the
TCP Wrapper package soon offered the ability to perform reverse
mapping matching checks.  If the reverse and forward mappings did not
match, the wrapper program would terminate the connection before
checking any of its other permissions.  This mechanism could be used
for all connections, on the grounds that forward and reverse
mismatches were an indication either that an attack was in progress;
or else that the network was badly managed, and therefore a likely
origin for attack.


Best regards,
Andrew


-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@ca.afilias.info>                              M2P 2A8
jabber: ajsaf@jabber.org                 +1 416 646 3304 x4110

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop