Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)

[Dino Farinacci <[e-mail]>]

Thanks Eric for your great comments. Like I said in previous emails, I’ll address the simple things here and then handle all the security related stuff separately next week.

I will do the same with Benjamin’s comments as well. And in his reply, send a diff with changes that reflect both Eric and Benjamin’s comments.

> On Sep 27, 2018, at 5:16 AM, Eric Rescorla <[e-mail]> wrote:
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4115
> 
> 
> IMPORTANT
> S 5.2.
>>     s: This is the SMR-invoked bit.  This bit is set to 1 when an xTR is
>>        sending a Map-Request in response to a received SMR-based Map-
>>        Request.
>> 
>>     m: This is the LISP mobile-node m-bit.  This bit is set by xTRs that
>>        operate as a mobile node as defined in [I-D.ietf-lisp-mn].
> 
> This would appear to create a normative reference to this document. To
> avoid that, you need to specify how I behave if I receive it but I
> don't implement lisp-mn.

I am find making it a normative reference but need the lisp-chairs to comment. I am not sure what the implications of that are.

> 
> S 5.2.
>>     m: This is the LISP mobile-node m-bit.  This bit is set by xTRs that
>>        operate as a mobile node as defined in [I-D.ietf-lisp-mn].
>> 
>>     I: This is the xTR-ID bit.  When this bit is set, what is appended to
>>        the Map-Request is a 128-bit xTR router-ID.  See LISP PubSub usage
>>        procedures in [I-D.ietf-lisp-pubsub] for details.
> 
> here too you seem to be creating a normative reference.

LISP-chairs?

> S 5.5.
>>        is being mapped from a multicast destination EID.
>> 
>>  5.5.  EID-to-RLOC UDP Map-Reply Message
>> 
>>     A Map-Reply returns an EID-Prefix with a prefix length that is less
>>     than or equal to the EID being requested.  The EID being requested is
> 
> How do I behave if I receive an EID-Prefix that is less than any of my
> mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16
> and someone asks me for 10.0.0.0/8? Also, when you talk about prefix
> length, I assume you mean the length fo the mask?

Yes, this is explained later in this section. Was that not helpful??

> S 5.6.
>>     Authentication Data:  This is the message digest used from the output
>>        of the MAC algorithm.  The entire Map-Register payload is
>>        authenticated with this field preset to 0.  After the MAC is
>>        computed, it is placed in this field.  Implementations of this
>>        specification MUST include support for HMAC-SHA-1-96 [RFC2404],
>>        and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED.
> 
> What prevents replay attacks here? I'm guessing it's the Map-Version-
> Number, but as I understand it, I can set this to 0.

Well there are many. The nonce can change for each Map-Register sent. Same for Map-Version number as well as the key-id. 

> S 6.1.
>>     receives an SMR-based Map-Request and the source is not in the
>>     Locator-Set for the stored Map-Cache entry, then the responding Map-
>>     Request MUST be sent with an EID destination to the mapping database
>>     system.  Since the mapping database system is a more secure way to
>>     reach an authoritative ETR, it will deliver the Map-Request to the
>>     authoritative source of the mapping data.
> 
> If I'm understanding this correctly, this allows an ETR to prevent an
> ITR from learning that it is no longer the appropriate ETR for a
> prefix. The way this attack works is that before the topology shift, I
> send SMRs, thus causing Map-Requests, which, because my entry is
> cached, refresh the cache on the ITR past the topology shift. I can
> keep doing this indefinitely. Am I missing something

Well if the ETR is being spoofed, then there is Map-Request load, but it won’t corrupt the ITR’s map-cache. The ITR always sends a verifying Map-Request to the mapping system to get the latest and authenticated RLOC-set for the mapping. Rate-limiting is necessary so each SMR received DOES NOT result in a Map-Requerst to the mapping system.

> S 8.2.
>>     authentication data, so prior to sending a Map-Register message, the
>>     ETR and Map-Server SHOULD be configured with a shared secret or other
>>     relevant authentication information.  A Map-Server's configuration
>>     SHOULD also include a list of the EID-Prefixes for which each ETR is
>>     authoritative.  Upon receipt of a Map-Register from an ETR, a Map-
>>     Server accepts only EID-Prefixes that are configured for that ETR.
> 
> How does it know?

It is provisioned by the mapping service provider (MSP). When the LISP site is allocated an EID-prefix, it configures all the xTRs that connect that site. And then the LISP site (the admins at the site), shop for an MSP and tell them what EID-prefixes, they will be registering. That is when the shared-key between the LISP site and MSP is exchanged via a manul out-of-band business process.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> S 5.
>>       \ |           UDP Length          |        UDP Checksum           |
>>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>         |                                                               |
>>         |                         LISP Message                          |
>>         |                                                               |
>>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> What do these two diagrams correspond to? v4 and v6? This needs
> explanation.

