Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-igmp-mld-yang-13: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

On May 26, 2019 at 10:15:05 PM, Benjamin Kaduk via Datatracker (
[e-mail]) wrote:

Ben:

Hi!

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I agree with Mirja that reiterating the privacy considerations of
explicit tracking of group membership (with pointer to the relevant
IGMP/MLD protocol documents) would be worthwhile.
Normally I would leave this as a Comment on the assumption that the
privacy considerations are already documented in the protocol
specification that documents explicit tracking, but I could not find
such a document (with privacy considerations listed) in a quick search;
I found RFC 6636 and draft-ietf-pim-explicit-tracking but probably
missed a few others.

Let's talk about what the current state actually is, and where it's best
to document the privacy considerations (which is not necessarily this
document, a priori).

Let’s first take a step back.  IGMP/MLD have the function of managing
multicast groups, as MLD’s name (Multicast Listener Discovery) suggests,
the protocols already collect information related to which hosts are
interested in which multicast groups.  §3 of rfc6636 has a good description:

   Mobile hosts use IGMP and MLD to make a request to join or leave
   multicast sessions.  When an adjacent upstream router receives the
   IGMP/MLD Report messages, it recognizes the membership status on the
   link.  To update the membership status reliably, the router sends
   IGMP/MLD Query messages periodically, and sends Group-Specific and/or
   Group-and-Source-Specific Queries when a member host reports its
   leave.  An IGMP/MLD Query is therefore necessary to obtain up-to-date
   membership information, but a large number of the reply messages sent
   from all member hosts may cause network congestion or consume network
   bandwidth.


“Explicit Membership Tracking” is simply the realization of the ability of
the router to remember the membership to save network resources and shorten
group leave time.  Yes, the name is probably not the best, specially if
we’re worried about privacy, but the protocols already expose that
information.  IOW, the ability to know the hosts is not new.

Note that anyone on the link can listen to the Reports…so there’s no need
to get access to the YANG information, or even implement explicit tracking,
to know which host is interested in what.  From that point of view, I think
that any privacy consideration should have been in the IGMP/MLD specs
(rfc3376/rfc3810), but those documents only focus their Security
Considerations on the impact/mitigation of forged messages.


draft-ietf-pim-explicit-tracking had the intent of specifying Explicit
Membership Tracking.  However, a couple of attempts for publication have
resulted in the document being sent back to the WG, first as a result of
the IESG Evaluation…and later my me.  In both cases the reason can be
summarized as there not being enough clarity for it to be in the Standards
Track.  The WG seems to have lost interest…. As described there, there are
"various ways to implement the explicit tracking function…[it] does not
change on-wire behavior, and the function or mechanisms described in this
document do not break the interoperability between the existing
implementations and the implementation based on this specification.”  IOW,
multiple implementations can co-exist...


Having said that, I don’t think the YANG module is the right place to
document the privacy considerations of information that has existed in the
protocols “forever" (IGMPv1 was specified in rfc1112 and MLDv1 in rfc2710).

Thoughts?

Alvaro.