Subject: [alto] Security

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Mar 2013 18:49:21 +0200

Hi all, 

I just read through the security consideration section of http://tools.ietf.org/html/draft-ietf-alto-protocol-14 and it raised some questions for me. 

As someone who has not followed the work closely I unfortunately have to say that I do not understand why you came up with the current security solution. 

It is not clear to me what the threats are. 

Just as an example: Why would someone want to sent a client fake ALTO information or impersonate a server? What would be their benefit? If they do that wouldn't it be easier to then attack the discovery mechanism? What is the relationship between the client and the server? Is it always dynamically discovered or are there cases where the client has an ALTO server address pre-configured?  

Do you need confidentiality protection of the exchange between the client and the server? Would you consider the information that the server provides as public information?

There is text about denial of service attacks but that is not really core to the topic since the usage of TLS will likely make the DoS vulnerable worse. The reference to SIP puzzles is misleading (since you are not using SIP nor cryptographic puzzles in TLS). 

I don't understand from the reading whether client authentication functionality has to be provided or not. It is too fuzzy; you cannot develop an interoperable based on the current description. There are many ways to do client authentication and there is always the question about key management. 

Ciao
Hannes

PS: Please stop using the term SSL since it shows that you have no idea about security. SSL was the precursor to TLS; the work on TLS (of the different versions) had fixed security vulnerabilities of SSL. Have a look at the Wikipedia to get a brief summary of the history: http://en.wikipedia.org/wiki/Transport_Layer_Security

---

From: Richard Alimi <[email-masked]>
Date: Tue, 12 Mar 2013 22:33:28 -0700

Hi Hannes,

Thank you for the feedback. Replies inline...

On Wed, Mar 6, 2013 at 8:49 AM, Hannes Tschofenig <[email-masked]
> wrote:

> Hi all,
>
> I just read through the security consideration section of
> http://tools.ietf.org/html/draft-ietf-alto-protocol-14 and it raised some
> questions for me.
>
> As someone who has not followed the work closely I unfortunately have to
> say that I do not understand why you came up with the current security
> solution.
>
> Just as an example: Why would someone want to sent a client fake ALTO
> information or impersonate a server? What would be their benefit? If they
> do that wouldn't it be easier to then attack the discovery mechanism?

Section 13.2 currently states:

   Applications using the information must be cognizant of the
   possibility that the information is malformed or incorrect.  Even if
   an ALTO Server has been properly authenticated by the ALTO Client,
   the information provided may be malicious because the ALTO Server and
   its credentials have been compromised (e.g., through malware).  Other
   considerations (e.g., relating to application performance) can be
   found in Section 6 of [RFC5693]
<http://tools.ietf.org/html/rfc5693#section-6>.

This references the ALTO Problem Statement draft which describes some
reasons an attacker may want to do this.  We can make it clear that
this forward reference contains some example attacks.

The draft also has this text in the Manageability Considerations section:

   Operators providing an ALTO Server should ensure that appropriate
   information is being exposed.  Privacy implications for ISPs are
   discussed in Section 13.1
