Subject: [apps-discuss] APPs team review of draft-ietf-alto-reqs-11

From: Ted Hardie <[email-masked]>
Date: Thu, 15 Sep 2011 12:17:18 -0700

I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team). Please
resolve these comments along with any other Last Call comments you may
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-alto-reqs-11
Reviewer: Ted Hardie
Review Date: September 15, 2011

Summary:

I believe that this document needs further work before publication as an
Informational RFC.

Major Issues:

Section 5.2.1 on Classification of Information Disclosure Scenarios
has no scenarios relating to the user privacy aspects of disclosure.  There
is a great deal of work on the potential privacy threats related to
correlation of data; some reference to that threat, and any mitigation
available, seems required.  The privacy discussion in ARv11-49 also does
not discuss this, but it is a basic part of the risk here, since an ALTO
server
could theoretically see a much broader set of resource requests than
a single server.

Minor Issues:

REQ ARv11-8 says:

   ARv11-8: For host group descriptor types other than "IPv4
   address prefix" and "IPv6 address prefix", the host group descriptor
   type identification MUST be supplemented by a reference to a
   facility, which can be used to translate host group descriptors of
   that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping
   table or an algorithm.

I did not see a justification for this limitation here or in RFC 5693.
A host group identifier that contained, for example, an AS number
seems to be within the scope of the protocol (though admittedly harder
to populate in a query).  If this limitation is driven by an
underlying requirement, I believe it should be made explicit.  If this
is intended to be allowed under REQ. ARv11-13, then a forward pointer
that states that host group descriptors that are not immediately
mappable to IP addresses should be extended with a different type would be
useful.

[Though AS number may not seem to be immediately practical, it might
actually
be faster to populate in ALTO queries than the current external IP of
a NATted or double NATted host.  By identifying the AS, the ALTO
service provider may be able to identify peering and transit
relationships between resource providers and the node making the query--thus
helping
identify the appropriate choice. ]

In ARv11-12, the document is indicating that the preferences expressed
are relative, but it does not say whether they are pure ordinals or
whether they are weighted.  If this is not yet decided, that's fine.
But if the intent is to say that they are pure ordinals, it might be
good to make that explicit.  There's a lot of experience in CONNEG
contexts that says implementors will attempt to infer weights and
engage is some mighty dodgy math if this is not clear.

REQs ARv11-23 and ARv11-24, taken together, seem to implicitly require
that the two modes must be distinguishable, so that a client can avoid
sending targets to ALTO services that do not support them.  If this is
the case, an explicit statement of this in one of the two would be
useful.

ARv11-27 is unclear as to whether ALTO transactions populated only
with RFC1918 addresses are what must be supported or whether the
intent is integration with methods for determining external addresses.

The document currently says:

   In particular, as a simple way of achieving some basic form of
   throttling, an ALTO server MAY answer ALTO queries with a "Retry
   After: {point in time | time delta}" message.  This "Retry After" MAY
   be sent as part of the ALTO reply together with the requested guiding
   information, or as a standalone (error) message not giving the
   requested guidance.

The first form creates an implicit requirement for a synchronized
clock, which should either be made explicit or eliminated in favor of
the second form.

REQ. ARv11-47 is not clear on the threat being addressed, so it is not
clear whether the messages themselves must be encrypted or encryption
of the hop-by-hop transport is sufficient.  Some clarification would
be useful.

In REQ. ARv11-50, the document says:

   An ALTO server MUST provide adequate guidance even if the ALTO
   client prefers not to specify the desired resource (e.g., keeps the
   data field empty).

Depending on the data distribution method, this may not be possible.
I assume that this is meant to cover only target cases where both the
resource and target host are mentioned.  It would be helpful to
clarify this.

Editorial:

I believe the abstract is difficult to parse.  I personally would find
something like the following more readable:

Certain resources, such as pieces of information or server processes,
are available from multiple hosts on the network.  Applications which
access those resources currently have no guidance on the likely
performance of different potential sources.  The goal of ALTO is to
provide guidance for selecting among candidates sources to
applications consuming multiply homed resources.  This guidance shall
be based on parameters that affect performance and efficiency of the
data transmission between the hosts, e.g., the topological distance.
The ultimate goal is to improve performance (or Quality of Experience)
in the application while reducing resource consumption in the
underlying network infrastructure.

The Introduction says:

   The logical entities that provide the ALTO service do not take part
   in the actual user data transport, i.e., they do not implement
   functions for relaying user data.  They may be placed on various
   kinds of physical nodes, e.g., on dedicated servers, as auxiliary
   processes in routers, on "trackers" or "super peers" of a P2P
   application, etc.

I believe the phrase "logical entities" here is meant to imply that
these functions are separable and that there is no necessary
relationship between the entities providing the ALTO service and those
providing the access to resources.  If this is the case, some
clarification may be useful.

In section 2.3, I originally read the "see section 2.2" as refering to
section 2.2 of RFC 5693 (see section 2.2. above) would be mildly
better.  Since there is no Section 2.2 in RFC 5693, though, this is a
self-correcting problem.

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 20 Sep 2011 11:42:29 +0200

