Stephen- thank you for the thoughtful review. We have updated the draft based on your feedback. In particular, we added section 8 to describe several TreeDN deployments to provide some more concrete details on real-world deployments. Please let us know if the latest revision addresses your concerns. A diff can be found here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-mops-treedn-04&url2=draft-ietf-mops-treedn-05&difftype=--html Further comments inline: On Mon, 29 Apr 2024, Stephen Farrell via Datatracker wrote: | | Reviewer: Stephen Farrell | Review result: Has Issues | | The draft describes TreeDN, a scheme for using AMT (automatic multicast | tunnelling) to overcome issues with IP multicast. Overall, the ideas appear | sound enough, esp. for an informational/overivew document, but I did see a few | issues that probably ought be fixed before publication. (They should be easily | fixed though.) | | - The security considerations section needs to refer to the security | considerations of RFC7450 (AMT) and also really ought include some analysis of | how esp. the potential DoS issues described there might (or do not) affect uses | such as broadcasting large-scale sports events. Explicitly called out the security considerations of RFC7450 and how they apply to TreeDN. | | - I only had a quick look I had at RFC7450 but if the anycast IP of the AMT | relay tends to identify the kind of content (whether a specific event, or some | kind of "TV channel" equivalent), then TreeDN may have a privacy issue that | perhaps wouldn't have been as much appreciated when RFC7450 was being | developed. (And certainly wasn't when the -00 that became RFC7450 was | started:-) In other contexts we're starting to be much more sensitive to such | issues and those also deserve consideration here, e.g. adding some text to the | effect that if the AMT gateway is associated with a mobile-device/home/person, | then the privacy issue exists (that a n/w observer can know e.g. the time, the | g/w and relay IPs and base inferences on those) and maybe something like MASQUE | would be an appropriate way to improve matters. (I'd not expect a document like | this to provide solutions there, but it is important to recognise such issues | as early as possible I think.) The IP address of the relay is probably far less of a concern from a confidentiality perspective than the receiving host/gw, as IGMP/MLD certainly could be used to associate particular content with an end user. Added explicit mention of this in the security considerations. | | - There's a conflict between the kind of sales/marketing text claiming (without | references) that TreeDN is super-good, and the arm-waving in section 7.3 that | says that there are loads of (unspecified) ways to distribute keys to | authorized clients. Given the lack of references to e.g. things deployed | following the TreeDN approach and stats as to how much those deployments | actually improved things, I guess a way to handle this would be to tone down | the sales/marketing text and just say that TreeDN is a neat idea and that | deploying it would need some TBD way to distribute keys to authorized | receivers. Or else maybe add the references that back up the sales/marketing | claims and then point to how some of those deployments did key distribution.(*) Added description of three real-world deployments in sect 8 to provide more concrete examples of how TreeDN is being used today. | | (*) Apologies if this point is made a little bluntly, but my antennae fire when | I read lots of text like "the TreeDN architecture is ideal for..." with zero | backup via references;-) Removed the word "ideal" -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
