Hi Richard,
great job! This is a big step towards a structured security section.
I really like it. Of course, I have some more comments and suggestions :)
-----
In 13.3.2 the text about computational puzzles seems a bit too long
given that this is just some idea we didn't analyze and specify in
detail. I'm not an expert here but some googling suggests to me that
the cited sip draft has expired quite some time ago.
Maybe something like:
... The ALTO server can also indicate overload. More advanced protection
schemes such as computational puzzles [I-D.jennings-sip-hashcash] could
be used to guard expensive operations; however, no in-depth analysis and
specification of such mechanisms has been undertaken by this document.
-----
I'm having difficulties parsing the subsection heading
> 13.4. User Protection using ALTO Services
Is ALTO to be used for protecting users (users of what?)?
I guess the intention was something like:
13.4. Protection of users using ALTO services
although this reads terribly. Before we try to rephrase that, let me
propose to split 13.4. into two subsections, as two different aspects
are in there.
13.4. Privacy Protection for ALTO Users
13.4.1. Risk Scenarios
By analyzing the queries sent from an ALTO client, the ALTO server as
well as a third-party intercepting the message exchange could track user
behaviors and communication patterns. This is particularly true for the
endpoint property service, to which the user sends the IP addresses of
potential communication partners. For a more comprehensive
classification of risk scenarios, see cases 4, 5, and 6 in [RFC 6708],
Section 5.2.
13.4.2. Protection Mechanisms
To protect user privacy, an ALTO Client should consider the
possibility to rely only on Network Map for PIDs and Cost Map
amongst PIDs to avoid passing IP addresses of other endpoints
(e.g., peers) to the ALTO Server.
[FIXME : RFC 6708 proposes a further option for
the "target-aware query mode", which is the RFC 6708's name
for the Endpoint Property Service:
In the target-aware query mode, this issue can be
addressed by ALTO clients through obfuscating the identity of
candidate resource consumers, e.g., by specifying a broader
address range (i.e., a shorter prefix length) than a group of
hosts in question actually uses, or by zeroing out or randomizing
the last few bits of IP addresses. However, there is the
potential side effect of yielding inaccurate results.
... To my understanding the "zeroing out or randomizing the last
few bits of IP addresses" would work with the Endpoint Property
Service but not the idea of giving an address range instead of a
single IP address - please correct me if I'm wrong. Could the map
filtering service be used to emulate a blurred Endpoint Property
Service? If so, please adapt this paragraph accordingly. ]
13.5. Undesirable results from an authenticated ALTO server
13.5.1. Risk Scenarios
The ALTO Service makes it possible for an ALTO Provider to
influence the behavior of network applications. An ALTO Provider
may be hostile to some applications and hence try to use ALTO
Information Resources to achieve certain goals [RFC5693]:
"redirecting applications to corrupted mediators providing
malicious content, or applying policies in computing Cost Map based
on criteria other than network efficiency."
A related scenario is that an ALTO server could unintentionally
give "bad" guidance. If too many ALTO clients follow the guidance
without doing additional sanity checks and measurements, more
preferrable hosts and/or links could get overloaded while less
preferrable ones remain idle.
13.5.2. Protection Mechanisms
Applications that are able to establish several connections to
different resource providers at the same time (e.g., chunk-based
peer-to-peer file sharing applications) may select those by a mix of
ALTO-assisted and random selection. If throughput measurements do
not show "better-than-random" results for the resource providers
selected with ALTO support of if other evidence suggests misleading
ALTO Information Resources, a user might want to disable ALTO usage
or switch to another ALTO server provided by an "independent
organization". This holds in particular if the first ALTO server is
provided by the access network operator (see AR-20 and AR-21 in [RFC
6708]). An access network 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. Authentication and integrity
protection can at least detect such behavior (see
xref-to "Authenticity and Integrity of ALTO Information Resources").
-----
Assuming that you like the section split I proposed above, I'd like
to further propose re-ordering the sections:
13.1 Authenticity and Integrity of ALTO Information Resources
13.2. Undesirable results from an authenticated ALTO server
13.3. Confidentiality of ALTO Information Resources
13.4. Privacy Protection for ALTO Users
13.5. Availability of the ALTO Service
Maybe we should also rename the 13.?.2 Sections from
"Protection Mechanisms" to "Protection Strategies" as most of the
text is still rather high-level recommendations. Or use a
three-subsection design:
1. Risk secnarios (someone could be listening)
2. Protection Strategies (use encryption)
3. Protection Mechanisms and Guidelines (use TLS with cipher x and
minimum key length y)
Thanks
Sebastian
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
