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

[Eric Rescorla <[e-mail]>]

On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci <[e-mail]> wrote:

> Thanks Eric for your great comments. Like I said in previous emails, I’ll
> address the simple things here and then handle all the security related
> stuff separately next week.
>
> I will do the same with Benjamin’s comments as well. And in his reply,
> send a diff with changes that reflect both Eric and Benjamin’s comments.
>
> > On Sep 27, 2018, at 5:16 AM, Eric Rescorla <[e-mail]> wrote:
> >
> > Rich version of this review at:
> > https://mozphab-ietf.devsvcdev.mozaws.net/D4115
> >
> >
> > 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.




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


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

I had thought that "prefix length" referred to the former, but it seems
like here it
refers to the latter.


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



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


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

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



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




> >
> > S 5.4.
> >>        'Nonce' field.
> >>
> >>     Record TTL:  This is the time in minutes the recipient of the Map-
> >>        Reply will store the mapping.  If the TTL is 0, the entry MUST be
> >>        removed from the cache immediately.  If the value is 0xffffffff,
> >>        the recipient can decide locally how long to store the mapping.
> >
> > Am I supposed to merge this with previous mappings? REmove them?
>
> No replace it. There is text that says this that is not in the packet
> format description section.
>

OK.


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

-Ekr


> Thanks,
> Dino
>
>