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

From: "Jan Seedorf" <[email-masked]>
Date: Wed, 12 Aug 2009 17:53:27 +0200

Dear all,

I understand that prior to IETF-75 the authors of draft-penno-alto-protocol-03 where busy with merging the protocols. But I would like to point out that the security section is still far from done. Some points that immediately come to mind are:

-- 10.4.: "To fulfill these requirements, ALTO Information meant to be
   redistributable contains a digital signature which includes a hash of
   the ALTO information encrypted by the ALTO Server's private key."
--> replace "encrypted by the ALTO Server's private key" with "signed by the ALTO Server's private key" [in asymmetric cryptography, you either _decrypt_ or _sign_ with a private key]

-- 10.4.  ALTO Information Redistribution --> you basically suggest to have the ALTO-server sign information it provides. While that is certainly a good idea, the problem of ALTO information redistribution may be more sophisticated. Martin wrote a draft on some potential issues (draft-stiemerling-alto-info-redist-00). 

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

 - Jan

============================================================
Jan Seedorf
Research Scientist
NEC Europe Ltd., NEC Laboratories Europe, Network Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-221
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] 
============================================================
NEC Europe Limited Registered Office: NEC House,
1 Victoria Road, London W3 6BL Registered in England 2832014

---

From: Wang Yan <[email-masked]>
Date: Thu, 13 Aug 2009 10:51:10 +0800

Hi, Jan

> 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-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "Jan Seedorf" <[email-masked]>
Date: Fri, 14 Aug 2009 11:30:54 +0200

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-masked] [mailto:[email-masked]] 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
> 
> > --> 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

---

From: Wang Yan <[email-masked]>
Date: Wed, 19 Aug 2009 11:29:04 +0800

Hi, Jan

I agree that we need clearer description on security. What I mean is I think privacy and workload also need to analyze, only by means of certification and encrypt cannot solve the problem of privacy. Each single solution has its own pros and cons on these aspects. The mixed draft also does not explain on these aspects and it has these problems as I think, so I think it is necessary to write a draft to analyze each solution one by one, and hopefully there is an analytic result which can clearly details each solution regarding these aspects, provides help to future solutions, instruct and help ISP to provide the service in practice. We also hope to find some potential solution from the analysis. Now we just start up this work. What about your opinion? And if anybody thinks it's practical, let's discuss together.

Regards
Yan

----- Original Message ----- 
From: "Jan Seedorf" <[email-masked]>
To: "Wang Yan" <[email-masked]>; "alto" <[email-masked]>
Sent: Friday, August 14, 2009 5:30 PM
Subject: RE: [alto] Security section of draft-penno-alto-protocol-03

Dear Yan,

 - Jan