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

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

This draft explicitly states that the m-bit can be ignored by nodes that 
do not support  the lisp mobile node behavior.  Which seems pretty clear 
that it is nicely separable.

Yours,
Joel

On 9/29/18 1:30 PM, Eric Rescorla wrote:
> 
> 
> On Sat, Sep 29, 2018 at 10:24 AM Joel M. Halpern <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     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.
> 
> 
> OK, I haven't read the -mn- draft so I don't know if that will have a 
> clean upgrade path.
> 
> -Ekr
> 
> 
>     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]>
>      > <mailto:[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]>>
>      >      > <mailto:[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]>>
>      >      >     <mailto:[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>
>      >      >     <http://10.1.0.0/16> and 10.2.0.0/16
>     <http://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>
>      >     <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
>      >      >
>      >
>