[secdir] Secdir review of draft-ietf-ice-dualstack-fairness-03

Charlie Kaufman <charliekaufman@outlook.com> Thu, 07 July 2016 04:12 UTC

Return-Path: <charliekaufman@outlook.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EC0A712D1D8; Wed, 6 Jul 2016 21:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.597
X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BdA61mMF7y2t; Wed, 6 Jul 2016 21:12:11 -0700 (PDT)
Received: from SNT004-OMC2S40.hotmail.com (snt004-omc2s40.hotmail.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77CAA12D0C3; Wed, 6 Jul 2016 21:12:11 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com ([]) by SNT004-OMC2S40.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 6 Jul 2016 21:12:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=paz6pom1ktsbO1qEcI4p1jUkHi0WKKaW4wAl8ffGYtI=; b=Z36XzDYUYAesHBaTKINL01xRCEQwYbF+/swxjNK+XtatxoubR7vWBhJvThv+TI+wMdI4k+zbbN4dUYbYW4a0x7pHa+ZG2OJ9j9Gm+YAN0tzGmFuZGO51sQRumZEnZdSeXT/QGSeFh6lwCk2asPDTe2kR0q0v9q//eVyr1JWHNcHvYQrTs+ChRsMfMN5TnsHfZpXLtXsUM0LiT/HYkgqq+2K1ZB6wsWAOA0DuBYBw6Cl+JvSED5tBnnFm0ftHB6Q+7WXr0ItJrhSKfd0EhtDDGAw0kAueYToNfK1uRH7Ws6RI62RpU3hLRz5QEZn8kE64OBKJRCzGYLiEjEmmleeLOw==
Received: from SN1NAM01FT043.eop-nam01.prod.protection.outlook.com ( by SN1NAM01HT193.eop-nam01.prod.protection.outlook.com ( with Microsoft SMTP Server (TLS) id 15.1.523.9; Thu, 7 Jul 2016 04:12:09 +0000
Received: from CY1PR17MB0425.namprd17.prod.outlook.com ( by SN1NAM01FT043.mail.protection.outlook.com ( with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Thu, 7 Jul 2016 04:12:09 +0000
Received: from CY1PR17MB0425.namprd17.prod.outlook.com ([]) by CY1PR17MB0425.namprd17.prod.outlook.com ([]) with mapi id 15.01.0528.024; Thu, 7 Jul 2016 04:12:09 +0000
From: Charlie Kaufman <charliekaufman@outlook.com>
To: "secdir@ietf.org" <secdir@ietf.org>, 'The IESG' <iesg@ietf.org>, "draft-ietf-ice-dualstack-fairness.all@tools.ietf.org" <draft-ietf-ice-dualstack-fairness.all@tools.ietf.org>
Thread-Topic: Secdir review of draft-ietf-ice-dualstack-fairness-03
Thread-Index: AQHR2AUWk4ql4+jlVEO1OZzBN30rgA==
Date: Thu, 07 Jul 2016 04:12:09 +0000
Message-ID: <CY1PR17MB042523AE29B615686A832F68DF3B0@CY1PR17MB0425.namprd17.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=softfail (sender IP is smtp.mailfrom=outlook.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=outlook.com;
received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of as permitted sender)
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [4WfPlo6q0GyfRk+rxRLBbSWd/sDdA1X3]
x-eopattributedmessage: 0
x-forefront-antispam-report: CIP:; IPV:NLI; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM01HT193; H:CY1PR17MB0425.namprd17.prod.outlook.com; FPR:; SPF:None; CAT:NONE; LANG:en; CAT:NONE;
x-ms-office365-filtering-correlation-id: d8fb2e61-a43f-4fba-1b29-08d3a61cdd8b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(5061506196)(5061507196)(1603103041)(1601125047); SRVR:SN1NAM01HT193;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM01HT193; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT193;
x-forefront-prvs: 0996D1900D
Content-Type: multipart/alternative; boundary="_000_CY1PR17MB042523AE29B615686A832F68DF3B0CY1PR17MB0425namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 04:12:09.4227 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT193
X-OriginalArrivalTime: 07 Jul 2016 04:12:11.0024 (UTC) FILETIME=[BBF44900:01D1D805]
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/t4Pcv_2Mi4HYEg2L9VzVshj7mlc>
Subject: [secdir] Secdir review of draft-ietf-ice-dualstack-fairness-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jul 2016 04:12:14 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

I don't believe this proposal raises any security concerns. It has a short Security Considerations section containing information relevant to ICE but not to this proposed modification.

This document proposes a modification to RFC5245bis (which specifies a protocol for NAT traversal). When trying to establish a connection through a NAT, there are a number of different techniques that can be used, some of which will work and some of which will not work depending on the characteristics of the NAT and other aspects of the environment. RFC5245 specifies an enumeration of such techniques and specifies an order in which they should be attempted.

Apparently, there are problems in real world deployments where there are a large number of possible NAT traversal techniques and checking them in the order prescribed by RFC5245bis results in long delays and sometimes connection failures based on timeouts. This document proposes changing the order in order to get better performance and reliability. It makes no other changes to the protocol.

Detailed review:

I'm not an ICE expert, so some of these comments may be completely misguided. Take them for whatever they may be worth.

I don't think "fairness" is the right term in this context. The goal is not a fair division of resources between different clients or even any sort of balance between use of IPv4 and IPv6. If many different connectivity mechanisms worked, the preferred mechanism would be (I assume) the one computed using the formula in RFC5245bis. The problem is that checking all of the mechanisms in order to too time consuming, and there is a desire to check (and settle on) techniques more likely to work ahead of techniques less likely to work but more optimal if they do (in particular, checking some IPv4 based techniques before all of the IPv6 based techniques have been tried).

Section 5 says:
> ICE [I-D.ietf-ice-rfc5245bis] section has guidelines for how
> the type preference and local preference value should be chosen.
> Instead of having a static local preference value for IPv4 and IPv6
> addresses, it is possible to choose this value dynamically in such a
> way that IPv4 and IPv6 address candidate priorities end up
> intermingled within the same candidate type. It is also possible to
> assign lower priorities to IP addresses derived from unreliable
> interfaces using the local preference value.

This specification says what is possible, but it does not (as far as I could see) specify any particular means of accomplishing it. If the intent of this RFC is to encourage people to experiment with different priority techniques, that's fair but the document should say so. If the intent is to encourage people to copy the design in ICE_dualstack_imp, then it's formula for priority should be specified here in sufficient detail to implement it.

Section 1 para 1 line 5: All interfaces and address types are known to the application. Perhaps this was intended to say all interfaces and address types known by the application to be unreliable...

Section 1 last paragraph and Section 5 third to last paragraph say:

> The introduced fairness might be better, but not
> worse than what exists today

This is probably not true. There are probably unusual cases where this reordering will result in slightly increased connection times. I suspect what is meant is that "In almost all cases this change will result in connection times at least as fast as those using the previous system, and in many cases the benefit will be substantial."


Section 1 para 1 line 5: arguable -> arguably
Section 1 para 1 line 7: know -> known
Section 1 para 2 line 7: describes -> describe
Page 4 last para line 7: "too excessive" -> "not optimal"
Section 7 end of third to last paragraph: missing "."

Reply all

Sent from Outlook<http://aka.ms/weboutlook>