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

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

Like any other flag bits that are not assigned, this would be MBZ on 
transmission, must be ignored on reception.  Once assigned, 
implementations that support the assignment would do whatever the 
assigning document says.  Very normal procedure.

Yours,
Joel

On 9/29/18 1:22 PM, Eric Rescorla wrote:
> 
> 
> On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     With regard to the m-bit, I would prefer that this document leave the
>     bit reserved,
> 
> 
> Just trying to think through the interop implications of this. Would it 
> be must be zero and must ignore? something else?
> 
> -Ekr
> 
>     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]>
>      > <mailto:[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]>
>      >     <mailto:[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>
>      >     <http://10.1.0.0/16> and 10.2.0.0/16 <http://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>
>     <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
>      >
>