Re: [lisp] AD Review of draft-ietf-lisp-pubsub-09

[Alvaro Retana <[e-mail]>]

On April 26, 2022 at 6:05:24 PM, Dino Farinacci wrote:

> Alvaro, here are some responses. I cut out text I didn't need to comment on.

Thanks Dino -- some replies inline.



> > [major] This is the only place, including rfc6830bis/rfc6833bis, where
> > "proxy-reply mode" is used. Is this operation specified anywhere,
> > maybe using a different name? This seems to be related to the
> > Map-Server being able to offer non-authoritative Map-Replies -- please
> > be specific.
>
> In 6833bis, we refer to the P-bit in the Map-Register as "proxy Map-Reply
> bit". And occurs 11 times in 6833bis.

Ah, ok.  Please just be consistent with the terminology.  Not everyone
is as familiar with lisp -- including me, of course! :-)



> > [major] What happens if one of these assumptions is not met? If the
> > rest of the specification is followed (setting the I and N bits, etc.)
> > what are the "failure scenarios" if the conditions are not met?
>
> When the N bit is not set, the message is processed like a regular
> Map-Request (and state is not put in the subscription cache on the map-
> server). That wasn't clear? Alberto?

The assumptions I was referring to are these:

129	3.  Deployment Assumptions

131	   The specification described in this document makes the following
132	   deployment assumptions:

134	   (1)  A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
135	        assigned to each xTR.

137	   (2)  Map-Servers are configured in proxy-reply mode, i.e., they are
138	        solicited to generate and send Map-Reply messages for the
139	        mappings they are serving.

I think all I'm looking for is a short explanation that the pubsub
will not work.  Maybe something like this:

   If either assumption is not met, a subscription cannot be
   established and the network will continue operating without
   this enhancement.



> > 144 4. Map-Request PubSub Additions
> > ...
> > 190 xTR-ID bit (I-bit): This bit is set to 1 to indicate that a 128
> > 191 bit xTR-ID and a 64 bit Site-ID fields are present at the end of
> > 192 the Map-Request message. For PubSub operation, an xTR MUST be
> > 193 configured with an xTR-ID and Site-ID, and it MUST set the I bit
> > 194 to 1 and include its xTR-ID and Site-ID in the Map-Request
> > 195 messages it generates.
...
> > [major] "MUST set the I bit to 1 and include its xTR-ID and Site-ID"
> >
> > What should the receiver do if the I bit is set but the ID fields are
> > not included?
...
>
> We will fix this. If the I bit not set, the Map-Request is not processed as a
> subscribe-request.

The question was the other way around: what if the I-bit is set but
the IDs are not included?   The lengths are handled by the IP/UDP
header lengths, so the Map-Request (and the rest of the packet) may
have the correct length while still having the I-bit set.

I assume the answer is that the subscription cannot be processed and
"normal" processing is done...but it should be stated in the document.




> > 253 (3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs
> > 254 received in the Map-Request (which one is implementation
> > 255 specific).
> >
> > [major] Does this need to be specified here? Where are Map-Notify
> > messages sent to? I couldn't find a specific answer, but it seems to
> > me that choosing a destination address should be pretty "basic"; i.e.
> > something that should have been specified in the base spec.
>
> It is basic but there are many choices, *especially* in the presents of NATs.
> You can send to one of the "Local" RLOCs or to the source IP address of the
> Map-Request. If you want to get the message back to the xTR you need to use
> the source IP address.

Yes.  The point was that choosing an address is not an issue that
comes up only when sending Map-Notify messages when using pubsub -- it
is a general issue.  Any considerations should be mentioned in the
"general" document (rfc6833bis) so that all extensions can benefit and
don't have to include additional text about it.



> > 331 When the xTR receives a Map-Notify with an EID not local to the xTR,
> > 332 the xTR knows that the Map-Notify has been received to update an
> > 333 entry on its map-cache. Processing of unsolicited Map-Notify
> > 334 messages MUST be explicitly enabled via configuration at the xTR.
> > 335 The xTR MUST keep track of the last nonce seen in a Map-Notify
> > 336 received as a publication from the Map-Server for the EID-Record. If
> > 337 a Map-Notify received as a publication has a nonce value that is not
> > 338 greater than the saved nonce, the xTR drops the Map-Notify message
> > 339 and logs the fact a replay attack could have occurred. To compare
> > 340 two nonces, the xTR uses the serial number arithmetic defined in
> > 341 [RFC1982] with SERIAL_BITS = 64. The nonce field space (64 bits) is
> > 342 considered large enough to not be depleted during normal operation of
> > 343 the protocol (e.g., assuming a fast publication rate of one Map-
> > 344 Notify per EID-Record per Map-Server per second, the nonce field
> > 345 space will not be depleted in 0.5 trillion years). The same
> > 346 considerations discussed in Section 5.6 of [I-D.ietf-lisp-rfc6833bis]
> > 347 regarding storing Map-Register nonces apply here for Map-Notify
> > 348 nonces.
> >
> > [major] "Processing of unsolicited Map-Notify messages MUST be
> > explicitly enabled via configuration at the xTR."
> >
> > rfc6833bis added the Map-Notify-Ack, but it doesn't require
> > configuration anywhere to process unsolicited Map-Notify messages.
> > IOW, this requirement is not in line with rfc6833bis.
>
> Its because in 6833bis all Map-Notify messages are always solicited.

Yes, I missed that.

Can it be assumed that if the xTR sends a "subscription request" it
will accept unsolicited Map-Notify messages?  This may be an
implementation detail, but it seems to me that adding the extra
configuration step is unnecessary if the xTR is requesting the
information.


Alvaro.