Subject: Re: [alto] Hannes security questions

From: Wendy Roome <[email-masked]>
Date: Mon, 11 Mar 2013 10:06:53 -0400

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-masked]>
>
>....
>
>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.

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.

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.

>I don't understand from the reading whether client authentication
>functionality has to be provided or not. It is too fuzzy; you cannot
>develop an interoperable based on the current description. There are many
>ways to do client authentication and there is always the question about
>key management.

I assumed authentication would be based on a name in the (properly signed)
certificate that the client presents to the ALTO server.  The client has
to authorize that name via some unspecified path -- such as a phone call
between humans. :-)

	- Wendy

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 14 Mar 2013 23:36:30 +0100

Hi,

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

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

> 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