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

["Klaas Wierenga (kwiereng)" <[e-mail]>]

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