Re: [alto] Roman Danyliw's No Objection on draft-ietf-alto-cdni-request-routing-alto-18: (with COMMENT)

Qin Wu <bill.wu@huawei.com> Thu, 17 February 2022 03:52 UTC

Return-Path: <bill.wu@huawei.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 F255C3A148D; Wed, 16 Feb 2022 19:52:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 C9We5rwqDktI; Wed, 16 Feb 2022 19:52:23 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0023A1485; Wed, 16 Feb 2022 19:52:22 -0800 (PST)
Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JzglB001Lz67Y1y; Thu, 17 Feb 2022 11:47:49 +0800 (CST)
Received: from canpemm100006.china.huawei.com (7.192.104.17) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 17 Feb 2022 04:52:18 +0100
Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm100006.china.huawei.com (7.192.104.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 17 Feb 2022 11:52:17 +0800
Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2308.021; Thu, 17 Feb 2022 11:52:16 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Jensen Zhang <jingxuan.n.zhang@gmail.com>, Roman Danyliw <rdd@cert.org>
CC: The IESG <iesg@ietf.org>, alto-chairs <alto-chairs@ietf.org>, IETF ALTO <alto@ietf.org>, "draft-ietf-alto-cdni-request-routing-alto@ietf.org" <draft-ietf-alto-cdni-request-routing-alto@ietf.org>
Thread-Topic: [alto] Roman Danyliw's No Objection on draft-ietf-alto-cdni-request-routing-alto-18: (with COMMENT)
Thread-Index: AdgjsWUhNFXly2Rew0C3fMcs/wP71w==
Date: Thu, 17 Feb 2022 03:52:16 +0000
Message-ID: <c3e1e0c114b944ba8d218a9fb6373155@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.16]
Content-Type: multipart/alternative; boundary="_000_c3e1e0c114b944ba8d218a9fb6373155huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/kKGT5JknzSRQsOmLddQTeVl6BZI>
Subject: Re: [alto] Roman Danyliw's No Objection on draft-ietf-alto-cdni-request-routing-alto-18: (with COMMENT)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 17 Feb 2022 03:52:28 -0000

Thanks, Jensen, just one update to Roman,
Authors has made another revision to address comments raised by IANA manager
The diff can be seen:
https://www.ietf.org/rfcdiff?url1=draft-ietf-alto-cdni-request-routing-alto-20&url2=draft-ietf-alto-cdni-request-routing-alto-22

-Qin (on behalf of chairs)
发件人: Jensen Zhang [mailto:jingxuan.n.zhang@gmail.com]
发送时间: 2022年2月16日 21:35
收件人: Roman Danyliw <rdd@cert.org>
抄送: The IESG <iesg@ietf.org>; alto-chairs <alto-chairs@ietf.org>; IETF ALTO <alto@ietf.org>; draft-ietf-alto-cdni-request-routing-alto@ietf.org
主题: Re: [alto] Roman Danyliw's No Objection on draft-ietf-alto-cdni-request-routing-alto-18: (with COMMENT)

Hi Roman,

A new version that echoes the replies already provided in this thread is available:

URL:            https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-21.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-21
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni-request-routing-alto-21.txt

Please let us know if they address your concerns.

Best regards,
Jensen


On Tue, Jan 18, 2022 at 10:00 PM Jensen Zhang <jingxuan.n.zhang@gmail.com<mailto:jingxuan.n.zhang@gmail.com>> wrote:
Hi Roman,

Many thanks for your comments. See our answers inline. Please let us know if they address your concerns.


On Thu, Jan 6, 2022 at 5:31 AM Roman Danyliw via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-alto-cdni-request-routing-alto-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Klaas Wierenga for the SECDIR review.

Thanks for addressing my DISCUSS point

** Section 8.
     For authenticity and integrity of ALTO information, an attacker
      may disguise itself as an ALTO server for a dCDN, and provide
      false capabilities and footprints to a uCDN using the CDNI
      Advertisement service.

-- I don’t follow the intent of the first clause.  Why is an _attacker_
concerned with the authenticity and integrity of the ALTO information?

This bullet describes the same risk scenario as the one in Sec 15.1 of RFC7285.


-- What role can TLS, an associated server certificate (for the dCDN) and
configured knowledge of this certificate at the uCDN mitigate some of this
risk?  Shouldn’t the uCDNs only be communicating with a collection of known
dCDNs with which it has some out-of-band negotiated arrangement?

Yes, the uCDNs should only communicate with known dCDNs. But an attacker can start a man-in-the-middle attack.
About how to configure TLS, does the second last bullet of this section make it clear?


** Section 8.
      For availability of ALTO services, an attacker may conduct service
      degradation attacks using services defined in this document to
      disable ALTO services of a network.

Again, operating under the assumption that the dCDN (ALTO Server) would only be
working with a known (prearranged) set of uCDNs and they would have
authenticated somehow (per the DISCUSS), couldn’t repeated requested be rate
limited and after attribution, filtered to minimize impact?

Yes, considering the limited number of authenticated uCDNs, this security issue may not be that risky.
This bullet just aligns with Sec 15.5 of RFC7285. Do you strongly think we should remove this one?

Thanks,
Jensen




_______________________________________________
alto mailing list
alto@ietf.org<mailto:alto@ietf.org>
https://www.ietf.org/mailman/listinfo/alto