It is th entire IP packet sent as a LISP control-message. The header before the diagrams indicate they are UDP packets.

> S 5.2.
>>     Type:   1 (Map-Request)
>> 
>>     A: This is an authoritative bit, which is set to 0 for UDP-based Map-
>>        Requests sent by an ITR.  It is set to 1 when an ITR wants the
>>        destination site to return the Map-Reply rather than the mapping
>>        database system.
> 
> I don't understand this sentence, as literally it would say that you
> should not return "the mapping database system" but that doesn't make
> any sense.

This was already fixed in a later revision. Now says:

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.  It is set to 1 when an ITR wants the
      destination site to return the Map-Reply rather than the mapping
      database system returning a Map-Reply.

> 
> S 5.2.
>>     P: This is the probe-bit, which indicates that a Map-Request SHOULD
>>        be treated as a Locator reachability probe.  The receiver SHOULD
>>        respond with a Map-Reply with the probe-bit set, indicating that
>>        the Map-Reply is a Locator reachability probe reply, with the
>>        nonce copied from the Map-Request.  See RLOC-Probing Section 7.1
>>        for more details.
> 
> How am I supposed to handle this if I am a Map Server.

It should be ignored. I will add text to reflect this point. Good point.

> 
> S 5.2.
>>        receipt.
>> 
>>     L: This is the local-xtr bit.  It is used by an xTR in a LISP site to
>>        tell other xTRs in the same site that it is part of the RLOC-set
>>        for the LISP site.  The L-bit is set to 1 when the RLOC is the
>>        sender's IP address.
> 
> Is the xTR supposed to filter this on exiting the site.

Nope.

> 
> S 5.2.
>> 
>>     Nonce:  This is an 8-octet random value created by the sender of the
>>        Map-Request.  This nonce will be returned in the Map-Reply.  The
>>        security of the LISP mapping protocol critically depends on the
>>        strength of the nonce in the Map-Request message.  The nonce
>>        SHOULD be generated by a properly seeded pseudo-random (or strong
> 
> This seems like it needs to be a MUST.

Yes, I agree. I cannot remember why we made it a SHOULD.

> 
> S 5.3.
>>     originating Map-Request source.  If the RLOC is not in the Locator-
>>     Set, then the ETR MUST send the "verifying Map-Request" to the
>>     "piggybacked" EID.  Doing this forces the "verifying Map-Request" to
>>     go through the mapping database system to reach the authoritative
>>     source of information about that EID, guarding against RLOC-spoofing
>>     in the "piggybacked" mapping data.
> 
> This text here doesn't seem compatible with either of the two cases
> listed in "EID-prefix" above.

I don’t understand the comment Eric. Maybe because I can’t find the exact reference to EID-prefix where you think there is a conflict. Please cite for me. Thanks.

> 
> S 5.4.
>> 
>>     Nonce:  This is a 24-bit value set in a Data-Probe
>>        [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request
>>        is echoed in this 'Nonce' field of the Map-Reply.  When a 24-bit
>>        value is supplied, it resides in the low-order 64 bits of the
>>        'Nonce' field.
> 
> Nit: a 64-bit quantity doesn't really have low-order bits if it's not
> numeric. Do you mean "rightmost"? Also, what are the other bits.

Really good point. I’ll fix.

> 
> 
> S 5.4.
>>        'Nonce' field.
>> 
>>     Record TTL:  This is the time in minutes the recipient of the Map-
>>        Reply will store the mapping.  If the TTL is 0, the entry MUST be
>>        removed from the cache immediately.  If the value is 0xffffffff,
>>        the recipient can decide locally how long to store the mapping.
> 
> Am I supposed to merge this with previous mappings? REmove them?

No replace it. There is text that says this that is not in the packet format description section.

> S 8.3.
>>     of the mapping database protocols.
>> 
>>  8.3.  Map-Server Processing
>> 
>>     Once a Map-Server has EID-Prefixes registered by its client ETRs, it
>>     can accept and process Map-Requests for them.
> 
> This section is confusing because the introduction says that this
> function is only performed by Map-Resolvers:
> '
> "The LISP Mapping Service defines two new types of LISP-speaking
>   devices: the Map-Resolver, which accepts Map-Requests from an
> Ingress
>   Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
>   mapping database; and the Map-Server, which learns authoritative
> EID-
>   to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
>   them in a database.”

The document does cover the operation of a Map-Resolver and a Map-Server. Some functions are performed only by Map-Resolvers only and other different functions are performed by Map-Servers only.

I am not sure what you don’t understand.

Thanks,
Dino