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

[Dino Farinacci <[e-mail]>]

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