Ballot for draft-ietf-lisp-pubsub
Yes
No Objection
No Record
Note: This ballot was opened for revision 10 and is now closed.
# Internet AD comments for draft-ietf-lisp-pubsub-11 CC @ekline ## Comments * Should this update RFC 9301 (since it's modifying the Map-Request)? (debated making this a trivial-to-fix DISCUSS)
Thanks for this well-crafted (albeit dense) document. I have one question. While I don't think it needs to be a blocking issue, I'd still appreciate discussion. In Section 7.1, you write, If PubSub is being used in an environment where replay attacks might occur, then the Map-Server MUST verify that the OTK has not been used before. I strained to think of a realistic deployment where the threat model was one where security was required, but replay protection was NOT required. Can you provide an example of one?
Thanks for a well done IANA Considerations section. In Section 1, in that list of steps, it looks strange that in step 1 you send a request, and then in step 2 you mutate a bit on the request. Is that possible? Or would it be better to say that in step 1 you construct a request that has this bit set, and in step 2 you send it? An editorial point: "ITR/RTR/PITR" or some variant of it appears several times. Could there be a single term that encapsulates all three? Repeating that cluster of initialisms has me reading it like "this or that or the other" each time, and it feels like it could be simplified. In Section 5: "If the Map-Server removes the subscription state, it SHOULD notify the xTR by sending a single Map-Notify with the same nonce but with Loc-Count = 0 (and Loc-AFI = 0), and ACT bits set to 5 "Drop/Auth-Failure"." Why is this only a SHOULD? Also in Section 5: "If the subscription request fails, the Map-Server MUST send a Map-Reply to the originator ..." That should be a "Negative Map-Reply", right?
** Thank you to Chris M. Lonvick for the SECDIR review. ** Thank you to Magnus Westerlund for the TSVART review which had a number of security items of feedback. Thank you for addressing my DISCUSS and COMMENT feedback.
Much thanks to Al Morton for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-lisp-pubsub-10-opsdir-lc-morton-2023-01-22/) I'm at a conference (NANOG) this week, and so the OpsDir reviews are especially useful. I've provided some nits below -- feel free to address them when making other changes, or ignore them (they are just nits): 1: "The Locator/ID Separation Protocol (LISP) [RFC9300] [RFC9301] splits IP addresses in two different namespaces" - I think this is: "splits IP addresses into two different namespaces" 2: "It is RECOMMENDED that the xTR uses persistent storage to keep nonce state." - I think this would be better as: "to keep the none state" 3: "The Map-Server that receives the Map-Request will be the Map-Server responsible to notify that specific xTR " -> "responsible for notifying" 4: "A similar problem may be experienced when a large number of state were simultaneously updated." - "states are" 5: "Alternatively, the Map-Server can instead determine that such subscription request fails, and send" - "requests fail" 6: "When the ITR wants to update the security association for that Map-Server and EID-Prefix, it follows again the procedure described in this section." -- I think that this is either "it follows the procedure described in this section again.", or 9probably better) "it once again follows..." 7: "Note that if the Map-Server replies with a Map-Notify, none of the regular LISP-SEC steps regarding Map-Reply described in Section 5.7 of [RFC9303] takes place." - for readability, I think this would be better as "take place" or "occur". 8: "Misbehaving nodes may send massive subscription requests which may lead to exhaust the resources of a Map-Server" - "exhausting" 9: (Appendix): "The following subsections provides an inventory of some experience lessons from these deployments." - "provide"
Thanks for working on this specification. Thanks to Magnus for his detailed TSVART review, that resulted in improvement is both transport and security related issues. I also strongly agree that this specification needs applicability statement to be added, as it is not aiming for "limited domain". I trust the responsible AD will make sure there will be applicability statement added as agreed here : https://mailarchive.ietf.org/arch/msg/tsv-art/ytuGgsIoIVwHoLuq-wr2nPVLzJ4/ The LISP-SEC requirement has already been addressed by Roman is his ballot, hence supporting that discuss.
# Éric Vyncke, INT AD, comments for draft-ietf-lisp-pubsub-13 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Luigi Iannone for the shepherd's detailed write-up including the WG consensus. Other thanks to Sheng Jiang, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-lisp-pubsub-10-intdir-telechat-jiang-2023-02-09/ and I read the author's reply. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Updating RFC 9301 ? Like Erik Kline, I wonder whether this I-D should formally update RFC 9301. Or is the IANA registry addition enough ? ### Section 5 and intended status ``` The exact details to characterize such policies are deployment and implementation specific. Likewise, this document does not specify which notifications take precedence when these policies are enforced. ``` This is indeed my biggest concern about this mechanism as it can trigger a flood of Map-Notify when a EIP mapping changes. PubSub is nice when there is one publisher and many potential subscribers but in this specific case it is several publishers to several subscribers with many subscriptions. An experimental status would be more comforting. ### Missed notification If for any reason a Map-Notify is missed (e.g., publisher is overloaded), then what is the fall-back ? When a Map-Request gets no response, then the Map-Request can be resent by the xTR but in the case of Map-Notify ? There is some text in section 5, but only from the point of view of the publisher. ### Appendix A.1 The monitoring use case is indeed quite a useful one. My comments above do not really apply in this use case. ## 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. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
The IANA section lists a new "LISP Control Plane Header Bits: Map-Request-Record" registry, and assigns 1 bit in it, but it is unclear how many remaining unassigned bits are left
# GEN AD review of draft-ietf-lisp-pubsub-11 CC @larseggert Thanks to Roni Even for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/cR9bos2756DfJOE43Wen3byzgyk). ## 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. ### Outdated references Document references `draft-boucadair-lisp-pubsub-flow-examples-01`, but `-03` is the latest available revision. ### URLs These URLs in the document did not return content: * https://www.lisp-lab.org ### Grammar/style #### Section 1, paragraph 8 ``` les] for sample flows to illustrate the the use of the PubSub specification. ^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5, paragraph 16 ``` Notification Publish Procedures The publish procedure is implemented via Map ^^^^^^^^^^^ ``` After "The", the verb "publish" doesn't fit. Is "publish" spelled correctly? If "publish" is the first word in a compound adjective, use a hyphen between the two words. Using the verb "publish" as a noun may be non-standard. #### Section 9.1, paragraph 3 ``` e time. The following subsections provides an inventory of some experience le ^^^^^^^^ ``` The verb form "provides" does not seem to match the subject "subsections". ## 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
Thanks to Magnus for the TSVART review, and the authors for the extended (!) discussion of that review. I have a few notes: (S1) the sequence of events omits the Map-Notify-Ack in response to the initial Map-Notify. (S5) "If the Map-Request has only one ITR-RLOC with AFI=0..." I assume this Map-Request has the I-bit set? (S5) The paragraph about congestion control that begins with "As a reminder..." is probably better in S6, as originally discussed in the thread, because it's the Publish Map-Notifies that are the most likely to trigger congestion. (S6) Just to clarify, the Map-Notify has no change from RFC9301 with respect to flags (unlike the Map-Request)? (S6) "...it may stop trying to send the Map-Notify" This seems too weak to me; why not cancel the subscription, or better yet, cancel all subscriptions to that xTR if it's unresponsive?
Hi, Thanks for this document. I have just one minor comment, in section 3, rather than phrasing this section as deployment assumptions, it might be better to phrase this as deployment requirements. Regards, Rob