<http://tools.ietf.org/html/draft-ietf-alto-protocol-14#section-13.1>.
 Both operators and ALTO Servers and those
   using ALTO Clients should be aware of the impact of incorrect or
   faked guidance (see Section 10.3 of [I-D.ietf-alto-deployments
<http://tools.ietf.org/html/draft-ietf-alto-protocol-14#ref-I-D.ietf-alto-deployments>]
and
   future versions of that document).

As far as attacking the discovery mechanism, yes an attacker may wish to do
that.  I believe that something that should be addressed in the
server-discovery document (and its security considerations) but not in the
protocol document.

Does this answer your questions?

Looking at those two pointers again, we should probably clean this up such
that Section 13.2 also points to draft-ietf-alto-deployments, and the
Manageability Considerations section points to the 13.2.

What is the relationship between the client and the server? Is it always
> dynamically discovered or are there cases where the client has an ALTO
> server address pre-configured?
>

These are a few relationships that have been discussed in the past:
(1) ALTO Client a part of an application used by a subscriber of an ISP,
and the ISP may host an ALTO server
(2) Business relationship between peering ISPs (one has the ALTO server and
another has the ALTO client)
(3) CDN provider using an ALTO client to subscribe to information about an
ISPs network (the ISP managing the ALTO server)

I can see cases where an ALTO client may manually configure the address of
an ALTO server, particularly for (2) or (3).

> Do you need confidentiality protection of the exchange between the client
> and the server? Would you consider the information that the server provides
> as public information?
>

I think it depends on the deployment scenario.  I could imagine that the
exchange between two peering ISPs would be confidential, while a
public-service ALTO server that pieces together information from public
datasources like BGP looking glasses may not need to be (though a client
may desire it to be, depending on what it's using it for).  There is
already a thread about exactly how to word this requirement, so let's leave
discussion of this to that thread.

>
> There is text about denial of service attacks but that is not really core
> to the topic since the usage of TLS will likely make the DoS vulnerable
> worse. The reference to SIP puzzles is misleading (since you are not using
> SIP nor cryptographic puzzles in TLS).
>

Can you clarify here?  Are you suggesting to drop the text about Denial of
Service, or to extend it to note that use of TLS may make it worse?

I think we can remove the reference to draft-jennings-sip-hashcash.

>
> I don't understand from the reading whether client authentication
> functionality has to be provided or not. It is too fuzzy; you cannot
> develop an interoperable based on the current description. There are many
> ways to do client authentication and there is always the question about key
> management.
>

In your view, how much of this belongs in the ALTO protocol draft versus
the ALTO Deployment Considerations draft (draft-ietf-alto-deployments)?

When revising the statement about TLS support we can also revise exactly
which features are required to support the base protocol.  My personal view
is that server-authentication, message integrity, and confidentiality would
be required but that client-authentication can be optional.

Question (to anyone): looking at the RFCs cited by Michael (
http://www.ietf.org/mail-archive/web/alto/current/msg01759.html), I don't
see any of them expanding on the particular TLS mechanisms used (e.g., key
management, how client certs are provided, etc).  Are there any examples we
can work off of to understand how other WG's have tackled this?

Thanks,
Rich

>
> Ciao
> Hannes
>
> PS: Please stop using the term SSL since it shows that you have no idea
> about security. SSL was the precursor to TLS; the work on TLS (of the
> different versions) had fixed security vulnerabilities of SSL. Have a look
> at the Wikipedia to get a brief summary of the history:
> http://en.wikipedia.org/wiki/Transport_Layer_Security

Thanks. We'll update the text.

>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 14 Mar 2013 22:03:29 +0100

One small comment below

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Richard Alimi
> Sent: Wednesday, March 13, 2013 6:33 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [alto] Security

[...]

> <http://tools.ietf.org/html/draft-ietf-alto-protocol-14#sectio
> n-13.1> .  Both operators and ALTO Servers and those
> <http://tools.ietf.org/html/draft-ietf-alto-protocol-14#ref-I-
> D.ietf-alto-deployments> ] and
> As far as attacking the discovery mechanism, yes an attacker 
> may wish to do that.  I believe that something that should be 
> addressed in the server-discovery document (and its security 
> considerations) but not in the protocol document.

Section 6.1 http://tools.ietf.org/html/draft-ietf-alto-server-discovery-07 has some text on this attack. One could refer to that from the protocol draft security considerations.

Michael

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 14 Mar 2013 22:43:21 +0100

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 14 Mar 2013 23:55:04 -0400

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

---------------

   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.
--------------------------------------------------

---

From: Richard Alimi <[email-masked]>
Date: Fri, 15 Mar 2013 23:22:07 -0700

Very good!  A couple of small things inline:

> Thanks a lot and see you tomorrow!

s/in HTTP/in TLS/
s/HTTPs/TLS/

>    the identify of ALTO Servers.

Maybe reference RFC6125 for verifying server certificates.

>     ALTO Information Resources can be sensitive information that can

s/that can pose risks/that can pose risks if exposed to unauthorized
parties/

>     information to mount effect attacks such as focusing on high-cost

s/mount effect/mount/
  or
s/mount effect/mount effective/

>    mandatory details of information disclosure, and hence the Provider

s/ALTO does not presume mandatory details/ALTO does not require any
particular level of/

>    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

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.

>    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
>    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.

>    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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 16 Mar 2013 14:26:57 -0400

Good edits. Please see below.

>>    in HTTP. In particular, the ALTO Protocol requires that HTTPs MUST

Good suggestion. Please see below on the revised para.

> 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)

> s/that can pose risks/that can pose risks if exposed to unauthorized
Fixed.

> s/mount effect/mount effective/

Revised to "mount effective".

> s/ALTO does not presume mandatory details/ALTO does not require any
Revised as suggested.

> 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).

