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

[Eric Rescorla <[e-mail]>]

On Mon, Oct 1, 2018 at 11:39 AM Dino Farinacci <[e-mail]> 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
>
>
>