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

[Sebastian Kiesel <[e-mail]>]

Hi Klaas,

thanks for the review and your comments. Please see below

On Mon, Jun 20, 2016 at 01:01:04PM +0000, Klaas Wierenga (kwiereng) wrote:
> 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.

Could you please have a look at Section 5.2 of RFC 6708.  Does the
discussion there address your comment? If so, we could add another
direct reference to that section at a suitable place in our document.
If not, what is still missing?

> - 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.

First, to stick with the analogy with cars, the baseline ALTO scenario
is not so much about whether to drive on the highway vs. on a sand path
to get to a specific destination.  It's more like wisely choosing the
destination, e.g.: 
I want to buy a specific product and I know that it is available at
identical price and quality in chain stores in X street and Y street,
respecively.  Where should I drive to get the product?  The ALTO answer
would be something like: To get from your home to X street you will have
to drive 5 km through a residential area with 30 km/h speed limit, while
to Y street it is 8 km on a freeway with 120 km/h speed limit, but it is
usually badly congested during rush hour.  
Obviously, this answer would not allow you to drive constantly at this
speed without looking for the actual traffic conditions.  

In other words, leaving the analogy: ALTO is not a replacement for TCP
or similar mechanisms; see AR-14 in RFC 6708 and the second part of 
Sec. 3.2.4. of our document, starting with "All the above listed rating
criteria are subject to the remarks below: ..." on page 27.
Section 7.4, "Preference of a single peer" points out the DoS risk.


Does this make sense or did I miss some point?


> - 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.

ALTO servers and clients MUST implement https (see Sec. 8.3.5. 
of RFC 7285).

However, in some (P2P) scenarios, there is very limited trust
between the participants of the application overlay and the
ALTO server operator(s).  So verifying the server identity by
means of the TLS cert may not be enough to answer the question
whether this information source is trustworthy. This section
intends to extend the guidance given in section 15.2. of RFC 7285.



Thanks,
Sebastian