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

[Sebastian Kiesel <[e-mail]>]

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


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.


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

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.

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

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?


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

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.


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

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


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


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

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.


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

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


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

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.


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

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?


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

ACK.



Thanks again for the extensive review.

   -- Sebastian