Re: [alto] Security section of draft-penno-alto-protocol-03

[Wang Yan <wyan at huawei.com>]

Hi, Jan

> -- "An ALTO Server may optionally use authentication and encryption to
>   protect ALTO information.  Authentication and encryption may be
>   provided using HTTP Basic or Digest Authentication and/or SSL/TLS."
> --> I think this text is not specific enough. What needs to be authenticated are three things: a) the identity of the server, b) the identity of the client, and c) the ALTO information itself. TLS is a solution for a) and b), but for c) the ALTO information needs to be signed by other means, and not only on transport from client to server. Another thing the WG should discuss: is encryption necessary? Indeed, an ALTO-server should authenticate clients but the information it provides should not be confidential, especially if redistribution is specifically allowed.
> 
> -- As I was mentioning during the ALTO session in Stockholm, I see the risk of Denial-of-Service attacks on ALTO servers. Even if the ALTO server has some pre-computed cost maps, an attacker could easily stress an ALTO server by simply querying all potential permutations of source-lists and destinations-lists. It is unlikely that the ALTO-server has all of them pre-computed. In security, it is always seen problematic (from a DoS perspective) if simple/small messages can generate large workload at a server. I think this is the case for ALTO if a Path Rating query has a list of multiple Source Network Locations.
> 
> -- I think the security section has only very general text on privacy issues. This is strange since the draft says: "Two key design objectives of the ALTO Protocol are simplicity and extensibility.  At the same time, it introduces additional techniques to address potential scalability and privacy issues." It would be nice to discuss these issues in the concrete scope of the proposed ALTO-protocol.
> 
> Again, I know the authors were focusing on the merge, but I hope they agree that the security section needs much more work. I felt like giving it a start with some comments.

Agreed. 

I think currently it is a good idea to combine most good solutions together, after all they are basically to solve one problem. However, since each solution has its own pros and cons,  good combinations can make them complementary to each other and improve the advantages of protocol, whereas bad combinations may not only increase the load of server but also preserve the disadvantages of all the solutions, and increase the risk of privacy at the same time.

After reading this draft, I feel that the entity is well designed, and the functions are enhanced. However, conventional cons seem still exist, especially some aspects on workload and privacy need to be clarified, the method to authenticate too many information may increase workload significantly.


Regards
Yan
_______________________________________________
alto mailing list
alto at ietf.org
https://www.ietf.org/mailman/listinfo/alto