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 [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
