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

"Y. Richard Yang" <yry@cs.yale.edu> Wed, 11 July 2018 17:54 UTC

Return-Path: <yang.r.yang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F13130E40 for <alto@ietfa.amsl.com>; Wed, 11 Jul 2018 10:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3RcbVKvfsCZ for <alto@ietfa.amsl.com>; Wed, 11 Jul 2018 10:54:38 -0700 (PDT)
Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7433D130DF2 for <alto@ietf.org>; Wed, 11 Jul 2018 10:54:37 -0700 (PDT)
Received: by mail-lf0-f49.google.com with SMTP id u202-v6so21970119lff.9 for <alto@ietf.org>; Wed, 11 Jul 2018 10:54:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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: <153029332051.30450.2848545429737582427@ietfa.amsl.com> <CANUuoLpS994gozRZQ6HMqgtn+ioTNojXaZC4nEOf5m5goL4uGw@mail.gmail.com> <CAAbpuyqgJA4TDSYEAdBnaQNo4jzDhtAQqBMfPtouznWPVyS8kA@mail.gmail.com>
In-Reply-To: <CAAbpuyqgJA4TDSYEAdBnaQNo4jzDhtAQqBMfPtouznWPVyS8kA@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Wed, 11 Jul 2018 13:54:22 -0400
Message-ID: <CANUuoLqVVG=WFLRR4XAUv=QiO1+s22SuAvzWdvn3YeU3gqQzpg@mail.gmail.com>
To: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008e780e0570bcf09b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/l_BwXgDXQIZaxBGvrcU47ejSfvU>
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2018 17:54:41 -0000

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 <jingxuan.n.zhang@gmail.com>;
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 <yry@cs.yale.edu>; 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 <internet-drafts@ietf.org>; 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
>>> alto@ietf.org
>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>>
>>