Ted,

thanks for the extensive review. See comments and some questions inline.

Please note: I have adjusted the mail's recipient list, in order to
catch all authors.

Thanks,
Sebastian

On Thu, Sep 15, 2011 at 09:17:18PM +0200, Ted Hardie wrote:
> I have been selected as the Applications Area Review Team reviewer for
> this draft (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> I believe that this document needs further work before publication as
> an Informational RFC.
> 
> Major Issues:
> 
> has no scenarios relating to the user privacy aspects of disclosure.

We believe that the privacy concerns from the user's point of view boil
down to what we call "Disclosure of the application behavior to ..."
"... the ALTO server" (case 2 in Section 5.2.1) or "... to an
unauthorized third party" (4).

This follows the logic that at least in the P2P file sharing scenario
(which was the first use case for ALTO) it's the users that run the
application overlay and therefore their privacy concerns are about
not disclosing the application behavior (e.g., who is sharing which
files with whom).

Should we add a note or clarification about that?
Or are you missing a completely different aspect of privacy (which?)?

> There is a great deal of work on the potential privacy threats related
> to correlation of data; some reference to that threat, and any
> mitigation available, seems required.  The privacy discussion in
> ARv11-49 also does not discuss this, but it is a basic part of the
> risk here, since an ALTO server could theoretically see a much broader
> set of resource requests than a single server.

The main countermeasure against the abovementioned concerns is to
use the target-independent query mode (see last paragraph on page 18).
ARv11-49 is just an addtional measure, in particular if someone
needs to use the target-aware query mode.

*****
> to populate in a query).

We all agree that somtimes, for a network operator it may be easier
to express preferences using host group descriptor types other
than IP addresses. AS numbers are on obvious example, maybe also
cell IDs in cellular mobile networks. However, at the end of the
day, an application does a connect() to an IP address, and therefore
needs guidance expressing preferences wrt. IP addresses. It is
(or at least was, at some point in time) consensus in the WG
that the complexity of mapping AS numbers to IP addresses should
be server-side, not client-side.

> If this limitation is driven by an underlying requirement, I believe
> it should be made explicit.

I think "complexity should be server-side" is not really a hard
underlying requirement, it's more sort of a collective gut feeling
that this makes deployment and interoperability easier. If a network
operator prefers to express his network topology using whatever
description language that's fine, but it should not require the
application (with the embedded ALTO client) to implement additional
code or acquire additional knowledge.

> If this is intended to be allowed under REQ. ARv11-13, then a forward
> pointer that states that host group descriptors that are not
> immediately mappable to IP addresses should be extended with a
> different type would be useful.

Extensibility of host group descriptors is covered in ARv11-6.
I do not see the relation to ARv11-13.

> actually be faster to populate in ALTO queries than the current
> external IP of a NATted or double NATted host.

How would an ALTO client located behind a NAT reliably find its
own AS number and the AS numbers of all candidate resource providers?

> By identifying the AS,
> the ALTO service provider may be able to identify peering and transit
> relationships between resource providers and the node making the
> query--thus helping identify the appropriate choice. ]

The ALTO requirements draft does not prevent anyone from using AS
numbers inside the ALTO server and on the interface through which
network topology information is loaded into the ALTO server (said
interface is out of the scope of current WG standardization activities).
In fact, we cannot prevent anyone from doing so, and as said above,
it may make sense to do so.

The ALTO requirements draft does not even prevent you from using AS
numbers within the ALTO client protocol. All it says is that if you
decide to expose AS numbers to the clients, you MUST provide a
(reference to a) mechanism for mapping to/from IP addresses (ARv11-8).

Does this make sense to you?

> whether they are weighted.  If this is not yet decided, that's fine.

The WG was not interested in deciding and freezing this at the
requirements level. The only "official" (i.e., WG document)
protocol specification does distinguish between ordinal and numerical
cost modes.

> the case, an explicit statement of this in one of the two would be

Is there a strong reason why a client should do some kind of capability
query and avoid sending unsupported query types? Of course, it's more
efficient ...

The WG's protocol spec does support this capability query, but do we
need to go back to the WG, ask for consensus and freeze that at the
requirements level?  I assume that we do not have to explicitly state
that if some protocol feature is optional, there must be *some kind* of
graceful handling if one party does not support it (RFC 2119 already
talks about the implications of optional features).

> intent is integration with methods for determining external addresses.

The intent of ARv11-27 is to say that the "exchange of ALTO
transactions" must work through NAT, i.e., a transport issue.
For example, we do not want to have FTP-style back-connects to
random port numbers.

There is no intention to make any statement here about the semantics
of queries/responses accross the boundary of address realms.

Would "transport of ALTO transactions" be clearer? Any other
proposal for a wording?

> clock, which should either be made explicit or eliminated in favor of

