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

[Roman Danyliw via Datatracker <[e-mail]>]

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).


----------------------------------------------------------------------
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?

** Section 1.  Editorial.  Is the “encap” in the phrase “map-and-encap
approach” a shortening of “encapsulate”?  Spell it out.

** 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.

** 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.”)

** 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?

** 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.

** 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.

** 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?

** 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.