Dear Yan, > 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. My point was that I think the final draft needs to discuss the security issues in much more detail and state explicitly how they are addressed with the protocol, and if not what other solution are out there and could in principle help.
- Jan > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Wang Yan > Sent: Donnerstag, 13. August 2009 04:51 > To: Jan Seedorf; alto > Subject: Re: [alto] Security section of draft-penno-alto-protocol-03 > > 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
