Hi Prasad, yes, I think that would be good. But see also my concern about a possible DoS since data from S-EID2 may be received by S-EID1? ________________________________ From: Vengada Prasad Govindan (venggovi) <[email protected]> Sent: Friday, September 11, 2026 06:10 To: Magnus Nyström <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: RE: draft-ietf-lisp-rfc6831bis-06 ietf last call Secdir review
Hello Magnus, Thank you for your comments, please see inline with GVP1> Thanks Prasad -----Original Message----- From: Magnus Nyström via Datatracker <[email protected]> Sent: Tuesday, September 1, 2026 11:35 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: draft-ietf-lisp-rfc6831bis-06 ietf last call Secdir review Document: draft-ietf-lisp-rfc6831bis Title: The Locator/ID Separation Protocol (LISP) for Multicast Environments Reviewer: Magnus Nyström Review result: Has Nits The document is well written and seems to cover all cases of interoperability with existing protocol implementations etc. However, I do wonder about one statement in the Security Considerations section: "There may be a security concern with respect to unicast PIM messages. When multiple receiver sites are joining an (S-EID1,G) distribution tree that maps to a (RLOC1,G) underlay distribution tree, and a malicious receiver site joins an (S-EID2,G) distribution tree that also maps to the (RLOC1,G) underlay distribution tree, the legitimate sites will receive data from S-EID2 when they did not ask for it." - Isn't this a security concern? Why only a "may"? I think (but may be wrong) that this is also related to the text in the penultimate paragraph of Section 4, starting "For example, one site joins (S-EID1,G), and another site joins (S-EID2,G)...". It seems - but, not being very well versed in LISP I could be wrong here - that not only can this situation (with a malicious receiver) result in legitimate sites receiving data from S-EID2 (with potential also for denial of service?) but also in the S-EID2 receiving data from the legitimate sites without their awareness? Should there not be a mechanism described to prevent these scenarios? Or is there? Thanks, GVP1> RFC7761 (PIM) provides Non-cryptographic Authentication Mechanisms by which the set of neighbors that can Join/ Prune groups can be limited. The same mechanisms apply to LISP as well. I can update the Security Considerations of this draft with a pointer to RFC7761 in the Security considerations section if you are ok with it.
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
