[pim] Re: [Shepherding AD review] review of draft-ietf-pim-light-03

["Gunter van de Velde (Nokia)" <[e-mail]>]

Hi Hooman,

Many thanks for the swift actions.

The draft is almost ready to go. One last sanity check when running idnits tool, few messages are seen: a downref and a duplicate ref (which i am confused about why it is shown)

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-light-05.txt

Is the downref to an experimental needed for PIM light? If yes, we will need to add it to the downref register. (This is something PIM AD, IESG and RFC editor will process, hence no workload for the authors. However we do try to avoid downrefs if possible. If the reference would be used as an example, and not formal procedures it is an informational reference.

In addition the Normative reference to "draft-ietf-bier-pim-signaling" seems to be better as Informational. I think it is only used in examples. If we make this Normative, then the PIM Light draft is fate sharing with draft-ietf-bier-pim-signaling which seems undesired and not required.

Any thoughts about this few final aspects?

G/

From: Hooman Bidgoli (Nokia) <[e-mail]>
Sent: Thursday, August 8, 2024 1:04 AM
To: [e-mail]; Gunter van de Velde (Nokia) <[e-mail]>
Subject: Re: [pim] [Shepherding AD review] review of draft-ietf-pim-light-03

Hi Gunter

Thanks for your review and comments. I uploaded a new version of the document.

Some points/comments please


  1.
RFC 7761, Section 4.3.1, outlines the PIM neighbor discovery mechanism using Hello messages. Section 4.5 specifies that if a router receives a Join/Prune message from an IP source address without having previously received a PIM Hello message from that source, the router SHOULD discard the Join/Prune message without further processing. This procedure ensures that only messages from authenticated PIM neighbors are processed, maintaining the integrity and reliability of the multicast routing infrastructure.


HB> "This procedure ensures that only messages from authenticated PIM neighbors are processed, maintaining the integrity and reliability of the multicast routing infrastructure."
HB> I think you are misunderstanding the authenticated part. the hello messages can't authenticate the neighbor without IPsec AH mode or an authentication protocols like HMAC. This is why RFC7761 section 4.5 is pointing to section 6.3 and eventually IPsec for authentication.
HB> I am omitting this last bit of your suggestion and going with the original text.


  1.

The following rewrite may be more clear for consumers of the document.

The fact that with PIM Light there is processing of packets from an unauthenticated neighbor seems as a serious security concern. This shoul dbe mentioned as a concern and operational guidelines to reduce the risk vector



HB> again I think you are confusing authentication of a router to PIM hello adjacency. Authentication is done via IPsec or HMAC hash over the PIM hello packets and other packets including join/prunes. This authentication is possible with PIM Light as well as mentioned in the security section. Hello messages do not authenticate the router.

3.

The existing IANA registery for "PIM Message Types" may not be sufficient for PIM Light and may need update.

The existing table may need a new column, used explicit for PIM Light to show which of the PIM Message Types is supported.

It would be to lock the Message types currently supported and allows a framework for the future, unless through WG consensus the expectation is never any message ar eto be supported for PLI?

HB> I can't see us supporting any new message for PLI in near future. As PLI only support join/prune message.