Good edits. Please see below. On Saturday, March 16, 2013, Richard Alimi wrote:
> > >> 13.1.3. Protection Mechanisms >> >> ALTO protects authenticity and integrity of ALTO Information >> Resources by leveraging the authenticity and integrity mechanisms >> in HTTP. In particular, the ALTO Protocol requires that HTTPs MUST >> > > s/in HTTP/in TLS/ > s/HTTPs/TLS/ > Good suggestion. Please see below on the revised para. > > >> be supported, to protect authenticity and integrity of ALTO >> Information Resources. Server certificates will be used to verify >> the identify of ALTO Servers. >> > > Maybe reference RFC6125 for verifying server certificates. > > ALTO protects authenticity and integrity of ALTO Information (both Information Directory and individual Information Resources) by leveraging the authenticity and integrity mechanisms in TLS. In particular, the ALTO Protocol requires that HTTP over TLS MUST be supported, to protect authenticity and integrity of ALTO Information. For server certificates, the rules and guidelines defined in [RFC6125] apply. But the preceding spec may not be complete, as we may want to consider more details on URI etc (see http://tools.ietf.org/html/rfc6125#section-3) > >> 13.1.4. Limitations >> >> A deployment scenario may require redistribution of ALTO >> information to improve scalability. When authenticity and >> integrity of ALTO information are still required, then ALTO Clients >> obtaining ALTO information through redistribution must be able to >> validate the received ALTO information. Support for this >> validation is not provided in this document, but may be provided by >> extension documents. >> >> 13.2. Confidentiality of ALTO Information Resources >> >> 13.2.1. Risk Scenarios >> >> Although in many cases ALTO Information Resources may be regarded >> as non-confidential information, there are deployment cases where >> ALTO Information Resources can be sensitive information that can >> pose risks. >> > > s/that can pose risks/that can pose risks if exposed to unauthorized > parties/ > > Fixed. > >> For example, an attacker may infer details regarding the topology, >> status, and operational policies of a network through the Network >> and Cost Maps. As a result, a sophisticated attacker may be able >> to infer more fine-graind topology information than an ISP hosting >> an ALTO server intends to disclose. The attacker can leverage the >> information to mount effect attacks such as focusing on high-cost >> links. >> > > s/mount effect/mount/ > or > s/mount effect/mount effective/ > Revised to "mount effective". > > >> >> Revealing some endpoint properties may also reveal additional >> information than the Provider intended. For example, when adding >> the line bitrate as one endpoint property, such information may be >> potentially linked to the income of the habitants at the network >> location of an endpoint. >> >> In [RFC6708] Section 5.2.1, three types of risks associated with >> the confidentiality of ALTO Information Resources are identified: >> risk type (1) Excess disclosure of the ALTO server operator's data >> to an authorized ALTO client; risk type (2) Disclosure of the ALTO >> server operator's data (e.g., network topology information) to an >> unauthorized third party; and risk type (3) Excess retrieval of >> the ALTO server operator's data by collaborating ALTO clients. >> >> 13.2.2. Protection Mechanisms >> >> To address risk type (1), the Provider of an ALTO Server must be >> cognizant that the network topology and provisioning information >> provided through ALTO may lead to attacks. ALTO does not presume >> mandatory details of information disclosure, and hence the Provider >> > > s/ALTO does not presume mandatory details/ALTO does not require any > particular level of/ > > Revised as suggested. > should evaluate how much information is revealed and the associated >> risks. >> >> To address risk type (2), the ALTO Protocol requires that HTTPs >> MUST be supported, to protect confidentiality, in addition to >> authenticity and integrity of ALTO Information Resources. In >> addition, the ALTO Protocol requires that HTTP Digestion >> > Authentication MUST be supported to address ALTO Client >> Authentication to limit the parties with whom ALTO information is >> directly shared. >> > > Should we reword this to indicate "client authentication" instead > of prescribing a particular technique? > How about the following spec: To address risk type (2), the ALTO Protocol need confidentiality. Since ALTO requires that HTTP over TLS MUST be supported, the confidentiality mechanism is provided by HTTP over TLS. For deployment scenarios where client authentication is desired to address risk type (2), ALTO requires that HTTP Digestion Authentication MUST be supported to achieve ALTO Client Authentication to limit the parties with whom ALTO information is directly shared. Depending on the use-case and scenario, an ALTO server may apply other access control techniques to restrict access to its services (see [I-D.ietf-alto-deployments] for a more detailed discussion on this issue). > >> Depending on the use-case and scenario, an ALTO >> server may apply other access control techniques to restrict access >> to its services (see [I-D.ietf-alto-deployments] for a more >> detailed discussion on this issue). >> >> To address risk type (3), the Provider of the ALTO Server must >> evaluate the joint information that may be leaked and the >> associated risks. >> >> 13.2.3. Limitations >> >> ALTO Information Providers should be cognizant that encryption only >> protects ALTO information until it is decrypted by the intended >> ALTO Client. Digital Rights Management (DRM) techniques and legal >> agreements protecting ALTO information are outside of the scope of >> this document. >> >> In order to limit access to an ALTO server (e.g., for an ISP to >> only allow its users to access its ALTO server, or to prevent >> Denial-of- Service attacks by arbitrary hosts from the Internet), >> an ALTO server may employ access control policies. >> >> 13.3. Availability of the ALTO Service >> >> 13.3.1 Risk Scenarios >> >> An attacker may want to disable ALTO Service as a way to disable >> network guidance to large scale applications.In particular, queries >> which can be generated with low effort but result in expensive >> workloads at the ALTO Server could be exploited for >> Denial-of-Service attacks. For instance, a simple ALTO query with >> n Source Network Locations and m Destination Network Locations can >> be generated fairly easily but results in the computation of n*m >> Path Costs between pairs by the ALTO Server (see Section 5.2). >> >> 13.3.2 Protection Mechanisms >> >> ISPs should be cognizant of the workload at the ALTO Server >> generated by certain ALTO Queries, such as certain queries to the >> Map Filtering Service and Ranking Service. One way to limit >> Denial-of-Service attacks is to employ access control to the ALTO >> server. The ALTO server can also indicate overload. Yet another >> possible mechanism for an ALTO Server to protect itself against a >> multitude of computationally expensive bogus requests is to demand >> that each ALTO Client to solve a computational puzzle first before >> allocating resources for answering a request (see, e.g., >> [I-D.jennings-sip-hashcash]). The current specification does not >> use such computational puzzles, and discussion regarding tradeoffs >> of such an approach would be needed before including such a >> technique in the ALTO Protocol. >> > > One thing Hannes mentioned was removing the reference to computational > puzzles. I tend to agree with that. If we figure out that its needed > later, it can always be mentioned in an extension document. > > I agree as well. Here is the revision: ISPs should be cognizant of the workload at the ALTO Server generated by certain ALTO Queries, such as certain queries to the Map Filtering Service and Ranking Service. One way to limit Denial-of-Service attacks is to employ access control to the ALTO Server. The ALTO Server can also indicate overload. Additional techniques such as using computational puzzles may be considered in an extension document. > >> ISPs should also leverage the fact that the the Map Service allows >> ALTO Servers to pre-generate maps that can be useful to many ALTO >> Clients. >> >> 13.4. User Protection using ALTO Services >> >> 13.4.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." >> >> The ALTO Service also makes it possible for an ALTO Server to track >> user behaviors and communication patterns, in particular when ALTO >> Clients reveal Network Location Identifiers (IP addresses or >> fine-grained PIDs) to the ALTO Server. >> > > Perhaps we can make this more specific to certain areas of the protocol. > Maybe something like: "The ALTO Protocol provides mechanisms in which a > client can send Network Location Identifiers to the ALTO Server. Clients > should be cognizant that behavior could be tracked if an ALTO server stores > and processes these addresses. > > Changed. see below. > An attacking ALTO Server >> may collect information from multiple client queries to deduce >> additional application/content information through correlation. >> > > How about starting this with "It is possible for an ALTO server to.." > When I first read this, it sounded a bit like the specification language > saying that we are suggesting for ALTO servers to do this. > > Good suggestion: The ALTO Protocol also provides mechanisms in which a client can send Network Location Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, and such client information may lead to client privacy risks if an ALTO Server stores and processes such information in order to deduce client behaviors and communication patterns. The ALTO Server may try to deduce additional application/content information by correlating queries collected from multiple clients. > 13.4.2. Protection Mechanisms >> >> It is important to note there is no protocol mechanism to require >> conforming behaviors on applications using ALTO Information >> Resources. If a user suspects misleading ALTO Information >> Resources, (s)he might want to switch to another ALTO server >> provided by an "independent organization" (see AR-20 and AR-21 in >> RFC 6708). >> > > Is it only the user who would make this decision? It could also be the > ALTO client or the application using the ALTO client. (Ideally some > automated thing would catch this before the user noticed.) > Good suggestion. Changed to the following: To protect applications from misleading ALTO Information Resources, it is important to note that there is no protocol mechanism to require conforming behaviors on how applications use ALTO Information Resources. An application using ALTO may consider to include a mechanism to detetct misleading ALTO Information Resources. After such a detection, the application might want to switch to another ALTO server provided by an "independent organization" (see AR-20 and AR-21 in RFC 6708) or ignore ALTO Information Resources. To protect user privacy, an ALTO Client should be cognizant about potential ALTO Server tracking through client queries. An ALTO Client may 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. Thanks! Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
