Very good! A couple of small things inline:
On Thu, Mar 14, 2013 at 8:55 PM, Y. Richard Yang <[email protected]> wrote: > Hi Sebastian, > > Excellent comments! Considering your comments and suggestions, here is a > draft version of Section 13. Please take a look and give us comments. > > Thanks a lot and see you tomorrow! > > Richard > > > --------------- > 13. Security Considerations > > Some environments and use cases of ALTO require consideration of > security attacks on ALTO Servers and Clients. In order to support > those environments interoperably, the ALTO requirements document > [RFC6708] outlines minimum-to-implement authentication and other > security requirements. Below we consider the threats and protection > mechanisms supported by the ALTO Protocol. > > 13.1 Authenticity and Integrity of ALTO Information Resources > > 13.1.2. Risk Scenarios > > An attacker may want to provide false or modified ALTO Information > Resources or Information Resource Directory to ALTO Clients to > achieve certain malicious goals. As an example, an attacker may > provide false endpoint properties. For example, suppose that a > network supports an endpoint property named hasQuota which reports > if the endpoint has usage quota. An attacker may want to generate > a false reply to lead to unexpected charges to the endpoint. An > attack may also want to provide false Cost Map. For example, by > faking a Cost Map that highly prefers a small address range or a > single address, the attacker may be able to turn a distributed > application into a Distributed Denial of Service (DDoS) tool. > > Depending on the network scenario, an attacker can attack > authenticity and integrity of ALTO Information Resources using > various techniques, including, but not limited to, sending forged > DHCP replies in an Ethernet, DNS poisoning, and installing a > transparent HTTP proxy that does some modifications. > > 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/ > 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. > > 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/ > > 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/ > > 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/ > 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? > 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. > > 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. 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. > > 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.) > 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. > > 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. > -------------------------------------------------- > > On Thu, Mar 14, 2013 at 5:43 PM, Sebastian Kiesel <[email protected]>wrote: > >> Hi, >> >> I think the security considerations section in draft-ietf-alto-protocol-14 >> is indeed a big mess. I mean nothing what's written there is really >> wrong but it does not seem to be the result of a systematic analysis >> what our relevant threats and countermeasures are. >> >> We should try to give this section a systematic structure, probably >> based on the basic protection goals of almost any networked system. >> My proposal is: >> >> >> 13. Security Considerations >> >> 13.1. Authenticity and Integrity of ALTO queries and responses >> 13.1.1. Threat scenarios >> 13.1.2. High-level discussion of scenarios and protection mechanisms >> 13.1.3. Recommendations for configuration of specific protection >> mechanisms >> in the protocol >> >> 13.2. Confidentiality of ALTO queries and responses >> 13.2.1. Threat scenarios >> 13.2.2. High-level discussion of scenarios and protection mechanisms >> 13.2.3. Recommendations for configuration of specific protection >> mechanisms >> in the protocol >> >> 13.3. Availability of the ALTO service >> 13.3.1. Threat scenarios >> 13.3.2. High-level discussion of scenarios and protection mechanisms >> 13.3.3. Recommendations for configuration of specific protection >> mechanisms >> in the protocol >> >> >> >> >> >> For authenticity/integrity threat scenarios we already have some text in >> RFC 5693, Sec. 6 that could be cited or copied and refined. >> >> For confidentiality threat scenarios and discussion we have a rather >> extensive analysis in RFC 6708, Sec 5.2 that should be just cited. >> >> >> Just my $0.02 >> Sebastian >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
