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

From: Dino Farinacci <[email-masked]>
Date: Mon, 1 Oct 2018 11:39:18 -0700

> > 
> > 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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Oct 2018 06:38:01 -0700

On Mon, Oct 1, 2018 at 11:39 AM Dino Farinacci <[email-masked]> wrote:

> > 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.
> >

OK.

> 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.

> 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.
>

> The length of the address is defined by the 16-bit AFI that precedes the

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-

> > Well there are many. The nonce can change for each Map-Register sent.
> Same for Map-Version number as well as the key-id.
> >
> 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.

> > 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.

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

Agreed. I'm just saying you should put in a caption on each of them.

> No, I don’t think so. But you have to write more words to let me know what

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

> > 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.
> >

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.

> > 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.
> >
> > 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.
>
> (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.
> 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
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Oct 2018 17:41:39 -0700

Sorry the delay Eric.

> 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.

> 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:
> 

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.

> Agreed. I'm just saying you should put in a caption on each of them.

Done.

> 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.

> 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.

Dino

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 Oct 2018 06:36:28 -0700

On Mon, Oct 8, 2018 at 5:41 PM Dino Farinacci <[email-masked]> wrote:

> 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.

> 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.

> > 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.

> > (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.
> > 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.
> >
> 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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 9 Oct 2018 08:55:32 -0700

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

> On Oct 9, 2018, at 6:36 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> OK. I'm going to assume that the changes you note above fixed my confusion here as well.
> 
> 
> 
> > > > S 8.3.