Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt

[Jensen Zhang <[e-mail]>]

Hi Richard and WG,

My opinion is to make such a decomposition optional. Because the
decomposition is not always possible, and the decomposition solution may
not be unique. It's hard to enforce it.

So I suggest we can add the following paragraphs to explain it:

===
An ALTO client should be aware that the entities in the response MAY be
different from ones it requests. If entities in the requested domain can be
inherited, the ALTO server MAY decompose a requested entity address into
several entities which could inherit it. One example is the Internet
Address domains: Considering a request for property P of entity A (e.g.,
ipv4:192.0.2.0/31), if P has value v1 for A1=ipv4:192.0.2.0/32 and v2 for
A2=ipv4:192.0.2.1/32, then the ALTO server could return the response
including entities A1 and A2, instead of the requested entity A. The ALTO
server could also return v1 for A1 and v2 for A, and the ALTO client can
also deduce v2 for A2 from the inheritance.

An operator should be aware that if the ALTO server supports the entities
decomposition, there will be potential security considerations. Section 8
(points to the Security Considerations section) discusses the details and
potential solutions.
===

There are two security considerations I can find:

1. If an ALTO client requests a large IP prefix like 0.0.0.0/0, the
decomposition may be very large (equal to the full map), which may consume
a lot of computation resource in the server side.
2. The decomposition may expose the confidential information to the ALTO
client, which may be unexpected by the ALTO server.

Waiting for comments from others.

Best,
Jensen

On Wed, Jul 11, 2018 at 7:18 AM Y. Richard Yang <[e-mail]> wrote:

> Dear WG,
>
> In the process to revise UP to address the comments and make the protocol
> as clean as possible, the authors identify one technical issue which we
> need WG opinions.
>
> Specifically, it is related to response (Sec. 5.6) to a filtered property
> map.
>
> The related new text:
> "   The response MUST indicate an error, using ALTO protocol error
> handling,
>    as defined in Section 8.5 of [RFC7285], if the request is invalid.
>
>    Specifically, a Filtered Property Map request can be invalid as
>    follows:
>
>    o  An entity address in "entities" in the request is invalid if:
>
>       *  The domain of this entity is not defined in the "entity-domain-
>          types" capability of this resource in the IRD;
>
>       *  The entity address is an invalid address in the entity domain.
>
>       A valid entity address is never an error, even if this Filtered
>       Property Map resource does not define any properties for it.
>
>       If an entity address in "entities" in the request is invalid, the
>       ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
>       in Section 8.5.2 of [RFC7285], and the "value" field of the error
>       message SHOULD indicate this entity address.
>
>    o  A property name in "properties" in the request is invalid if this
>       property name is not defined in the "property-types" capability of
>       this resource in the IRD.
>
>       It is not an error that the Filtered Property Map resource does
>       not define a requested property's value for a particular entity..
>       In this case, the ALTO server MUST omit that property from the
>       response for that endpoint.
>
>       If a property name in "properties" in the request is invalid, the
>       ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
>       in Section 8.5.2 of [RFC7285].  The "value" field of the error
>       message SHOULD indicate the property name.
>
>    The response to a valid request is the same as for the property map
>    (see Section 4.6), except that it only includes the entities and
>    properties requested by the client.
>
>    It is important that the Filtered Property Map response MUST include
>    all inherited property values for the specified entities.  A Full
>    Property Map may skip a property P for an entity A if P can be
>    derived using inheritance from another entitiy B.  A Filtered
>    Property Map request may include only A but not B.  In such a case,
>    the property B MUST be included in the response for A.
>
>    [QUESTION to WG: Need to make a decision.] It is possible that the
> entities in
>    the response are different from the entities in the request.
>    Consider a request for property P of entity A (e.g.,
>    ipv4:192.0.2.0/31).  Assume that P has value v1 for
>    A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32.  Then, the
>    response will include entities A1 and A2, instead of the request
>    entity A.
>
> An alternative design is to not enforce this decomposition. The authors
> feel
> that the current revision is better but is open to WG guidance.
>
> Thanks!
> Richard
>
>
> On Fri, Jun 29, 2018 at 1:29 PM <[e-mail]> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Application-Layer Traffic Optimization
>> WG of the IETF.
>>
>>         Title           : Unified Properties for the ALTO Protocol
>>         Authors         : Wendy Roome
>>                           Shiwei Dawn Chen
>>                           Sabine Randriamasy
>>                           Y. Richard Yang
>>                           Jingxuan Jensen Zhang
>>         Filename        : draft-ietf-alto-unified-props-new-04.txt
>>         Pages           : 30
>>         Date            : 2018-06-29
>>
>> Abstract:
>>    This document extends the Application-Layer Traffic Optimization
>>    (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
>>    properties" to domains of other entities, and by presenting those
>>    properties as maps, similar to the network and cost maps in ALTO.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04
>> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-04
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>>
>
>
> --
> --
>  =====================================
> | Y. Richard Yang <[e-mail]>   |
> | Professor of Computer Science       |
> | http://www.cs.yale.edu/~yry/        |
>  =====================================
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>