The intent of this note is to state that using HTTP with its retry-after
header (RFC 2616, sec. 14.37) as an underlying protocol layer satisfies
the requirement. And HTTP defines both point in time and time delta,
AFAIR without discussing synchronized clock issues.

> of the hop-by-hop transport is sufficient.  Some clarification would

At this requirements level, we do not have a clear architecture
in mind, e.g., is there such a thing as a proxy? Therefore, it is
diffcult to discus hop-by-hop vs. end-to-end encryption. The requirement
is here to force authors of a concrete specification to think about this
issue...

> resource and target host are mentioned.  It would be helpful to

Not neccessarily. There could be ALTO queries

"give me a sorted list of IP prefixes that are expected to give
better-than-average performance if I connect to a peer therein"

and

"give me a sorted list of IP prefixes that are expected to give
better-than-average performance if I connect to a peer therein,
and, by the way, I am going to watch TV channel ABC over p2p
live streaming protocol XYZ."

The req. says that also the first query should give some
reasonable result.

> providing the access to resources.  

right. furthermore, an ALTO server is not necessarily a separate
physical box.

> If this is the case, some clarification may be useful.

Could you please propose text? What exactly needs to be clarified?

> better.  Since there is no Section 2.2 in RFC 5693, though, this is a

ACK.

Thanks again for the extensive review.

   -- Sebastian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Sep 2011 10:13:40 +0200

Hi Sebastian,

Thanks for your message, some responses inline.

> Or are you missing a completely different aspect of privacy (which?)?
I think the newcomer to ALTO may have difficulty teasing out what you mean
by application behavior.  I certainly did not read it to mean "privacy
sensitive user data".  I believe it would be better list this requirement
with reference to what is disclosed rather than in terms of application
behavior.

> needs to use the target-aware query mode.
Assuming you mean the last paragraph of 17, it begins:

The disclosure of candidate resource providers' addresses to the ALTO
   server can be avoided by allowing ALTO clients to use the target-
   independent query mode.

This issue here is not disclosure of resource providers' address, but
disclosure of the queries themselves.  Aggregating data about the queries
issued allows you to correlate data about the user issuing the queries;
that's the privacy issue I mentioned.

> be server-side, not client-side.
I think the requirement language may be misleading here.  Your explanation
makes
it sound like the goal here is: "No matter what host descriptor type is
used, the
service should return candidate IP addresses".   The way I originally read
it, it sounded like:
"Any host descriptor must have a well-known mapping to an IP address before
it can
be used."  Some clarification may be needed if the first is your goal.

> code or acquire additional knowledge.
Acquiring additional knowledge (e.g. the external IP bound to my NATted
internal IP) may
be necessary in some cases.  Forbidding at a protocol level that this could
not be
some other piece of additional knowledge does not seem justified by the text
in
this document or the 5693; as a baseline, I heartily agree--but you are
circumscribing
extensibility  here.

Just my personal opinion, of course.

> I do not see the relation to ARv11-13.
I wondered whether ARv11-13 might cover descriptors that did not fall
into ARv11-6.  Thank you for the clarification.

> protocol specification does distinguish between ordinal and numerical
Thanks for the clarification; it might be useful to say something like
"Protocol specifications should indicate whether preferences expressed are
 ordinal or weighted", but if the protocol specification already does so,
this
may not be required.

> talks about the implications of optional features).
Frankly,  publishing protocol requirements when the spec is already
developed all too often results in exactly this:  rejiggering the
requirements to match the
protocol already developed or in development.  Please work with your AD on
whether
this is something that would be valuable.

> Would "transport of ALTO transactions" be clearer? Any other
I believe so, yes.

> AFAIR without discussing synchronized clock issues.
The RFC 2616 method also implies the need for a synchronized clock at a
resolution of one second, at least in my view.

> is here to force authors of a concrete specification to think about this
If you do not have a threat model in mind, it is not clear to me what
justification you have for this requirement at all.  Required security
mechanisms should be matched against a threat; if you don't know what you're
protecting from whom, claiming that encryption of some sort is required at
some point seems less than useful.

> better-than-average performance if I connect to a peer therein"
Well, personally, it is hard to see how this is a useful response if the
result is that I connect to a peer within that prefix but that node must
make
onward connections to retrieve the resources I need.  In some data
distribution
methods, that seems a likely result.  But this turns on what you mean
by "adequate guidance".  I assumed, apparently wrongly, that this meant
adequate guidance on transfer performance.  But if this is adequate guidance
on peer connectivity/speed, then this requirement may make more sense.
Some clarification of what "adequate guidance" means (that is guidance about
what)
would be useful.

> Could you please propose text? What exactly needs to be clarified?
I believe it would be useful to recast this in functional terms, but I have
not proposed text.

> Thanks again for the extensive review.
Thank you for your responses.  I believe that working with your AD on the
next steps is appropriate.  As I
said above, my personal view is that time spent on requirements documents
once the protocol specification is done or well on its way may not be the
best use of a WG's time.  How much effort you should spend on these
clarifications is a matter for the WG and ADs to work through.

regards,

Ted