Explicit entries

[boucadair]

The subscription state can also be created explicitly by configuration at the Map-Server (possible when a pre-shared security association exists, see Section 7). In this case, the initial nonce associated with the xTR-ID (and EID-Record) MUST be randomly generated by the Map-Server.

The behavior is underspecified.

[boucadair]

How the triggered Map-Notify are handled by the xTR given that they don't have a state? Do we allow xTRs to delete explicitly created subscriptions?

[arnatal]

How the triggered Map-Notify are handled by the xTR given that they don't have a state?

No special behavior is needed IMHO. Maybe we can just add a note to say that xTRs can disable via configuration the processing of "non-explicitly-subscribed" publications.

Do we allow xTRs to delete explicitly created subscriptions?

I would think so.

[boucadair]

No special behavior is needed IMHO

As no state matching the Map-Notify will be found in the xTR, the message will be discarded. How the xTR differentiates between an update of an explicitly configured state vs. a replay of an Map-Notify (which can be sent once an xTR has explicitly deleted the corresponding state)?

Maybe we can just add a note to say that xTRs can disable via configuration the processing of "non-explicitly-subscribed" publications.

Agree. Assuming we are able to unambiguously distinguish such Map-Notify.

I tend to simply delete the sentence about explicitly configured entries. If we maintain it, we need to add more text.

[arnatal]

No special behavior is needed IMHO

As no state matching the Map-Notify will be found in the xTR, the message will be discarded. How the xTR differentiates between an update of an explicitly configured state vs. a replay of an Map-Notify (which can be sent once an xTR has explicitly deleted the corresponding state)?

Currently Section 6 reads:

When the xTR receives a Map-Notify with an EID not local to the xTR, the xTR knows that the Map-Notify has been received to update an entry on its Map-Cache. The xTR MUST keep track of the last nonce seen in a Map-Notify received as a publication from the Map-Server for the EID-Prefix. When the LISP deployment has a single Map- Server, the xTR can be configured to keep track of a single nonce for all EID-Prefix (when used, this option MUST be enabled at the Map- Server and all xTRs). If a Map-Notify received as a publication has a nonce value that is not greater than the saved nonce, the xTR drops the Map-Notify message and logs the fact a replay attack could have occurred. The same considerations discussed in Section 5.6 of [RFC9301] regarding Map-Register nonces apply here for Map-Notify nonces.

The way I understand this is that the xTR will always be able to refer to the nonce to check if the message could had been replayed. Hope I'm not missing something.

Said that, it is true that we were missing some spec on the paragraph about explicit subscriptions (besides a note on a configuration option). We should say that the nonce is random only if the Map-Server doesn't have a suitable nonce (e.g. a single nonce per xTR-ID might be used and there might be subscription state for another prefix). I'll open a PR with a quick fix for your review.

[boucadair]

The way I understand this is that the xTR will always be able to refer to the nonce to check if the message could had been replayed. Hope I'm not missing something.

I think there is something I'm missing.

I always understood the explicit subscription in the draft as that the subscription is created on the Map-Server without requiring a Map-Request from the subscriber (xTR). Map-Notify that will be triggered by the update of such state will have a nonce, but I'm failing to see how nonce checks will help the xTR if the xTR does not have a local state in the first place.

[arnatal]

If the xTR has no state whatsoever for a nonce associated with the EID-Prefix, the xTR will create it with the first nonce it sees for that EID-Prefix. Assuming the considerations regarding persistent storage etc, are accounted for (for which Section 6 points to 9301), the first nonce seen has to be legit since an attacker cannot craft a brand new message (it's the missing the auth key) and for a message to be replayed it first needs to have been legitimately sent. This is my understanding at least.

[arnatal]

If the xTR has no state whatsoever for a nonce associated with the EID-Prefix, the xTR will create it with the first nonce it sees for that EID-Prefix. Assuming the considerations regarding persistent storage etc, are accounted for (for which Section 6 points to 9301), the first nonce seen has to be legit since an attacker cannot craft a brand new message (it's the missing the auth key) and for a message to be replayed it first needs to have been legitimately sent. This is my understanding at least.