Re: [BEHAVE] DNS vs port overloading

Simon Perreault <simon.perreault@viagenie.ca> Thu, 27 June 2013 14:48 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0680C21F9A6B for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 07:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level:
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvAzihDzyVcG for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 07:48:15 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4921F9A43 for <behave@ietf.org>; Thu, 27 Jun 2013 07:48:15 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EC1F747121; Thu, 27 Jun 2013 10:48:13 -0400 (EDT)
Message-ID: <51CC50AE.2080909@viagenie.ca>
Date: Thu, 27 Jun 2013 16:48:14 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
References: <CB1B483277FEC94E9B58357040EE5D02325A6E93@xmb-rcd-x15.cisco.com> <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <f8741fad1af1cee094de9c59408b7425@cacaoweb.org> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> <51CC444C.1030507@viagenie.ca> <20130627141434.3B0BD365EA62@drugs.dv.isc.org> <51CC4A59.8080801@viagenie.ca> <20130627143612.51ECB365ED5A@drugs.dv.isc.org>
In-Reply-To: <20130627143612.51ECB365ED5A@drugs.dv.isc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: behave@ietf.org, ivan@cacaoweb.org
Subject: Re: [BEHAVE] DNS vs port overloading
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 14:48:16 -0000

Le 2013-06-27 16:36, Mark Andrews a écrit :
>>> And overloading DNS could potentially defeat the port randomisation
>>> done by the server even though nameservers do port overloading
>>> themselves to send traffic out a large set of ports choosen at
>>> random and reselected from at random.
>>
>> Good point.
>>
>> Could that be solved with operational advice? In the case of CGN, we
>> could advise the ISP could to make sure that its recursive nameserver
>> sits on the border between the internal and external realm such that no
>> DNS traffic is handled by the CGN.
>>
>> Would that fully address your concern?
>
> No.  Many ISP's have a history of mucking with DNS results when you
> use their servers.  Most ISP's don't muck DNS queries not directed
> to their servers.  For those that do you can usually see that they
> are mucking with results.
>
> You can't just redirect queries at a normal recursive server and
> think that will provide a "transparent DNS caching server".

Right, but, port overloading is not what kills the randomization done by 
the DNS client. Non-port preserving NAT is what kills it.

Non-port preserving NATs are already required to implement port 
randomization according to:

https://tools.ietf.org/html/rfc6056#section-4

Port overloading is not incompatible with port randomization. Maybe we 
should explicitly write this and add a reference to RFC 6056?

Simon