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
be supported, to protect authenticity and integrity of ALTO
Information Resources. Server certificates will be used to verify
the identify of ALTO Servers.
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.
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.
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
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. 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.
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. An attacking ALTO Server
may collect information from multiple client queries to deduce
additional application/content information through correlation.
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). 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
>
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
be supported, to protect authenticity and integrity of ALTO
Information Resources. Server certificates will be used to verify
the identify of ALTO Servers.
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.
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.
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
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. 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.
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. An attacking ALTO Server
may collect information from multiple client queries to deduce
additional application/content information through correlation.
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). 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.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
