[secdir] Re: Secdir last call review of draft-ietf-mops-treedn-04

[Leonard Giuliano <[e-mail]>]

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"