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

["Joel M. Halpern" <[e-mail]>]

With regard to the m-bit, I would prefer that this document leave the 
bit reserved, and the LISP mobile node document assign the bit fromthe 
registry.  That keeps a clean separation.

Yours,
Joel

On 9/29/18 1:05 PM, Eric Rescorla wrote:
> 
> 
> On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci <[e-mail] 
> <mailto:[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]
>     <mailto:[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
>     <http://10.1.0.0/16> and 10.2.0.0/16 <http://10.2.0.0/16>
>      > and someone asks me for 10.0.0.0/8 <http://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
>