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

["Hooman Bidgoli (Nokia)" <[e-mail]>]

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


From: Gorry Fairhurst <[e-mail]>
Sent: Friday, September 12, 2025 5:03 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)


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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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 to https://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.