[CDNi] Secdir last call review of draft-ietf-cdni-additional-footprint-types-05

Daniel Migault via Datatracker <noreply@ietf.org> Sat, 10 December 2022 15:05 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: cdni@ietf.org
Delivered-To: cdni@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69923C1516FE; Sat, 10 Dec 2022 07:05:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Daniel Migault via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: cdni@ietf.org, draft-ietf-cdni-additional-footprint-types.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.2.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <167068470142.29533.15030214937491608215@ietfa.amsl.com>
Reply-To: Daniel Migault <daniel.migault@ericsson.com>
Date: Sat, 10 Dec 2022 07:05:01 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/DJ74M9DEAsX61xeQTaCNXsle34M>
Subject: [CDNi] Secdir last call review of draft-ietf-cdni-additional-footprint-types-05
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2022 15:05:01 -0000

Reviewer: Daniel Migault
Review result: Ready

Hi,

Reviewer: Daniel Migault
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other

The comment below mostly reflects what raised my curiosity while reading the
document. I do not see any of these comments requires some changes to the
document.

While reading the document I was wondering what could be the reason for
advertising ca-ns and us-ny. Note that whatever the response is, there is no
need to change the document. From my point of view, I imagined that subdivision
code would be mostly used to characterize a geographic zone that is served by a
CDN and so that expected codes would be neighbor areas. The example takes ca-ns
and us-ny which I do not see as neighbors, at least geographically speaking. I
know we can always find a case, but I am wondering if it is expected to be
common to have some non neighbor subdivisions being advertised and why. One
reason could be that geographic neighborhood and networking neighborhood may
also be distinct and I would be curious to understand if that is the reason and
how often it is expected to happen. To be clear, I am fine if the subdivision
code has just been taken (pseudo) randomly for example.

The Union data type is mentioned as overcoming the limitation of narrowing
capability. I think the text is nice saying that narrowing does not work for
what we do, but overall I do see the need to have union as a completely
separate need from the need to narrow. In other words, I do not see the
justification as something needed. My perception is that we were able to have
AND and Union enables to have OR.

If  my understanding is correct, I have the impression that there is an
alternative way to achieve OR which would consist of having different separate
advertisements. Not being an expert in CDNI, what I have in mind is that a dCDN
may send one advertisement with a union or may make multiple advertisements (1
for each member of the union). I am not challenging here the need for a union
as I am convinced it is needed - or will be needed at some point. What I would
like to understand is if multiple advertisements could effectively be
considered as an alternative to the union. If that is correct, I would be
interested to briefly understand the pro/cons of each alternative. I suspect
this mostly an operational advantage, but I am curious to learn a bit more on
it.

The SUBDIVISION Domain was not entirely clear to me, but I suspect this
connects the newly defined footprint type to the more generic framework.

The main security consideration I have regarding the footprint type is the
ability to prove that the dCDN is legitimate for announcing such capabilities.
Typically, I am wondering if there is any way to prevent a CDN to advertise
capabilities in Australia for example - while he is not serving that region ?

Note that we generic and so, is likely to be already addressed at a higher
level. My impression is that the model is that one has to trust the
advertisement, and so only consider those of trusted CDNs. I am wondering if
there are any practical ways to evaluate the trustworthiness related to the
subdivision.

Yours,
Daniel