Here are the changes I put in. And starting to address security. A bunch of LISP co-authors had a conference call last week and awe are preparing text to address security issues you and Ben have raised.
Cheers, Dino
<<< text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html": Unrecognized >>>
> On Oct 9, 2018, at 6:36 AM, Eric Rescorla <[email protected]> wrote: > > > > On Mon, Oct 8, 2018 at 5:41 PM Dino Farinacci <[email protected]> wrote: > Sorry the delay Eric. > > > > > > > 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. > > > > Sorry, cache it? My question is how to respond to the case where the > > Map-Request has this property. > > I thought you were referring to the Map-Reply. If a Map-Request is sent for > 10.0.0.0/8 a replier needs to return in a Map-Reply /8, if it is registered > in the mapping system as well as all more specifics. That is seldom done > since a Map-Request is triggered for a destination EID in an IP packet, but a > “lig” client to ask to see if the coarser prefix exists. > > OK. Thanks. > > > > > > > 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. > > > > I agree, but the text refers to this as the prefix and it has a length, > > which is the length of the encoded field, not the length of the mask, as > > seen in this excerpt: > > > > 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- > > I will make this more clear. Thanks for the comment. Fixed in the section you > cite and make it more clear the different of “address length” and “mask > length” in the “EID-Prefix” definition. > > Sounds good. > > > > > > 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-/. > > > > OK, but then this second excerpt seems contradictory. We have an EID-Prefix > > field which has a different length which is dictated by the AFI only. > > It is not contracdictory. Let me explain, if I have a map-cache entry > 10.0.0.0/8 and I want to query the mapping system, then I send a Map-Request > for 10.0.0.0/8. What comes back in the Map-Reply is the /8 and more specifics > if they are registered. > > The definition section is saying what is in a Map-Request and the other > section that is describing behavior when a Map-Reply is returned. > > OK. I'm going to assume that the changes you note above fixed my confusion > here as well. > > > > > > > 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. > > > > Sure, this seems reasonable, but then perhaps the text above could be > > revised, because it reads like Map Resolvers process these requests and > > therefore implies that Map-Servers do not. > > In the intro we are trying to explain at high-level the service interface. > But since Map-Resolvers forward Map-Requests to Map-Servers, they process > them to. But its through indirection. > > OK, thanks. > > -Ekr > > Dino > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
