Hi Roman, Thanks! Fantastic to know that we have converged. Thanks again for your great review!
Alberto From: Roman Danyliw <r...@cert.org> Date: Thursday, February 23, 2023 at 2:54 PM To: Alberto Rodriguez-Natal (natal) <na...@cisco.com>, The IESG <i...@ietf.org> Cc: draft-ietf-lisp-pub...@ietf.org <draft-ietf-lisp-pub...@ietf.org>, lisp-cha...@ietf.org <lisp-cha...@ietf.org>, lisp@ietf.org <lisp@ietf.org>, g...@gigix.net <g...@gigix.net> Subject: RE: Roman Danyliw's Discuss on draft-ietf-lisp-pubsub-13: (with DISCUSS and COMMENT) Hi Alberto! Thanks for this -14 revision and the explanations below. It addresses all of DISCUSS and COMMENT feedback. I’ve cleared my ballot. Thanks, Roman From: Alberto Rodriguez-Natal (natal) <na...@cisco.com> Sent: Monday, February 20, 2023 3:09 PM To: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org> Cc: draft-ietf-lisp-pub...@ietf.org; lisp-cha...@ietf.org; lisp@ietf.org; g...@gigix.net Subject: Re: Roman Danyliw's Discuss on draft-ietf-lisp-pubsub-13: (with DISCUSS and COMMENT) Hi Roman, Thanks again for your review! A revised version of the draft (-14) has just been uploaded. To address your DISCUSS, version -14 adds a third bullet to Section 3 to mention that a security association is required between the ITR and Map-Server (via LISP-SEC or PSK). Version -14 should also address the rest of your feedback, following the conversation below. Let us know what you think. Thanks! Alberto From: Alberto Rodriguez-Natal (natal) <na...@cisco.com<mailto:na...@cisco.com>> Date: Thursday, February 16, 2023 at 4:12 PM To: Roman Danyliw <r...@cert.org<mailto:r...@cert.org>>, The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: draft-ietf-lisp-pub...@ietf.org<mailto:draft-ietf-lisp-pub...@ietf.org> <draft-ietf-lisp-pub...@ietf.org<mailto:draft-ietf-lisp-pub...@ietf.org>>, lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org> <lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org>>, lisp@ietf.org<mailto:lisp@ietf.org> <lisp@ietf.org<mailto:lisp@ietf.org>>, g...@gigix.net<mailto:g...@gigix.net> <g...@gigix.net<mailto:g...@gigix.net>> Subject: Re: Roman Danyliw's Discuss on draft-ietf-lisp-pubsub-13: (with DISCUSS and COMMENT) Hi Roman, Thanks a lot for your review! Please see inline. Thanks! Alberto From: Roman Danyliw via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Date: Thursday, February 16, 2023 at 1:48 AM To: The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: draft-ietf-lisp-pub...@ietf.org<mailto:draft-ietf-lisp-pub...@ietf.org> <draft-ietf-lisp-pub...@ietf.org<mailto:draft-ietf-lisp-pub...@ietf.org>>, lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org> <lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org>>, lisp@ietf.org<mailto:lisp@ietf.org> <lisp@ietf.org<mailto:lisp@ietf.org>>, g...@gigix.net<mailto:g...@gigix.net> <g...@gigix.net<mailto:g...@gigix.net>>, g...@gigix.net<mailto:g...@gigix.net> <g...@gigix.net<mailto:g...@gigix.net>> Subject: Roman Danyliw's Discuss on draft-ietf-lisp-pubsub-13: (with DISCUSS and COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-lisp-pubsub-13: 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-pubsub/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** In following the robust discussion in the TSVART thread (https://mailarchive.ietf.org/arch/msg/tsv-art/vcJRc6oXRRiCl5-bouLTyRVbTc8/), it appears that design assumption of this document is to build on RFC9301 and RFC9303. Section 3 helpfully outlines unique deployment assumptions for PubSub relative to RFC301. Missing is an explicit summary of what Alberto stated in https://mailarchive.ietf.org/arch/msg/tsv-art/80yDl25rP3Ev4H_x_rOstue_J7M/. There appears to be a stronger requirements to use LISP-SEC or associated pre-shared secret to secure this new mechanism which is not the same as the baseline RFC9301 (per Section 1.1). [AR] Yes, a PubSubKey is required for PubSub operation, this can be a PSK or can be generated via LISP-SEC, both options are described in Section 7.1. In early versions of the draft (-05 and prior), there used to be a bullet point in the deployment assumptions that mentioned that a security association was required for PubSub, but the bullet point was removed when section 7.1 was introduced in -06. We can add again a bullet point to the deployment assumptions to mention that a PubSubKey is needed (via PSK or LISP-SEC) and that details are in Section 7.1. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** 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. ** The shepherd report noted that this document was moved from experimental to PS status based on existing deployment experiment. As this was the basis of the document status, is it possible read more about these “production networks” that were running “early implementations” as described in Appendix A. Who were they? Were all these implementations limited domain? Any over the Internet? [AR] The most predominant example (afaik) of PubSub running in production is in the Software-Defined Access (SD-Access) solution from Cisco. SD-Access is a solution that enterprises deploy for their campus networks where the overlay is established over an underlay of campus switches. Both the underlay and overlay are under the control of the enterprise. ** Section 1. Editorial. Is the “encap” in the phrase “map-and-encap approach” a shortening of “encapsulate”? Spell it out. [AR] Ack ** Section 1.1. Thanks for added this section based on TSVART review. Consider if it possible to qualify which of these verification and configurations are handled with practices outside the scope of this document and what can be forward referenced into this document. [AR] We’ll clarify the text. ** Section 5. Otherwise, the Map-Server silently drops the Map-Request message and logs the event to record that a replay attack could have occurred. Why is the guidance to log when observing an attack weaker than the guidance in Section 4 when handling malformed Map-Requests (“In this case, the receiver SHOULD log a malformed Map-Request and MUST drop the message.”) [AR] We’ll update the text so the same guidance is provided for both cases. ** Section 5. For example, the Map-Server may be instructed to limit the resources that are dedicated to unsolicited Map-Notify messages to a small fraction (e.g., less than 10%) of its overall processing and forwarding capacity. What is an unsolicited “Map-Notify” message in the PubSub context? Is that the PubSub message itself? [AR] The publication message yes. ** Section 5 If the Map-Server does not keep last nonces seen, then in deployments concerned with replay attacks the Map-Server MUST require the xTRs to subscribe using the procedure described in Section 7.1 to create a new security association with the Map-Server. What is a “deployment concerned with replay attacks”? Shouldn’t that be all deployments? Section 7.1 has similar text. [AR] We’ll update this text. ** Section 7. To prevent xTR-ID hijacking, it is RECOMMENDED to follow guidance from Section 9 of [RFC9301] to ensure integrity protection of Map- Request messages. Can this text be more specific on what text in RFC9301 is being referenced. [AR] The text is referring to Section 9 of RFC9301 (Security Considerations), particularly the last paragraph. We’ll update this to make it more specific. ** Section 7.1 First, when the ITR is sending a Map-Request with the N-bit set following Section 5, the ITR also performs the steps described in Section 5.4 of [RFC9303]. RFC9303 doesn’t have a Section 5.4. Is it Section 6.4? [AR] That’s correct, thanks for catching this up! ** Section 7.1 The ITR can then generate a PubSubKey by deriving a key from the One-Time Key (OTK) as follows: PubSubKey = KDF( OTK ), where KDF is the Key Derivation Function indicated by the OTK Wrapping ID. Should the Map-Request nonce be used as part of the KDF input? See Section 3.1 of RFC5869. [AR] That’s a reasonable suggestion, we’ll update the text to reflect it.
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
