[Last-Call] Secdir last call review of draft-ietf-mops-treedn-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

- 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.)

- 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.(*)

(*) 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;-)



-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux