[pim] Re: Gorry Fairhurst's Discuss on draft-ietf-pim-p2mp-policy-ping-15: (with DISCUSS and COMMENT)

[Gorry Fairhurst <[e-mail]>]

On 24/09/2025 00:15, Hooman Bidgoli (Nokia) wrote:
>
> Hi Gorry
>
> Thanks for the suggestion!
>
> I incorporated your suggestion in version 24.
>
> Please have a look and hopefully this will address your concerns
>
> Thanks again
>
> Hooman
>
Thank you, I appreciate the addition, and have now changed mny position 
to "No Objection".

Best wishes,

Gorry

> *From:*Gorry Fairhurst <[e-mail]>
> *Sent:* Tuesday, September 23, 2025 11:23 AM
> *To:* Hooman Bidgoli (Nokia) <[e-mail]>; The IESG 
> <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> *Subject:* Re: Gorry Fairhurst's Discuss on 
> draft-ietf-pim-p2mp-policy-ping-15: (with DISCUSS and COMMENT)
>
>
> On 18/09/2025 17:19, Hooman Bidgoli (Nokia) wrote:
>
>     Hi Gorry
>
>     It was brought to my attention that you replied and I had missed
>     it. Sorry for confusion.
>
>     So P2MP Ping is no different then ICMP or what is said in RFC 4379.
>
>     It is exactly the same procedures which the implementation has to
>     rate limit the LSP ping traffic going to the control checking the
>     timestamp checking the source address etc…
>
>     The reason I didn’t mention RFC 4379 in the document is because I
>     point to RFC 6425 section 8 which in order points to RFC 4379.
>     Since p2mp policy is a identical to point-to-multipoint mpls
>     -extensions to lsp ping I think it is better to point to rfc6425
>     rather then directly pointing to rfc 4379.
>
>     Does this answer your question?
>
>     Also the reason I didn’t add any additional text compare to
>     rfc6425 is because the procedures are exactly the same.
>
>     If you would like I can add some extra text the document section 6
>     but honestly the parent rfc 6425 is taking care of this.
>
>     Please let me know your preference
>
>     Thanks
>
>     Hooman
>
> Thanks Hooman,
>
> That seems clear. I do think this is important enough to see the 
> requirement called-out in a document that is published in 2025.
>
> I suggest the simplest could be to simply quote the text from RFC 
> 4379, something like:
>
> [[The security considerations in RFC 4379 apply to this document, and 
> specifically it is noted
>
>    "To avoid potential Denial-of-Service attacks, it is RECOMMENDED that
>    implementations regulate the LSP ping traffic going to the control
>    plane.  A rate limiter SHOULD be applied to the well-known UDP port"
>    allocated for this service."
>
> ]]
>
> Please let me know if this or similar text can be included in the 
> security considerations?
>
> Best wishes,
>
> Gorry
>
>     *From:*Gorry Fairhurst <[e-mail]>
>     <mailto:[e-mail]>
>     *Sent:* Friday, September 12, 2025 5:03 AM
>     *To:* Hooman Bidgoli (Nokia) <[e-mail]>
>     <mailto:[e-mail]>; The IESG <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc:* [e-mail];
>     [e-mail]; [e-mail]; [e-mail]
>     *Subject:* Re: Gorry Fairhurst's Discuss on
>     draft-ietf-pim-p2mp-policy-ping-15: (with DISCUSS and COMMENT)
>
>     	
>
>     *CAUTION:*This is an external email. Please be very careful when
>     clicking links or opening attachments. See the URL nok.it/ext for
>     additional information.
>
>     On 11/09/2025 21:25, Hooman Bidgoli (Nokia) wrote:
>
>         Hi Gorry
>
>           
>
>         My apologies for missing this email.
>
>           
>
>         Thanks for your comments.
>
>           
>
>         This document is the extension of RFC 6425 so I agree and added a sentence that security considerations of section 8 of RFC 6425 should be followed.
>
>           
>
>         Also I fixed the NiT.
>
>           
>
>         I hope this addresses your concern?
>
>           
>
>         Thanks
>
>         Hooman
>
>     Thanks for your reply,
>
>     My request was simply to learn out more about how this particular
>     method would provide rate-limiting (or congestion control). A
>     useful starting point would be to look at about whether the
>     requirement for rate-limiting in Section 6 of RFC 4379 applies.
>
>     I look forward to understanding this and was hoping that it would
>     then be possible to add some text to this proposed specification,
>     although I'd suggest in a modern specification the requirements
>     for safe sharing of the Internet needs to be in the body of the
>     specification, not just discussed as a security consideration.
>
>     Best wishes,
>
>     Gorry
>
>     (WIT AD)
>
>           
>
>           
>
>         -----Original Message-----
>
>         From: Gorry Fairhurst via Datatracker<[e-mail]> <mailto:[e-mail]> 
>
>         Sent: Monday, August 4, 2025 6:13 AM
>
>         To: The IESG<[e-mail]> <mailto:[e-mail]>
>
>         Cc:[e-mail];[e-mail];[e-mail];[e-mail];[e-mail]
>
>         Subject: Gorry Fairhurst's Discuss on draft-ietf-pim-p2mp-policy-ping-15: (with DISCUSS and COMMENT)
>
>           
>
>           
>
>         CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>           
>
>           
>
>           
>
>         Gorry Fairhurst has entered the following ballot position for
>
>         draft-ietf-pim-p2mp-policy-ping-15: 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 tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>
>         for more information about how to handle DISCUSS and COMMENT positions.
>
>           
>
>           
>
>         The document, along with other ballot positions, can be found here:
>
>         https://datatracker.ietf.org/doc/draft-ietf-pim-p2mp-policy-ping/
>
>           
>
>           
>
>           
>
>         ----------------------------------------------------------------------
>
>         DISCUSS:
>
>         ----------------------------------------------------------------------
>
>           
>
>         Thanks for preparing this document.
>
>           
>
>         As I understand, the described mechanism generates a response over a protocol that is not rate-limited or congestion controlled. Therefore, I'd like to see text that guards against a Denial-of-Service attack to send MPLS echo requests/replies that seek to increase their workload. As such, I suggest a warning/scoping is added that this traffic needs to avoid sending/processing such requests, possibly in the last para of the introduction.
>
>           
>
>         RFC 6425 includes some text that might be a suitable starting point:
>
>           
>
>             As is described in [RFC4379], to avoid potential denial-of-service
>
>             attacks, it is RECOMMENDED to regulate the LSP ping traffic passed to
>
>             the control plane.  A rate limiter should be applied to the incoming
>
>             LSP ping traffic.
>
>           
>
>           
>
>         ----------------------------------------------------------------------
>
>         COMMENT:
>
>         ----------------------------------------------------------------------
>
>           
>
>         NiT:
>
>           
>
>         /As specified in section 3.2 of [RFC6425] ,/As specified in section 3.2 of [RFC6425],/
>
>         - Please remove space before comma.
>
>           
>
>           
>