Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
draft-ietf-pim-rfc4601bis-06

[Ballot comment]

Bill Atwood sent me a great explanation for how IPsec actually works
with PIM-SM here. I think adding a version of that to the security
considerations text here would be a fine thing, but that's a non-blocking
comment, so do add that or not as you see fit. (It was a very clear and
easy to follow description of what one needs to setup to get IPsec to
work usefully here so I hope you do include a version.)

Thanks for bearing with me in the meantime.

[Ballot discuss]


4601 used IPsec AH for it's MTI security. This removes that and
points at 5796 which defines how to use ESP for link local
addresses and with manual keying. That raises one technical
question and two ickky process questions. The ickky process
questions are probably best discussed between the IESG at least
initially in case we don't need to bother the authors/wg with
'em.

(1) I'd like to check that 5796 defines a way in which one can
secure all PIM messages that are defined here in 4601bis (should
one want to do that). If there are cases where PIM-SM can be
used and where there is no well defined security then I think
that would be a problem. And I think maybe there are such cases.
Am I wrong? If not, then how does one secure those?

- My review was based on the diff vs 4601 [1] and the abstract
of 5796 which seems fairly clear though.

  [1] https://tools.ietf.org/rfcdiff?url1=rfc4601&url2=draft-ietf-pim-rfc4601bis-05.txt

[Ballot discuss]


4601 used IPsec AH for it's MTI security. This removes that and
points at 5796 which defines how to use ESP for link local
addresses and with manual keying. That raises one technical
question and two ickky process questions. The ickky process
questions are probably best discussed between the IESG at least
initially in case we don't need to bother the authors/wg with
'em.

(1) I'd like to check that 5796 defines a way in which one can
secure all PIM messages that are defined here in 4601bis (should
one want to do that). If there are cases where PIM-SM can be
used and where there is no well defined security then I think
that would be a problem. And I think maybe there are such cases.
Am I wrong? If not, then how does one secure those?

(2) Is it ok for an IS to depend on a PS for it's MTI security
mechanism? (I think it is, but yeah, someone else might not.)

