[secdir] Sector review of draft-ietf-alto-deployments-15

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Mon, 20 June 2016 13:01 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3999512D09D; Mon, 20 Jun 2016 06:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Mi3Z2D8XhdKK; Mon, 20 Jun 2016 06:01:06 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 794CD12B05C; Mon, 20 Jun 2016 06:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10920; q=dns/txt; s=iport; t=1466427666; x=1467637266; h=from:to:cc:subject:date:message-id:mime-version; bh=EGy9vmWbpQ3cOv4f+RKBNGw6x0lG2DCg4NAI+wCCIlc=; b=G/Oql8nUKNLlCuDGmgN0IRl+IyxRMvjlmQLUECxjZk8rCdZOkG5i0Rii g1qC1ISgn5RBsT9Zh0YqaeEKgYdg9/a/j6nwvTKKSWrs+InPAT4L+uZpU yJav/5D1N+SQ3sBONRx8W8IJNHWRx5zZZ3nwPCBHkuEnnbPtDFzLmJJ50 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTJgAp6GdX/4UNJK1VCYJwToFZi06qE?= =?us-ascii?q?IZ7hhcegRQ7EQEBAQEBAQFlJ4RSI1YSAUoCBDAnBAENiDWwDJAaAQEBAQEBAQE?= =?us-ascii?q?CAQEBAQEBAQEBHoYniGYRgxeCWgWYdgGBMJwbj3YBNCCDcIl0Kxh/AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,498,1459814400"; d="scan'208,217";a="287625842"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2016 13:01:05 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5KD152N007733 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Jun 2016 13:01:05 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 08:01:04 -0500
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 08:01:04 -0500
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Sector review of draft-ietf-alto-deployments-15
Thread-Index: AQHRyvPNnxFha3RvI0Cb/MKm5WKEeQ==
Date: Mon, 20 Jun 2016 13:01:04 +0000
Message-ID: <etPan.5767e90e.4c847566.f16f@KWIERENG-M-H01C>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.67.153]
Content-Type: multipart/alternative; boundary="_000_etPan5767e90e4c847566f16fKWIERENGMH01C_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/pJpfwAYi_kb2kypyKigvtt4cIP8>
Cc: "draft-ietf-alto-deployments.all@tools.ietf.org" <draft-ietf-alto-deployments.all@tools.ietf.org>
Subject: [secdir] Sector review of draft-ietf-alto-deployments-15
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: Mon, 20 Jun 2016 13:01:08 -0000

Hi,

 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.

This document describes use cases when deploying ALTO (Application Layer Traffic Optimization). It provides guidance for using and deploying ALTO services.

The document reads well and is as far as I can tell pretty exhaustive (if anything the emphasis seems slightly on P2P rather than CDN, but that seems justified by the number of different P2P deployments as opposed to CDN).
I particularly like the extensive coverage of privacy and security issues throughout the document, this was clearly not bolted on late in the process. I have only a few comments and therefore believe the document is:

ready with nits

- A number of the comments throughout the document pertain to privacy, I think the document would have benefited from a separate privacy considerations paragraph, in addition to the security considerations.

- Not directly security related (apart from DoS), but I wonder in how far it is a risk that clients have a relatively static view of the world (3.4.4), i.e. it is assumed that the network characteristics don’t change rapidly. To use an analogy, is there a risk that when there is some holdup on the highway, that all cars will take the sand path for some extended period of time, thus clogging the sand path? If this is covered in other documents I apologise, but in the reviewed document that appears to be a risk.

- There is text around validation of the clients (7.3 ALTO server access), but to my surprise there is no wording to authentication of the server. As a client operator I would expect to be able to validate the server, after all the server is telling me where to go for the resources I need. The text explains what the risk of injecting wrong information is (7.4), but the authenticity of the server itself is not discussed. A simple server authentication seems to go a long way in preventing rogue ALTO servers.

Klaas


--
Klaas Wierenga
Identity Architect
Cisco Cloud Services