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

[Ted Hardie <[e-mail]>]

Hi Sebastian,

Thanks for your message, some responses inline.

On Tue, Sep 20, 2011 at 11:42 AM, Sebastian Kiesel <[e-mail]>wrote:

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



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


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


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




> > 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.
>
>
I wondered whether ARv11-13 might cover descriptors that did not fall
into ARv11-6.  Thank you for the clarification.



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


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




> > 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?
>
>
I believe so, yes.

>
> > 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.
>
>
>
The RFC 2616 method also implies the need for a synchronized clock at a
resolution of one second, at least in my view.



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



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


> 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?
>
>
I believe it would be useful to recast this in functional terms, but I have
not proposed text.


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





>   -- Sebastian
>