Hi, On Mon, Mar 11, 2013 at 10:06:53AM -0400, Wendy Roome wrote: > No one else has stepped up, so I'll offer my 2 cents worth. > > >Date: Wed, 6 Mar 2013 18:49:21 +0200 > >From: Hannes Tschofenig <[email protected]> > > > >.... > > > >It is not clear to me what the threats are. > > > >Just as an example: Why would someone want to sent a client fake ALTO > >information or impersonate a server? What would be their benefit? > > One reason for spoofing an ALTO server would be to divert clients from > legitimate servers to the spoofer's fake server. But I don't see any way a > spoofer can do that with the ALTO protocol.
Depending on the network scenario and depending on whether the attacker is a "regular user" or has administrative access to the access network equipment, one could try sending forged DHCP replies in an Ethernet, try some DNS poisoning, install a transparent HTTP proxy that does some modifications, etc. > The only person I can see spoofing an ALTO server would be a 13-year-old > brat [I'm talking emotional, not physical age!] who thinks it's fun to > "pessimize" the network. That is, tie the network in knots by getting > users to download movies from servers on the other side of the world, > instead of ones around the corner. In the P2P use case the underlying assumption why both network operator and user would want to use ALTO is the expectation of a win-win situation: user gets better application performance, operator gets reduced network infratructure utilization. A network operator providing an ALTO server might be tempted to "apply policies based on criteria other than network efficiency. For example, the service provider may suggest routes suboptimal from the user's perspective in order to avoid peering points regulated by inconvenient economic agreements." [RFC 5693]. If a user suspects such behavior (s)he might want to switch to another ALTO server provided by an "independent organization" (see AR-20 and AR-21 in RFC 6708). The operator in turn might try to redirect queries to external ALTO servers to the operator's ALTO server or try to tamper with their responses, if there is no authentication. Fake ALTO guidance (e.g., highly prefer a small address range or a single address) might be useful for turning a distributed application into a DDoS tool with the fake ALTO server as control center - interesting not only for 13-year-olds. Compromising the ALTO server discovery procedure and impersonating the ALTO server could be used to break confidentiality (see below) even if no messages are changed. > I can see a client faking authentication *if* that ALTO server gives out > highly detailed, sensitive network cost data to a few, selected, trusted > clients. But I think those ALTO servers will be the exception. I expect > most ALTO servers will be run as a public service, available to anyone. > > >Do you need confidentiality protection of the exchange between the client > >and the server? Would you consider the information that the server > >provides as public information? > > I expected most of that data to be public! To hide sensitive data, an ALTO > provider would use course-grained pids, and perhaps ordinal costs. > > As for confidentiality client queries, the endpoint-cost request indicates > that this client is interested in a specific set of servers. The client > might want to keep that interest private (eg, suppose they're porn > servers). But if I were worried about that, I'd be more worried that the > ALTO server would sell my profile to the highest bidder. And encryption > would do a thing to prevent the ALTO server from doing that. > > BTW, a client who's worried about that can download the full network & > cost maps. Then no one can tell what servers the client is interested in. right. for more threat scenarios see RFC 6708, Sec. 5.2. -- Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
