Re: [alto] SECDIR Last Call review of draft-ietf-alto-new-transport-15

Hi Donald,

Sorry for the late reply as the mail is not properly forwarded to my
primary email. Please see our responses inline and feel free to let us know
if there are further comments.

Best,
Kai

On Thu, Oct 12, 2023 at 10:38 AM Donald Eastlake <d3e3e3@gmail.com> wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  Document editors and WG chairs should treat these comments just
> like any other last call comments. Sorry this review is a bit late.
>
> The summary of this review is Ready with Issues.
>
> (I did an early review of the -07 version of this draft at which time
> I found only nits all of which were fixed.)
>
> *Security*
>
> While I'm not all that into ALTO, it seems to me that this draft is all
> about messages and message exchanges between ALTO entities where the
> security (authentication, encryption, ...) has been specified in previous
> standards track documents such as RFC 7285; however, in Section 9.3,
> it says the spoofed URIs can be avoided by "encrypting the requests"
> where I think it should say "authenticating" the requests. There are a
> few additional security considerations which seem to be covered by the
> Security Considerations section of this draft.
>

[KAI] You are right. In the meantime, after discussing with the AD and the
HTTPDIR reviewer, we eventually dropped the design of explicitly deleting a
TIPS view. So, it seems that spoofed URI is no longer a concern.

>
> *Other possible issues*
>
> - In the update from -14 to -15, huge numbers of all caps RFC 2119 key
> words have been lowercased. In many instances, this does not look
> right to me. (There are many other cases but one example is that in
> Section 8.4, all words in all upper case were lowercased.)
>
>
[KAI] We went over the keywords and hopefully they are in the right case
now. Some of the operational consideration sections are repetitive to
sections in RFC 8895 and are removed in -17, including Sec 8.4 in -15.

> - Although there is correct text elsewhere, the last paragraph of
> Section 6.4, page 24, seems to say you delete a TIPS view if
> heartbeats time out on one connection for that view. But shouldn't it
> be all connections going away as there might be multiple?
>
>
[KAI] Yes indeed. However, the heartbeat mechanism is no longer needed as
the server now has full control of TIPS views' lifecycles. But similarly,
the server is

> - I am a bit surprised there is nothing about jittering the heartbeat
> messages to be sure they can't get synchronized between muldtiple
> clients. Something like the time between them should be varied by an
> amount randomly selected in the range +0% to -40%.
>
>
[KAI] Previously the idea was to use multiple heartbeat messages to detect
the liveness of clients. Even for 2 messages, the variation is 100%, which
should be good enough. Of course, as we no longer have the heartbeat
mechanism now, this probably will not be an issue anymore.

> - Section 2.1, Page 6: I think there is something not quite right with
> the sentence "Prefetching updates can reduce the time to send the
> request, making it possible to achieve sub-RTT transmission of ALTO
> incremental updates." It seems muddled. Transmission speed /
> transmission time isn't affected by prefetching although, of course,
> the time to satisfy a request can be vastly reduced. Maybe
> "Prefetching updates can reduce the time to satisfy a request, makit
> it possible to achieve rapid, sub-RTT ALTO incremental updates."
>
>
[KAI] Thanks for the proposal. Will use the suggested text.

>
> *Nits*
>
> - Section 3.1, page 10, "(tag" -> "(a tag"
>

[KAI]  Nice catch. Updated as suggested.

>
> - Section 6.2, page 22, "time unit is second" -> "time unit is a second"
>

[KAI] The sentence is no longer there as heartbeat is removed in the new
version.

>
> Hope these comments are helpful.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>