Re: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-pubsub-13: (with DISCUSS and COMMENT)

["Alberto Rodriguez-Natal (natal)" <[e-mail]>]

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) <[e-mail]>
Date: Thursday, February 16, 2023 at 4:12 PM
To: Roman Danyliw <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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 <[e-mail]>
Date: Thursday, February 16, 2023 at 1:48 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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.