Re: how many angels can dance on the head of a pin?

Alex Bligh <alex@alex.org.uk> Sun, 10 August 2008 12:06 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85E928C0FB; Sun, 10 Aug 2008 05:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.289
X-Spam-Level: *
X-Spam-Status: No, score=1.289 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ8qSd2IBBcc; Sun, 10 Aug 2008 05:06:14 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE9B53A6DBB; Sun, 10 Aug 2008 05:06:14 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KS9YV-000B2n-Ti for namedroppers-data@psg.com; Sun, 10 Aug 2008 11:57:51 +0000
Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <alex@alex.org.uk>) id 1KS9YS-000B2V-9h for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 11:57:50 +0000
Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 43346C2DA3; Sun, 10 Aug 2008 12:57:43 +0100 (BST)
Date: Sun, 10 Aug 2008 13:01:26 +0100
From: Alex Bligh <alex@alex.org.uk>
Reply-To: Alex Bligh <alex@alex.org.uk>
To: Ben Laurie <ben@links.org>
cc: Duane at e164 dot org <duane@e164.org>, bmanning@vacation.karoshi.com, Namedroppers <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk>
Subject: Re: how many angels can dance on the head of a pin?
Message-ID: <9638F8EA548C822160EF40E4@nimrod.local>
In-Reply-To: <489ED142.8010500@links.org>
References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> <489E89B6.6090208@e164.org> <01B9CF1DF0A4A4443A6E73A4@nimrod.local> <489EAFCD.2090204@e164.org> <6751CAB7406138E7F72B474E@nimrod.local> <70CC931622BD9710F13283EA@nimrod.local> <489ED142.8010500@links.org>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

Ben,

--On 10 August 2008 12:30:10 +0100 Ben Laurie <ben@links.org> wrote:

>> I should have added that whilst non-broken NATs don't make things worse
>> (*), they also don't make things better.
>
> Not so, actually. If the NAT does random port assignment, then the
> resolver's assignment can be predictable.

Yep quite possibly. My post was precaffeinated and I was referring to
resolvers that were fixed-up, i.e. unpredictable. In practice though, I
suspect (Roy will know better) that a NAT seeing traffic from a single
internal (src IP, src port) tuple will continue to map that to a single
external (src IP, src port) tuple because, unless it's doing deeper
inspection than normal, it doesn't know which packets form separable
conversations. So the improvement would only occur where the broken
resolver used a non-constant but predictable port, which is the minority of
cases.

My point was that one should not think one can just stick a caching
resolver behind a NAT device and suddenly achieve immunity from this
particular poisoning attack. I presume you agree with that?

Alex

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>