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

[Dino Farinacci <[e-mail]>]

Thanks Alberto. I can take care of the 6830bis and 6833bis changes if we need clarifications since it seems we have "opened" these documents for minor changes (per Luigi's email for 6834bis). I am waiting for Albert to give me the green flag for makingt the edits.

Dino

> On Apr 27, 2022, at 3:04 PM, Alberto Rodriguez-Natal (natal) <natal=[e-mail]> wrote:
> 
> Hi Alvaro, Dino,
>  
> I scanned through the comments and discussion and it seems that we’re all on the same page. Thanks to both for the great suggestions. Give me some time to provide some comments here, since I don’t have the bandwidth right now. I’d also try to close vendor-lcaf before moving into PubSub.
>  
> Thanks!
> Alberto
>  
> From: Dino Farinacci <[e-mail]>
> Date: Wednesday, April 27, 2022 at 9:04 PM
> To: Alvaro Retana <[e-mail]>
> Cc: [e-mail] list <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> Subject: Re: [lisp] AD Review of draft-ietf-lisp-pubsub-09
> 
> I agree with all your suggestions and hope Alberto will use as input to the changes he makes for the next rev.
> 
> >> [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! :-)
> 
> We will make the pubsub be consistent with the text from 6833bis.
> 
> >> [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.
> 
> Agree.
> 
> >> 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
> 
> Then there will be a parsing error and the last 128-bits/64-bits of the packet will be mistakenly processed as an xTR-ID/Site-ID. It means the sender did not conform to the spec. It is an implementation bug.
> 
> > 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.
> 
> No, that is not what happens. And I believe we DON'T need to change 6833bis for this. Or the pubsub draft. If the sender sets the I-bit, it is saying the the xTR-ID/Site-ID are at the end of the message. A receiver can detect the error because after processing that last EID-record, if there are no bytes left from processing the message, it can conclude that the I-bit was set errorneously.
> 
> > 
> >>> 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.
> 
> Well not totally true. It is only used because an ITR-RLOC is included in a Map-Request, so a responding Map-Reply message should use it. Since a Map-Notify is a Map-Request ack for a subscribption requesst, its only these two types of messages that have this issue. All other "replies" to "query type messages" uses the source IP address from the query.
> 
> > 
> > 
> >>> 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
> 
> Yes, but I'd argue about terminology. The Map-Notify is solicited because of the subscripton request. But the actual message is soliciting an acknowedge Map-Notify message.
> 
> We call it unsolicited, because some time later, if there is an RLOC-change to an EID subscribed, the message will come without any message requesting it (i.e. it is event triggered).
> 
> > implementation detail, but it seems to me that adding the extra
> > configuration step is unnecessary if the xTR is requesting the
> > information.
> 
> Right.
> 
> Dino
> 
> > 
> > 
> > Alvaro.
> > 
> > _______________________________________________
> > lisp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp