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 10:42 AM Joel M. Halpern <[e-mail]>
wrote:

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

OK.

-Ekr


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