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>
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> 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
>> https://www.ietf.org/mailman/listinfo/alto
>>
>