All, >From a high-level perspective, I think there are three different aspects:
1) ALTO client may want to confirm that ALTO server is not spoofed. 2) ALTO servers may want to authenticate clients to ensure that only allowed clients get guidance. 3) ALTO servers may want that communication is encrypted, since ALTO information is possibly sensitive At first sight, these three goals seem orthogonal to me. For instance: 1) This requirement may not be a significant issue of an ALTO server discovery method is used that is tightly coupled with the access network, because spoofing the discovery result is then pretty difficult. In such cases, the additional protection by TLS/SSL seems limited. 2) For guidance of unstructured P2P networks, this seems unrealistic with any credential-based method. In my opinion, it is more likely that the ALTO server will be protected by firewalls that only allow intra-domain access. For P2P tracker guidance, client authentication might be possible for a well-defined number of P2P systems. It also seems possible that an ALTO server could expose more detailed maps to well-known users than to random P2P clients. Client authentication is certainly very relevant for many non-P2P use cases. 3) This depends on whether client and server communicate over a possibly untrusted network. For instance, if ALTO client and server are in the same physical network, encryption is not a major issue. Also, if the ALTO maps are very simple and provide simple information only (e. g., inside-AS vs. outside-AS address ranges), encryption might not be needed even if ALTO clients are spread over the whole Internet. In summary, I think there are several cases where enabling of TLS/SSL is not really needed. Also, I might be wrong, but if an operator only has requirement 2), maybe HTTP authentication (RFC 2617) without using TLS/SSL encryption would be just sufficient. Michael > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Martin Stiemerling > Sent: Tuesday, March 05, 2013 5:14 PM > To: Roome, W D > Cc: [email protected] > Subject: Re: [alto] ALTO vs ssl/tls > > Wendy, > > would a 'MUST implement TLS/SSL' fix your concern? This does > say that the implementation must have it, but it does not > preclude to use it, e.g., if you operate the ALTO server in > your data center only. > > Martin > > On 03/05/2013 04:39 PM, Wendy Roome wrote: > > Richard, > > > > Your proposal sounds fine. After all, it's a "motherhood" > statement. > > Who could argue with, "If you need security, etc, use ssl/tls."? > > > > However, I am surprised by the suddenly perceived need for > security, > > and I'd object to anything that implies that the default is > to use ssl/tls. > > I think that will kill the protocol. I'd always thought > that ALTO was > > primarily intended to be a public service that network operators > > provide to all applications, not an exclusive service > available only > > to a few trusted components. A network operator would > provide a public > > ALTO service because it benefits the operator as well as > the client. > > Sure, some operators might restrict access, but most > wouldn't bother. > > A few > > observations: > > > > * An ALTO server just returns a limited view of the network > > statistics. It's not like it gives out launch codes or > banking data, > > or allows a client to change anything. Why is it so > important to keep > > that data secret? Especially if a server can use ordinal mode to > > obscure the details? > > > > * The only use case in draft 14 is a P2P tracker. By > definition, P2P > > trackers are distributed & anarchistic, and can be run by any Tom, > > Dick or Sally. I don't think it's practical to authenticate > thousands > > of P2P tracker clients. Besides, most tracker operators wouldn't > > hesitate to post their ALTO authentication credentials on > the web. :-) > > > > * I can see why an ALTO client might want to authenticate > the server, > > to prevent spoofing. Although that begs the question of why someone > > would bother to spoof an ALTO server -- how would they benefit? > > > > - Wendy Roome > > > > From: "Y. Richard Yang" <[email protected] <mailto:[email protected]>> > > Date: Mon, March 4, 2013 14:35 > > To: Bill Roome <[email protected] > > <mailto:[email protected]>> > > Cc: "Reinaldo Penno (repenno)" <[email protected] > > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" > > <[email protected] <mailto:[email protected]>> > > Subject: Re: [alto] ALTO vs ssl/tls > > > > Hi Wendy, > > > > The context of the change is the following AD Review: > > > > " What security mechanism to use in what scenario. The > considerations > > elaborate on the use of SSL/TLS, but it is not clear when > to use it. > > In general, it seems to be really good, at least by today, > to mandate > > the use of HTTPS in almost any scenario where the traffic crosses a > > publicly available infrastructure, e.g., the general Internet, > > wireless access networks, etc. Conversely, it can be good to always > > mandate the use of HTTPS and to list exceptional cases where it is > > required, i.e., CDNI peering point." > > > > How about the following revision: > > > > "When server and/or client authentication, encryption, and/or > > integrity protection are required, ALTO Server MUST support SSL/TLS > > [RFC5246] as a mechanism. For cases such as a public ALTO > service or > > there is an implicit trust relationship between the client and the > > server, SSL/TLS may not be necessary." > > > > Richard > > > > > > > > _______________________________________________ > > alto mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/alto > > > > -- > [email protected] > > NEC Laboratories Europe > NEC Europe Limited > Registered Office: > Athene, Odyssey Business Park, West End Road, London, HA4 > 6QE, GB Registered in England 2832014 > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
