Thank you, Mike Bishop, for your detailed review and comments. Kindly find responses inline. All accepted comments are implemented in ver-13 Thanks Prasad
-----Original Message----- From: Mike Bishop via Datatracker <[email protected]> Sent: Tuesday, September 15, 2026 09:28 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Mike Bishop's Discuss on draft-ietf-lisp-rfc6831bis-08: (with DISCUSS and COMMENT) Mike Bishop has entered the following ballot position for draft-ietf-lisp-rfc6831bis-08: 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-lisp-rfc6831bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # IESG review of draft-ietf-lisp-rfc6831bis-08 CC @MikeBishop -08 was posted just as I balloted previously, so updating to track. ## Discuss ### Section 13 I am surprised, to put it mildly, that the new support for unicast underlays doesn't bring with it any new Security Considerations. This text appears largely unchanged from RFC 6831. The new unicast mode makes the ITR's replication list programmable by a remote party via RFC 8059's Receiver ETR RLOC Attribute. Yet RFC 8059 says "Security of Join/Prune attributes is only guaranteed by the security of the PIM packet. The attributes specified herein do not enhance or diminish the privacy or authenticity of a Join/Prune message." That sounds suspiciously like a traffic-redirection/amplification vector. Has this been analyzed anywhere? If there's an existing mitigation (deployment assumed fully trusted/single-operator, some out-of-band ACL, rate limiting at the ITR) it should be stated. GVP1> Agreed, added the following text to mitigate the unicast underlay (and cover multicast underlay). I hope this mitigates the security risk of traffic-redirection. <t> <xref target="RFC9303"/> defines a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. This can be leveraged by LISP-Multicast to authenticate genuine PIM Joins and also avoid any DDoS attacks or geting unauthorized access to multicast traffic.</t> ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ### RFC 6832: Normative vs. Informative? Comes up in several places within Section 9. Seems less critical to me than RFC 8059, but still worth a check. GVP1> Retained as Informative #### Section 9, paragraph 1 ``` This section describes the multicast corollary to [RFC6832] regarding the interworking of multicast routing among LISP and non-LISP sites. ``` Is the multicast restatement of this problem in this document complete enough to be read and implemented *without* consulting RFC6832? GVP1> This is correct in my understanding, #### Section 9.1.1, paragraph 1 ``` propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP Network Address Translation (LISP-NAT) in [RFC6832] solves. ``` Are you sure that an understanding of LISP-NAT isn't required to implement this section? GPV1> True, although knowing the broader context helps. #### Section 9.1.1, paragraph 5 I'm unclear how an ITR decides when it should route via an mPETR. Is this clearly stated somewhere in this document or does it depend on RFC6832? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### "Abstract", paragraph 1 ``` - obsoletes RFC6831 + obsoletes RFC 6831. + + + ``` GVP1> Fixed #### Section 1, paragraph 4 ``` - in other sites that are LISP enabled. - ^ + in other sites that are LISP-enabled. + ^ ``` GVP1> Fixed #### Section 1, paragraph 13 ``` - even when the site is LISP enabled. That is, internal operation of - ^ - multicast is unchanged, regardless of whether or not the site is LISP + even when the site is LISP-enabled. That is, internal operation of + ^ + multicast is unchanged, regardless of whether or not the site is LISP- + + ``` GVP1> Fixed #### Section 1, paragraph 13 ``` - LISP enabled. - ^ + LISP-enabled. + ^ ``` GVP1> Fixed #### Section 1, final paragraph ``` This document obsoletes [RFC6831]; please see Appendix A for changes. ^ ^ ``` GVP1> Fixed #### Section 3, paragraph 10 ``` +SP site (uLISP Site) that is also multicast-capable according to the procedur + ^ ``` GVP1> Fixed #### Section 4, paragraph 14 ``` - where fan-out occurs to multiple sites, a underlay router will + where fan-out occurs to multiple sites, an underlay router will + + ``` GVP1> Fixed #### Section 9.1, paragraph 1 ``` - LISP enabled. So, most of the implications are in the underlay with - ^ + LISP-enabled. So, most of the implications are in the underlay with + ^ ``` GVP1> Fixed #### Section 9.1, paragraph 6 ``` - are LISP-Multicast enabled; that has been discussed in previous - ^ + are LISP-Multicast-enabled; that has been discussed in previous + ^ ``` GVP1> Fixed #### Section 9.1.1, paragraph 1 ``` - In the first scenario, a site is LISP enabled for both unicast and - ^ + In the first scenario, a site is LISP-enabled for both unicast and + ^ ``` GVP1> Fixed #### Section 9.1.1, paragraph 4 ``` - site is LISP enabled or not. When it is not LISP enabled, the ITR - ^ ^ + site is LISP-enabled or not. When it is not LISP-enabled, the ITR + ^ ^ ``` GVP1> Fixed #### Section 9.1.4, paragraph 1 ``` - receiver site can determine if a source multicast site is LISP + receiver site can determine if a source multicast site is LISP- + + ``` GVP1> Fixed #### Section 9.1.4, paragraph 1 ``` - multicast site is a uLISP site, it is LISP enabled, but the ITR, by - ^ + multicast site is a uLISP site, it is LISP-enabled, but the ITR, by + ^ ``` GVP1> Fixed #### Section 9.1.4, paragraph 3 ``` - sites; since they think the source multicast site is LISP enabled, - ^ - the ETR cannot know if the ITR is LISP-Multicast enabled. To solve - ^ + sites; since they think the source multicast site is LISP-enabled, + ^ + the ETR cannot know if the ITR is LISP-Multicast-enabled. To solve + ^ ``` GVP1> Fixed #### Section 9.2, paragraph 16 ``` - either LISP-Multicast or uLISP enabled. This means that priority- - ^ + either LISP-Multicast- or uLISP-enabled. This means that priority- + + ^ ``` GVP1> Fixed #### Section 9.2, paragraph 18 ``` - * When the source site is not LISP enabled, determining the address - ^ + * When the source site is not LISP-enabled, determining the address + ^ ``` GVP1> Fixed #### Section 13, paragraph 3 ``` - mechanisms deployed for PIM [RFC7761] + mechanisms deployed for PIM [RFC7761]. + + ``` GVP1> Fixed #### Section 14, paragraph 1 ``` - No requests are made to IANA + No requests are made to IANA. + + ``` GVP1> Fixed ### Section 3, paragraph 15 ``` infrastructure. It is likely a unicast PITR [RFC6832] hereafter referred to as uPITR in this document and an mPETR will be co- ``` This defines a new term inside the definition of a different term. Extract "uPITR" as its own term and definition. ### Section 7.1, paragraph 2 ``` specified in [I-D.ietf-pim-rfc8059-9798bis]. ``` This is both a Normative *and* an Informative reference with different tags. Consolidate, please. GVP1> Fixed, only Normative now ### Section 9.1.1, paragraph 6 ``` their way in the underlay to multicast PxTRs. Let's call this use of ``` Generally best to avoid first-person language in RFCs. GVP1> Fixed all occurrences ### Section 12, paragraph 2 ``` [MTRACE] [RFC8487]. ``` MTRACE appears to *be* RFC8487; why cite both? ### Grammar/style #### Section 3, paragraph 5 ``` ETR): as defined in [RFC9300]. Additionally it is a router that is on the pa ^^^^^^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Additionally". GVP1> Fixed #### Section 3, paragraph 7 ``` any-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". GVP> Fixed #### Section 8, paragraph 3 ``` ticast site joins (S1-EID,Gi) through a underlay distribution tree of (RLOC1, ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". GVP> Fixed #### Section 9.1.5, paragraph 1 ``` ves an (S-EID,G) join, it must select a S-RLOC for the same address family as ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". GVP> Fixed ## Notes This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
