Sebastian, Thanks a lot! Please see below.
On Sun, Mar 17, 2013 at 4:56 PM, Sebastian Kiesel <[email protected]>wrote: > 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. > > Agreed. Changed to The ALTO Server can also indicate overload. More advanced protection schemes such as computational puzzles [I-D.jennings-sip-hashcash] may be considered in an extension 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. > > The split is great, as the second did included two considerations and I like the reordering (below) as well. > 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 > How about we say "endpoint property and endpoint cost services"? > 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. ] > Mentioning zeroing out or randomizing the last few bits can be helpful. Yes. Filtered map can be used to emulate endpoint cost service. We will adapt this paragraph. > > > 13.5. Undesirable results from an authenticated ALTO server > How about "Undesirable Guidance from 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 > > I think the ordering is good and will revise to it. > 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) > > Protection Strategies is a better term indeed. Let's change to it. As you mentioned TLS with cipher x and key length y, I assume that the protocol spec will not specify it, as it will be a moving target and should be handled by TLS negotiation according to best practices. What do you think? Thanks a lot! Richard > > Thanks > Sebastian >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
