> > > > 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. > > Me neither. Seems like it could go either way. My only interest is that the > protocol be unambiguous.
We are working through removing normative references to working group drafts. > > > > > 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? > > I think I'm still unclear on this point. The spec says you cache it. That is all you can do. But it means the sender of the Map-Reply is not spec conformant. That means RLOCs are used for the coarser EID-prefix. > > 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?? > > I found it a bit confusing. It seems to me like there are two lengths > involved here: > > - The length of the field (4 or 16) > - The parts of the field that are significant (i.e., the mask) In routing, as you know, the mask-length is always the same as the prefix-length. It is the number of bits in the mask. > I had thought that "prefix length" referred to the former, but it seems like > here it > refers to the latter. The length of the address is defined by the 16-bit AFI that precedes the address. > > 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. > > I think you need to describe the precise process of replay prevention here. Not addressing any security issues right now until we have the conference call. I agree with you and believe we have solutions, we just haven’t documented them clearly. And understand why your line of questioning. > > > 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. > > I'm probably just confused here: SMRs go through the mapping system, not > directly? If so, I agree that this wont' work. SMRs are sent from an xTR that changes its RLOC set to xTRs that might have EID-prefixes cached. It tells those caching xTRs to do a lookup to the mapping system. So the Map-Request, with S-bit set (an SMR) are sent directly from xTR to xTR. > > > 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. > > A caption would probably help. The beginning of the section shows an IPv4 UDP packet format as well as a IPv6 UDP packet format. > > > 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. > > Won't this cause problems on ingress to another site? No, I don’t think so. But you have to write more words to let me know what you are thinking about. > > > 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. > > This does seem to have been assigned to the wrong text. > > I am referring to: > > " 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 > either from the destination field of an IP header of a Data-Probe or > the EID record of a Map-Request. The RLOCs in the Map-Reply are > " > > versus > > " EID-Prefix: This prefix is 4 octets for an IPv4 address family and > 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 > or 2, respectively. For other AFIs [AFI], the length varies and > for the LCAF AFI the format is defined in [RFC8060]. When a Map- > " > > This is just the question of whether "prefix length" refers to the field or > the significant bits of the field. Prefix-length = mask-length = number-of-bits-in-mask = value-after-/. > > 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. > > Sure: As I understand it, Map Resolvers process Map Requests, and Map Servers > do not (that's what the quoted text seems to say). However, this sentence > talks about a Map Server processing a Map Request. That's where I am > confused. Here is a brief scenario: (1) ITR sends Map-Request to a Map-Resolver. (2) Map-Resolver “finds” the Map-Server where the EID could be registered. That is the mapping database transport system, two examples are LISP-ALT and LISP-DDT. (3) The Map-Resolver in the case of LISP-DDT, will have a referral-cache and know which map-server is authoriative for the EID-prefix the Map-Request EID is for. (4) The Map-Resolver forwards the Map-Request to that Map-Server. And hence Map-Servers process Map-Requests. The Map-Server can proxy-reply with the RLOC-set cached in its site-cache or forward to one or more ETRs (described by the RLOC-set) so they can map-reply. Most of the above is described in the LISP-DDT RFC. For LISP-ALT, the map-resovler forwards the Map-Request across a tunneled topology where BGP is used to tell you where EID-prefixes are registered to what Map-Servers. That tunneled toplogy is used for the sole purpose to forward Map-Requests. No data-plane involved there. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
