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

["Y. Richard Yang" <[e-mail]>]

Dear WG,

After extensive discussions, the authors will go with enforcing
decomposition.

Consider a simple use case:
A network map:
           defaultpid:  ipv4:0.0.0.0/0  ipv6:::0/0
            pid1:        ipv4:192.0.2.0/25
            pid2:        ipv4:192.0.2.0/28  ipv4:192.0.2.16/28

Assume that the client queries pid for ipv4:192.0.2.0/26. Without
decomposition, the client will get pid1, through inheritance. Now, the
client can use the result, for example, when lookup pid for 192.0.2.0/28,
locally. The result is pid1 locally but a query to the server is pid2.
Hence, for correctness, the system must notify the client that there are
refinement, which is decomposition.

We are taking a pass of the design and will post by end of this week.

Any comments are greatly appreciated!

Richard



On Wed, Jul 11, 2018 at 1:52 AM Jensen Zhang <[e-mail]>
wrote:

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