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

[Dino Farinacci <[e-mail]>]

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