Re: [pim] Mirja Kühlewind's No Objection on draft-ietf-pim-igmp-mld-yang-13: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 04 June 2019 00:01 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67E91200F5; Mon, 3 Jun 2019 17:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vug0s2KYy0QZ; Mon, 3 Jun 2019 17:01:43 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E833120059; Mon, 3 Jun 2019 17:01:42 -0700 (PDT)
Received: from prolepsis.kaduk.org (c-24-16-119-19.hsd1.wa.comcast.net [24.16.119.19]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5401Zft009289 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Jun 2019 20:01:37 -0400
Date: Mon, 3 Jun 2019 17:01:35 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Cc: Mirja =?iso-8859-1?Q?K=FChlewind?= <ietf@kuehlewind.net>, draft-ietf-pim-igmp-mld-yang@ietf.org, Stig Venaas <stig@venaas.com>, pim-chairs@ietf.org, Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, pim@ietf.org
Message-ID: <20190604000131.GO1902@prolepsis.kaduk.org>
References: <155871943771.12273.17148916156796470545.idtracker@ietfa.amsl.com> <CAEz6PPR+UVdSA3zZk2HjV1fHA2QSLB5aReaRgQkNf6vd+PZEPw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAEz6PPR+UVdSA3zZk2HjV1fHA2QSLB5aReaRgQkNf6vd+PZEPw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/e-twq7P1UdWdpLuzWAYS6yGYKOU>
Subject: Re: [pim] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-pim-igmp-mld-yang-13=3A_=28with_COMMENT=29?=
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2019 00:01:46 -0000

On Tue, May 28, 2019 at 10:04:19AM -0400, Xufeng Liu wrote:
> Hi Mirja,
> 
> Thanks for the review. We have proposed the changes in details below.
> Regards,
> - Xufeng
> 
> On Fri, May 24, 2019 at 1:37 PM Mirja Kühlewind via Datatracker <
> noreply@ietf.org>; wrote:
> 
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-pim-igmp-mld-yang-13: No Objection
> >
> > 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/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Two quick questions:
> >
> > 1) Not sure about the current practice about YANG models but shouldn’t this
> > document eventually update RFC8349?
> >
> [Xufeng]:  The current practice is not to update RFC8349, but to reference
> it.
> 
> 
> >
> > 2) Also maybe it would make sense to discuss the sensitivity of
> > explicit-tracking separately in the security consideration section?
> >
> [Xufeng]: Since RFC6636 does not describe the security risks in details, we
> can add the following to this this document.
> 
> [OLD]:5. Security Considerations
>   igmp-mold:interfaces/interface
> 
>      This subtree specifies the configuration for the IGMP attributes
>      at the interface level on an IGMP instance.  Modifying the
>      configuration can cause IGMP membership deleted or reconstructed

nit insert "to be" before "deleted"

>      on a specific interface of an IGMP instance.
> [NEW]:5. Security
> Considerations
>   igmp-mold:interfaces/interface
> 
>      This subtree specifies the configuration for the IGMP attributes
>      at the interface level on an IGMP instance.  Modifying the
>      configuration can cause IGMP membership deleted or reconstructed
>      on a specific interface of an IGMP instance.The explicit-tracking
> leaf enables the explicit membership tracking function on this
> multicast router. Enabling this function will cause the router to
> record more multicast membership information including all hosts that
> receive multicast messages.

That's probably okay, though I would suggest (instead of the last sentence):

Enabling this function causes the router to retain more state about the group,
including the list of hosts receiving multicast messages.  This information
is already available to a network observer watching the multicast traffic
itself, so the incremental risk of having the consolidated data readily at
hand (and susceptible to compromise) is low.


> [OLD]:      /rt:routing/rt:control-plane-protocols
>    /rt:control-plane-protocol/igmmp-mld:igmp
> 
>    /rt:routing/rt:control-plane-protocols
>    /rt:control-plane-protocol/igmp-mld:mld
> 
>    Unauthorized access to any data node of the above subtree can
>    disclose the operational state information of IGMP or MLD on this
>    device.
> [NEW]:      /rt:routing/rt:control-plane-protocols
>    /rt:control-plane-protocol/igmmp-mld:igmp
> 
>    /rt:routing/rt:control-plane-protocols
>    /rt:control-plane-protocol/igmp-mld:mld
> 
>    Unauthorized access to any data node of the above subtree can
>    disclose the operational state information of IGMP or MLD on this
>    device.Under /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/igmp-mld:igmp,
> and /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/igmp-mld:mld,
> igmp-mLd:interfaces/interface. The explicit-tracking leaf shows whether
> the explicit membership tracking function is enabled on this multicast
> router. When this function is enabled, the sub-tree group/source/host
> contains the membership information of all the hosts that receive
> multicast messages. Unauthorized access to this sub-tree may disclose
> such information.
>
> In addition, we will RFC6636 to the reference list, and add a
> “reference” statement to the description of the leaf
> “explicit-tracking” in the model.
> 
> 
> Is it ok to make such changes?

Please go ahead.  I think Mirja can chime in if there are still further changes
to be made.

-Ben