Re: Last Call: RFC 6346 successful: moving to Proposed Standard

Ted Lemon <Ted.Lemon@nominum.com> Thu, 04 December 2014 16:58 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16761A1BCC for <ietf@ietfa.amsl.com>; Thu, 4 Dec 2014 08:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuDkCDSryXAm for <ietf@ietfa.amsl.com>; Thu, 4 Dec 2014 08:58:48 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2C31A024C for <ietf@ietf.org>; Thu, 4 Dec 2014 08:58:48 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id AE534DA011F for <ietf@ietf.org>; Thu, 4 Dec 2014 16:58:34 +0000 (UTC)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1CFC453E076; Thu, 4 Dec 2014 08:58:18 -0800 (PST)
Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Dec 2014 08:58:06 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Last Call: RFC 6346 successful: moving to Proposed Standard
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <DBB1C75E-96D9-4F3B-93A9-EE22C40D47A7@netapp.com>
Date: Thu, 04 Dec 2014 11:57:51 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <29C2D286-E8D9-4D66-9F4D-A069EB0FFDC3@nominum.com>
References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <20141204162800.GE19718@mx1.yitter.info> <DBB1C75E-96D9-4F3B-93A9-EE22C40D47A7@netapp.com>
To: "Eggert, Lars" <lars@netapp.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/SkFB_CX7kz4FN6hiskHIP5A8ld4
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Dec 2014 16:58:50 -0000

On Dec 4, 2014, at 11:44 AM, Eggert, Lars <lars@netapp.com> wrote:
> And it's not only DNS that is being attacked, that attack just happened to be widely publicized. (For example, BGP sessions have been the target of TCP RST attacks.) Port randomization is a generally useful technique, which is why we did RFC6056, the effectiveness of which is reduced by A+P.

This is a concern that's been discussed at length already.   It's a real problem.   However, the actually application for A+P is in a dual-stack environment, where DNS queries really ought to be going over the IPv6 transport, not the IPv4 transport.   Additionally, a great many of the commonly used port-intensive services at this point are available over IPv6, and we would prefer that they go over IPv6.   So although there is clearly a reduction in the available number of _IPv4_ ports in an A+P scenario, the total number of available ports in this situation is more: the host no doubt has at least one and perhaps more than one IPv6 address, which can be used for all but the remaining legacy applications.

So it's possible that this ought to be discussed further in the document.   But the fundamental answer to the port guessing vulnerability is "switch to IPv6."   And as several people have already mentioned on this thread, the port starvation problem exists in any NAT, whether A+P is being done or no.   It is particularly bad in CGN, whether they are stateful or stateless.   So it's good to call out the issue and use it to motivate the advice that service providers _really_ ought to be turning on IPv6 if they haven't already.