On Mon, Oct 1, 2018 at 11:39 AM Dino Farinacci <[email protected]> wrote:
> > >
> > > 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.
>
OK.
> > > 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.
>
> > 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-
> > > 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.
>
Sure, Let's pick this up later.
>
> > > 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.
>
Sorry, I misspoke, but i think I get your point. This sounds fine.
> >
> > > 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.
>
Agreed. I'm just saying you should put in a caption on each of them.
> >
> > > 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.
>
I'm not sure I understand well enough, but it just seems like if you have a
bit that says "this is local" that then appears on another network where
it's not local, that might cause problems. But if you say it doesn't, then
OK
>
> > > 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.
> > > 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.
-Ekr
> 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