> 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.

> and processes these addresses.
Changed. see below.

> 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.

> 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

---

From: Sebastian Kiesel <[email-masked]>
Date: Sun, 17 Mar 2013 21:56:25 +0100

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.

      [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

   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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 18 Mar 2013 00:20:53 -0400

Sebastian,

Thanks a lot! Please see below.

> 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.

> propose to split 13.4. into two subsections, as two different aspects
The split is great, as the second did included two considerations and I
like the reordering (below) as well.

>    endpoint property service, to which the user sends the IP addresses of

How about we say "endpoint property and endpoint cost services"?

>       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.  Availability of the ALTO Service
I think the ordering is good and will revise to it.

> 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

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 18 Mar 2013 08:20:22 +0100

Richard,

please see inline

> considered in an extension document.

Very good.  "We leave it open for the future" sounds even better than 
"so far we didn't bother"  :-)

> How about we say "endpoint property and endpoint cost services"?

Right. It may also apply to the map filtering service, if you request
very fine-grained filters.

> Yes. Filtered map can be used to emulate endpoint cost service. We will

OK, great.

> How about "Undesirable Guidance from Authenticated ALTO Server"?

OK, that's better.

> >    preferrable ones remain idle.

Should we add a "(see alsoe AR-14 in RFC 6708)"  at the end of the last
sentence?!  I think we can never say too often that ALTO is neither
admission control nor centralized congestion control.

> be handled by TLS negotiation according to best practices. What do you

What I wanted to say: In my first proposal, I had three subsections
for every protection goal.  Their headings were still worded clumsy but
the idea was:

13.x.1 Risk Scenarios
13.x.2 Protection Strategy
13.x.3 Protection Mechanisms and Configuration Guidelines

with "Protection Strategy" as a high-level discussion which mechansims
(e.g., encryption) can solve the problems at which cost, leaving which
issues open, etc.  and "Protection Mechanisms and Configuration
Guidelines" containing very specific guidance how to implement and
configure these mechanisms.

Most of the text we have so far goes into the "Risk Scenarios" and
"Protection Strategy" subsections. So I'd like to propose now to
rename our existing "Protection Mechanisms" sections to "Protection
Strategy"

Regarding "Protection Mechanisms and Configuration Guidelines"
in general and TLS ciphersuites in particular: Maybe it is better to
omit the 13.x.3 subsections completely, as this is indeed a 
moving target while RFCs last "forever". 

Given that our base protocol HTTP is extremely widespread I assume that
there will be Best Current Practices how to secure it for very many
years to come.  So a rather generic reference to BCPs might be better in
the long-term than a detailed elaboration of today's state of the art.

What about:

Software engineers developing and operators deploying ALTO must make
themselves familar with up-to-date Best Current Practices how to secure
HTTP against these types of attacks.

This kind of sentence still could go in the respective 
"Protection Strategy" subsection, i.e., no need to open a separate
"Protection Mechanisms" subsection.

Thanks
Sebastian

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 18 Mar 2013 15:08:13 -0400

Hi Sebastian,

Please see below.

> very fine-grained filters.
Added this as an example as well.

> admission control nor centralized congestion control.

Good idea. Added a reference to AR-14 for more considerations.

> Agreed. Revised to this structure.

Thanks a lot!

Richard