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 <[email protected]>
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 <[email protected]> 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 <[email protected]> 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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>>
>>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
