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@xxxxxxxxx> 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@xxxxxxxxx
_______________________________________________
alto mailing list
alto@xxxxxxxx
https://www.ietf.org/mailman/listinfo/alto
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
