[pim] 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 <[email protected]>
> *Sent:* Friday, September 12, 2025 5:03 AM
> *To:* Hooman Bidgoli (Nokia) <[email protected]>; The IESG 
> <[email protected]>
> *Cc:* [email protected]; [email protected]; 
> [email protected]; [email protected]
> *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<[email protected]> <mailto:[email protected]> 
>
>     Sent: Monday, August 4, 2025 6:13 AM
>
>     To: The IESG<[email protected]> <mailto:[email protected]>
>
>     Cc:[email protected];[email protected];[email protected];[email protected];[email protected]
>
>     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.
>

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]