(3) Is it ok for an IS to not conform to BCP107? (I think it
depends, and I'm not sure in this case.)

- My review was based on the diff vs 4601 [1] and the abstract
of 5796 which seems fairly clear though.

  [1] https://tools.ietf.org/rfcdiff?url1=rfc4601&url2=draft-ietf-pim-rfc4601bis-05.txt

[Ballot comment]
Just a little bit of history in case this draft looks familiar to some of you.

This document was on the telechat agenda for 2015-03-12, but it was removed before the call to resolve a DISCUSS from Brian Haberman.  That issue has now been resolved.

The question of whether the AH security option actually has interoperable implementations has been raised.  This wasn't included in the survey and is relevant since AH is no longer recommended - having been updated by RFC 5796.  There are multiple implementations of RFC 5796 (according to Bill Atwood) - but it is lacking in deployment experience and, perhaps, implementation in many implementations.

[Ballot discuss]
Thank you for doing this work! I will be balloting YES on this document, but I have a point that needs to be worked out.  For the time being, this should be treated as a process issue and there is currently no need for document changes from the authors...

Section 6.3 of this document, and RFC 4601, currently says "The IPsec [8] transport mode using the Authentication Header (AH) is the recommended method to prevent the above attacks against PIM."

However, RFC 5796, which updates RFC 4601, says "In order to provide authentication of PIM-SM link-local messages, implementations MUST support ESP [RFC4303] and MAY support AH [RFC4302]."

The two issues that I think we need to resolve are:

1. Will 4601bis, when it is published as an RFC, inherit the "Updated by: RFC 5796" meta-data so that implementers will know to use the newer guidance provided in 5796?  There is a query to the RFC Editor on this point.

2. Should the text in section 6.3 be updated to adopt the recommendation from 5796 rather than maintain the obsolete recommendation for the use of AH?  If so, RFC 5796 could be referenced, which would lead to adding 5796 to the downref registry.

[Ballot comment]
Thank you so much for revising this spec. The number of errata was 
getting embarrassing and handling that alone makes this a very worthwhile
piece of work.

But additionally, this represents a milestone for PIM, an effort that
started as Experimental, and which is now widely deployed.

---

You continue to list Bill's coordinates and email as they appeared on
RFC 4601. Is this intentional, or should you update his coordinates?
Even if he wants the credit to still show ATT, an up-to-date email
address would be good.

---

Please look at replacing the reference to 5996 with a reference to 7296

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-pim-rfc4601bis version 4.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has one comment/question for one of the actions requested in this draft.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are two actions which need to be completed.

First, section 5.1 of the current draft indicates that PIM Address Family numbers are to be allocated in the following way:

"Values 0 through 127 are designated to have the same meaning as IANA-assigned Address Family Numbers. Values 128 through 250 are designated to be assigned for PIM by the IANA based upon IESG Approval, as defined in RFC 5226. Values 251 through 255 are designated for Private Use, as defined in RFC 5226."

IANA believes that the PIM Address Family subregistry of the Protocol Independent Multicast (PIM) Parameters registry located at:

http://www.iana.org/assignments/pim-parameters/

accurately reflects the request in section 5.1 of the current draft.

Second, section 5.2 of the current draft indicates that PIM Hello Options are to be allocated in the following way:

"Values 17 through 65000 are to be assigned by the IANA. Since the space is large, they may be assigned as First Come First Served as defined in RFC 5226. Such assignments are valid for one year and may be renewed. Permanent assignments require a specification as defined in RFC 5226."

IANA believes that the PIM-Hello Options subregistry of the Protocol Independent Multicast (PIM) Parameters registry located at:

http://www.iana.org/assignments/pim-parameters/

accurately reflects the request in section 5.2 of the current draft.

Comment/Question: Is the range of values for this space 1-65535?  Is value 0 non-existed
in this space?  Or this draft does not intend to address that?

IANA understands that there are no other actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)) to Internet Standard


The IESG has received a request from the Protocol Independent Multicast
WG (pim) to consider the following document:
- 'Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
  Specification (Revised)'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-02-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies Protocol Independent Multicast - Sparse Mode
  (PIM-SM).  PIM-SM is a multicast routing protocol that can use the
  underlying unicast routing information base or a separate multicast-
  capable routing information base.  It builds unidirectional shared
  trees rooted at a Rendezvous Point (RP) per group, and optionally
  creates shortest-path trees per source.

  This document addresses errata filed against RFC 4601, and removes
  the optional (*,*,RP) feature that lacks sufficient deployment
  experience.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601bis/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Internet Standard. It has many implementations for many years and has been thoroughly vetted. Much work has occurred over the last two years to address errata.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies Protocol Independent Multicast - Sparse Mode
(PIM-SM).  PIM-SM is a multicast routing protocol that can use the
underlying unicast routing information base or a separate multicast-
capable routing information base.  It builds unidirectional shared
trees rooted at a Rendezvous Point (RP) per group, and optionally
creates shortest-path trees per source.This document addresses errata filed against RFC 4601, and removes the optional (*,*,RP) feature that lacks sufficient deployment
experience.

Working Group Summary

There was very good feedback on the list over the last year, particularly during the last WGLCs. All comments were addressed to the satisfaction of those commenting.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are several existing implementations of the protocol over the span of many years. Bharat Joshi, most particularly, had many recent comments that were all addressed in final fine tuning of the document.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Mike McBride is the document shepherd and Adrian Farrell is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd (and many many others) has reviewed the document over the past few years and particular this final version. It is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

We have 100% consensus on this document after thorough review.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No appeals or other discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

thorough WG, Chair, and AD review.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No it won't change the status of other RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA considerations have been consistent for years.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No expert review needed in my humble opinion.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

thorough wg reviews and idnit checks