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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Sun, 26 May 2019 19:15:04 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pim-igmp-mld-yang-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Other than my Discuss point, basically all I have is editorial nits -- thanks for
the well-written document!

Section 2.1

                                   Even though there is no protocol
   specific notifications are defined in this model, the subscription

nit: s/there is// -- the "are defined in this model" takes care of
the grammatical necessities here.
   and push mechanism defined in [I-D.ietf-netconf-subscribed-
   notifications] and [I-D.ietf-netconf-yang-push] can be used by the
   user to subscribe notifications on the data nodes in this model.

nit: "subscribe to notifications"

   The model contains all basic configuration parameters to operate the
   protocols listed above. Depending on the implementation choices,

nit: "all the basic"

Section 4

     grouping interface-common-config-attributes {
       [...]
       leaf query-interval {
         [...]
         description
           "The Query Interval is the interval between General Queries
            sent by the Querier.In RFC3376, Querier's Query
            Interval(QQI) is represented from the Querier's Query
            Interval Code in query message as follows:

nit: one or two (not zero) spaces after the end of the sentence.
nit: "In RFC3376, the Querier's Query Interval (QQI)"

       leaf exclude-lite {
         if-feature intf-exclude-lite;

side-note: I misparsed this (I think) the first few times I read it,
since "exclude lite" can be taken as an imperative command to not use
the lite version.  But it seems this is really just an ordinary
feature-enablment tag about whether to use the EXCLUDE filtering that
is available in the lite version of the protocol.  I don't know whether
reordering to "lite-exclude" would be a net win or net loss due to
causing some other confusion, though.

     grouping interface-state-attributes-igmp {
       [...]
       list group {
         [...]
         list source {
           [...]
           list host {
	     [...]
             leaf host-address {
               type inet:ipv4-address;
               description
                 "The IPv6 address of the host.";

nit: "ipv6-address"

     grouping interface-state-group-attributes-igmp-mld {

nit: I thought most of the other shared groupings just didn't use a
suffix, as opposed to using the "-igmp-mld" combined suffix.
(Similarly for interface-state-source-attributes-igmp-mld and
interface-state-host-attributes-igmp-mld, which does cause me to wonder
if I'm not perceiving "most" correctly.)

Section 5

   igmp-mld:global

     This subtree specifies the configuration for the IGMP attributes
     at the global level on an IGMP instance.  Modifying the
     configuration can cause IGMP membership deleted or reconstructed
     on all the interfaces of an IGMP instance.

nit: "to be deleted or reconstructed"  (Similarly for the following
paragraphs.)

The description of the considerations for unauthorized read access are
fairly generic and do not specify specific potential harms, but I will
not insist on any changes here.

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 28 May 2019 10:18:54 -0400

Hi Benjamin,

Thanks for the review. A little more on the discussion below.
Best regards,
- Xufeng

> https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/
[Xufeng]: Understand the conern about the insufficient decription in
RFC6636 and draft-ietf-pim-explicit-tracking. We are ok to add more
description in this document, as proposed in the reply to Mirja's comment.
Would the change be ok?

[Xufeng]: Thanks for these. We will fix them in the new revision, and post
the updates soon.

> causing some other confusion, though.
[Xufeng]: Understand the confusion. "exlude" has its special meaning (which
a type of filter) here, but the leaf name does not show it. Would
"lite-exclude-filter" or "exclude-filter-lite" a bitter better?

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 29 May 2019 09:12:00 -0400

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

Ben:

Hi!

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 29 May 2019 08:39:06 -0700

> On May 26, 2019 at 10:15:05 PM, Benjamin Kaduk via Datatracker (

That basically matches my expectation -- to put it glibly, the difference
between having a cached copy of the recipient list on hand (to potentially
be exfiltrated, if one is thinking in a paranoid fashion) versus needing to
go out and fetch the recipient list.  So the relevant security considerations
are actually pretty minor, in the grand scheme of things...

> protocols “forever" (IGMPv1 was specified in rfc1112 and MLDv1 in rfc2710).

... and given that I agree that the YANG module is not the right place to
document this stuff, the right answer may just be "do nothing".  The main
other option that comes to mind would be to write a separate short document
with "additional [security|privacy] considerations for internet multicast
protocols", but absent some forcing function I don't expect such a document
to get written/published.

Mostly I just wanted to have someone who knows more about the existing documents
than I do to take a look and see if there's an obvious place to mention this,
but since it sounds like there isn't one, I'll go ahead and clear.

Thanks for the discussion!

-Ben

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 29 May 2019 23:32:41 -0400

Hi Benjamin,

We have posted an updated version
https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-yang-14, to address
these nits. We are holding on the updates for the Discuss point for now,
since it is still being discussed.

Best regards,
- Xufeng

On Tue, May 28, 2019 at 10:18 AM Xufeng Liu <[email-masked]>
wrote:

> [Xufeng]: Understand the confusion. "exlude" has its special meaning
> (which a type of filter) here, but the leaf name does not show it. Would