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 <[email protected]> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
