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

Hi Daniel,
Thank you for the deep dive into the concepts and incentives of the draft.
Per your remarks, please see our comments inline :)
Cheers,
Sanjay and Nir

On Sat, Dec 10, 2022 at 5:05 PM Daniel Migault via Datatracker <
noreply@ietf.org> wrote:

> 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.
>

Indeed. A geographical proximity is expected to be the common case.
The reason we presented ca-ns and us-ny was to give an example for 2 types
of subdivisions - a Province in Canada vs. a state in the US.
But now that you bring it up, we see it can confuse the reader.

To make it more intuitive to the reader, we will change the example to
reflect the geographical proximity, presenting for example NY and NJ or NY
and Ontario.

> 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.
>

There are a few reasons for using union. Indeed there is an operational
efficiency in joining
Additionally, there are more substantive uses of union, such as in cases
where the advertised capability refers to a fixed commodity (e.g. capacity).
For example, in the case a dCDN advertises its "capacity" capability, which
may apply for an overall set of IPs, from both IPv4 and IPv6.
The union allows us to be unambiguous - avoiding overbooking of "capacity
units", on the one hand, as well as utilizing the advertised capacity
efficiently (without arbitrarily splitting it) on the other.

> 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.
>

Indeed, there is no mechanism preventing dCDN from publishing
capabilities for IPs they do not own / cannot really serve.
This issue was also discussed in RFC 8008 section 2.4
<https://www.rfc-editor.org/rfc/rfc8008.html#section-2.4>, which mostly
refers to resolution of the issue at the business/contractual level.
They also point to the option to make the Footprint verifiable, mostly
out-of-band (non realtime).
There is very little to know incentive for a dCDN to cheat, as RFC 8008
states that it may "negatively affect the long-term business relationship".

Yours,
> Daniel
>
>
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
>