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

"Y. Richard Yang" <> Wed, 11 July 2018 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5F13130E40 for <>; Wed, 11 Jul 2018 10:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B3RcbVKvfsCZ for <>; Wed, 11 Jul 2018 10:54:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7433D130DF2 for <>; Wed, 11 Jul 2018 10:54:37 -0700 (PDT)
Received: by with SMTP id u202-v6so21970119lff.9 for <>; Wed, 11 Jul 2018 10:54:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7CdFO4vDrWhGz/cyRL8JJteA42/ne2CMQFGmAXJsGEA=; b=fc3i9vlF9vnNBdotyb0h2zTuseT1WoetDNXuRTgYUNxcf8L5H/ZHLFobmvaiW/zZss dmMS73m3+AGNL8WPUB8Z2D3dVml3WnftWpDq+Nm65MxZ9aR0hDS16/mDY3swibG0QlW0 AAbJDaD6TBvq+8LfSJ495mxhZi7sZy81g+GJanBojvnEy3TOgOP1lWyc+W5kwAUYE/78 wQ8zk0Eq/WCXBwi/CBTphCTgryjPpyzQvpJb5wSZMQ1LlmOOXzPHK149sIgnHdBlHr4R sfWxtoF67/qK3Tddftm6CI4yId65DN1a+APqYr7rpVll/2MH9J+emExheeYFzF8nlwgr UJqw==
X-Gm-Message-State: APt69E3xfFOr1JPhDSlKFkVSdA2i4k/Sinix1nBFbn6V+Hz93PSkHROt ++JQ+fxFSp1yzlySHg9ua+9V4Bbn3ZLSZ2D2UOI=
X-Google-Smtp-Source: AAOMgpcMxGvNHDLvAdfCTqrFokbVIIe5fX9Gy9N8ZykFEDy3rpHmNjnoosS1L7b0aXPLcc5EcElnBGgajJwekBbEVlU=
X-Received: by 2002:a19:501e:: with SMTP id e30-v6mr3760827lfb.71.1531331675582; Wed, 11 Jul 2018 10:54:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: "Y. Richard Yang" <>
Date: Wed, 11 Jul 2018 13:54:22 -0400
Message-ID: <>
To: Jensen Zhang <>
Content-Type: multipart/alternative; boundary="0000000000008e780e0570bcf09b"
Archived-At: <>
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Jul 2018 17:54:41 -0000

Dear WG,

After extensive discussions, the authors will go with enforcing

Consider a simple use case:
A network map:
           defaultpid:  ipv4:  ipv6:::0/0
            pid1:        ipv4:
            pid2:        ipv4:  ipv4:

Assume that the client queries pid for ipv4: Without
decomposition, the client will get pid1, through inheritance. Now, the
client can use the result, for example, when lookup pid for,
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!


On Wed, Jul 11, 2018 at 1:52 AM Jensen Zhang <>

> 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:, if P has value v1 for A1=ipv4: and v2 for
> A2=ipv4:, 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, 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 <> 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:  Assume that P has value v1 for
>>    A1=ipv4: and v2 for A2=ipv4:  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 <> 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:
>>> There are also htmlized versions available at:
>>> A diff from the previous version is available at:
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at
>>> Internet-Drafts are also available by anonymous FTP at:
>>> _______________________________________________
>>> alto mailing list