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

[Daniel Migault <[e-mail]>]

Thanks for the clarifications.
Yours ,
Daniel

On Tue, Dec 13, 2022 at 3:57 PM Nir Sopher <[e-mail]> wrote:

> 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 <
> [e-mail]> 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.
>
Thanks for the clarification. NY and Ontario is probably the best choice
;-)

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

Thanks for the clarification, that makes complete sense.

>
>
>> 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".
>
I see.

>
> Yours,
>> Daniel
>>
>>
>>
>> _______________________________________________
>> CDNi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cdni
>>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>


-- 
Daniel Migault
Ericsson