Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-25

Ballot deferred by Eric Rescorla on 2018-09-11.

Summary: Has 2 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.

Benjamin Kaduk Discuss

Discuss (2019-02-07 for -24)
This document has normative dependencies on other WG drafts that are not
yet mature (one could perhaps define this as having completed IETF LC).  In
particular, I believe there is a nontrivial chance that either or both of
lisp-sec and 6834bis could require changes to this document in order to be
fit for purpose, and thus that this document cannot safely be approved for
publication until these normative dependencies are closer to publication.
In particular, I have done a fairly full review of lisp-sec and have
DISCUSS-worthy points with it (I have not done much review of 6834bis yet).

This document includes a mechansism to use HMAC keyed by a pre-shared key
to authenticate messages (Map-Register and Map-Notify*); it is directly
using the long-term PSK as the HMAC key.  This is not really consistent
with current IETF best practices (e.g,. BCP 107), which tend to not use the
long-term key directly for keying messages, but rather to incorporate some
form of key derivation step, to protect the long-term key from
cryptanalysis and reduce the need to track long-term per-key data usage
limits.  It is probably not feasible to directly require all LISP
implementations to switch keying strategy, but it seems quite advisable to
define new algorithm ID types that include a key derivation step before the
HMAC, and to begin efforts to convert the ecosystem to the more sustainable
cryptographic usage.  I would like to discuss what actions are reasonable
to take at this time, on this front.

As implied by my previous discuss ballot position, I think Section 5.4
should grow a statement (akin to the one added in Section 5.6) that the
"Record" format is also used in the "Map-Reply Record" field of the
Map-Request message, and that the field definitions are reused wholesale
for the Map-Register message.

In Section 5.6, this text seems internally inconsistent:

      can continue using an incrementing nonce.  If the the ETR cannot
      support saving the nonce, then when it restarts it MUST use a new
      authentication key to register to the mapping system.  A Map-
      Server MUST track and save in persistent storage the last nonce
      received for each ETR xTR-ID that registers to it.  If a Map-
      Register is received with a nonce value that is not greater than
      the saved nonce, it drops the Map-Register message and logs the
      fact a replay attack could have occurred.

In order for a new key to be useful as stated, the Map-Server must do the
nonce tracking per <xTR-ID, key> pair and not just per xTR-ID.

Also, guidance is needed on what scope of uniqueness is needed for the Key
ID to function properly -- unique per Map-Server?  Per <Map-Server,xTR>
pair?  Per LISP domain?

Also in Section 5.6:

                                             Implementations of this
      specification MUST include support for either HMAC-SHA-1-96
      [RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is
      RECOMMENDED.

I don't think this sort of "mandatory to choose" is BCP 201-compliant.

I think there needs to be more description of Site-ID usage and scoping in
order to be fully interoperable (more in the COMMENT section).

There are multiple places where we talk about message contents being copied
from a corresponding request (e.g., from Map-Request to Map-Notify); we
need to explicitly state that the authentication data is recomputed to
match, e.g., the new message type.  I've tried to note these occurrences in
the COMMENT section.

The condition for Map-Notify-Ack terminating Map-Notify retransmission
seems incomplete (more in the COMMENT).

In Section 8.2:

                           A Map-Register message includes
   authentication data, so prior to sending a Map-Register message, the
   ETR and Map-Server SHOULD be configured with a shared secret or other
   relevant authentication information.  [...]

We require authentication for Map-Register and do not provide any
alternative mechanism for key distribution, so why is this only a SHOULD?

                                                        As developers
   and operators gain experience with the mapping system, additional,
   stronger security measures may be added to the registration process.

This text does not add confidence to the "proposed standard" label.

In Section 9:

   A complete LISP threat analysis can be found in [RFC7835].  In what

As I have stated previously, the threat analysis in RFC 7835 is not
complete and it should not be referred to as such.

   3.  LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented.  Network
       operartors should carefully weight how the LISP-SEC threat model
       applies to their particular use case or deployment.  If they
       decide to ignore a particular recommendation, they should make
       sure the risk associated with the corresponding threats is well
       understood.

I'm concerned enough about the risk of having a "ITR requests lisp-sec but
ETR didn't use it" case that causes complete breakage, that I want to talk
about this a bit more.  We currently in this document say that lisp-sec is
mandatory to implement (which presumably covers at least ITRs, ETRs,
Map-Resolvers, and Map-Servers).  LISP-SEC itself says that "and ETR that
supports LISP-SEC MUST set the S bit in its Map-Register messages".  Is it
possible that an ETR might "implement" but then not "support" LISP-SEC?  If
so, then we should consider the possibility that we need an authenticated
signal (from the mapping system to the ITR) that downgrading from lisp-sec
is allowed.  There seem to be several possibilities for how one might
construct such a signal; two that came to mind to me would be (1) to define a
new ACT value for "repeat without lisp-sec" that could be returned as a
negative Map-Response directly from the mapping system wherever the mapping
system is able to discern that the ETR in question does not support
lisp-sec (I don't actually know if this could happen at Map-Resolver or
would need to be delayed until the final Map-Server) and (2) to have an
optional Map-Request field that the ETR is required to copy unchanged to
the Map-Reply; this could then include a message HMAC'd in the ITR-OTK that
indicates lisp-sec non-support and binds to the nonce in the request.
Whether these are workable ideas seems to depend on aspects of the mapping
system to which I cannot speak.

                                                     The LISP-SEC
   protocol defines a mechanism for providing origin authentication,
   integrity, anti-replay, protection, and prevention of 'man-in-the-
   middle' and 'prefix overclaiming' attacks on the Map-Request/Map-
   Reply exchange.  [...]

Does LISP-SEC actually provide any additional anti-replay protection not
present in the base protocol?  I do not remember any such additional
protection.

   A complete LISP threat analysis has been published in [RFC7835].
   Please refer to it for more detailed security related details.

(1) you already said that above, (2) it's still not complete.

Section 11 ("Changes since RFC 6833") is inaccurate (see COMMENT).  I did
not check whether it is complete, but someone needs to do so before final
publication.


The following items were present in my original DISCUSS position and still
have not been resolved.  Note that I copy below the previous ballot text
even for some issues that are described above already in different words.

A 64-bit nonce is used, apparently as a request/response correlator, but
the actual (cryptographic?) properties required from the nonce in the
protocol are not clearly covered.  In some cryptographic contexts a 64-bit
nonce may be too short; I do not believe that this is the case here, but
without a clear picture of what the requirements are it's hard to say for
sure.  
[ed. there was some previous discussion about 24-bit nonces that has been
removed from the text, but the core question of what properties the nonce
is required to provide remains unaddressed in the document text.  There is
also a field called 'Nonce' that is used as a s equence number, the
requirements for which are partially described in the new text.]

The layout of the document is somewhat confusing, in a way that could
arguably lead to noninteroperable implemnetations.  For example, the
section on the Map-Register message format includes descriptions of the
fields in the records and locators therein, and the section on Map-Notify
reuses that portion of the structure, incorporating the field descriptions
by reference.  But the Map-Register section does not indicate that its
descriptions are to apply in both cases, leading to confusing text that
talks about values being set or cases that are not possible for a
Map-Register (i.e., the section nominally being described).  It would be
most clear to have a dedicated subsection for the portion of the
structure(s) that is being reused, which would allow for the per-field
descriptions to clearly indicate in which scope they are defined.  But the
more minimal change of just indicating that the primary definition will be
"dual use" would probably suffice as well.
The Map-Reply record/locator descriptions are reused similarly; I made a
comment on section 5.4 that lists a specific instance, though I believe the
phenomenon is more general.
[ed. this was partially addressed, but the request to examine all data
structure reuse (note that "for example" was used) was not heeded]

Similarly, there are many instances (some noted in my Comment) where a
bidirectional interaction between two xTRs is described, yet the peers are
identified as "ITR" and "ETR".  This is very confusing when the entity
named as "ITR" is described as performing ETR functionality, or vice versa;
pedagogically, it would be much better to use non-role-based names for the
entities while describing these exchanges.
[ed. there was some improvement here; I still note some potential sites for
confusion in the COMMENT]

While I see that there is an entire document dedicated to Map-Versioning
and thus we do not need to fully cover everything here, I think it is
critically important to be clear that there are consistency requirements
attached to map versions, as relating to the stability of membership of
RLOCs in a given record, etc.  (I cannot be very clear hear since I am not
entirely confident of the details of the consistency requirements yet.)

I think we need greater clarity on the 'E' and 'M' bits in the ECM format;
more in the Comment section.
[ed. the reader will need to consult the original ballot's COMMENT section
and not the current one]

Section 8.1 says:
   o  A Negative Map-Reply, with action code of "Natively-Forward", from
      a Map-Server that is authoritative for an EID-Prefix that matches
      the requested EID but that does not have an actively registered,
      more-specific ID-prefix.
This document provides no mechanism to establish that a Map-Server is
authoritative for a given EID-Prefix, so this entire case is
non-actionable.
[ed. I think there may have been some previous discussion on this (e.g.,
that might render it moot) but couldn't find it quickly]

Section 8.2 says:
   An ETR publishes its EID-Prefixes on a Map-Server by sending LISP
   Map-Register messages.  A Map-Register message includes
   authentication data, so prior to sending a Map-Register message, the
   ETR and Map-Server SHOULD be configured with a shared secret or other
   relevant authentication information.
This cannot be a SHOULD if things are to work properly; it has to be MUST.

Section 8.2 also says:
                                                        As developers
   and operators gain experience with the mapping system, additional,
   stronger security measures may be added to the registration process.
This kind of language for forward-looking guidance indicates that the
current security properties are not well-understood by the authors and is
inconsistent with Proposed Standard status.

I think the MUST and SHOULD requirements for implementing cryptographic
primitives are generally swapped; the more-secure ones (e.g.,
HMAC-SHA-256-128) should be MUST, and the legacy algorithms needed for
compatibility with existing deployments would be SHOULD.

Section 9 currently states:
   [a]s noted in Section 8.2, a Map-Server SHOULD verify that all EID-
   Prefixes registered by an ETR match the configuration stored on the
   Map-Server.
I think we need a MUST-level requirement for verifying authorization for a
given EID-Prefix, with one way of satisfying the requirement being checking
configuration, but allowing for other means as well.
Comment (2019-02-07 for -24)
Abstract

   This document describes the Control-Plane and Mapping Service for the
   Locator/ID Separation Protocol (LISP), implemented by two new types
   of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server

This is a -bis document; is "new" really appropriate?  (It also appears in
the Introduction, of course.)

Section 1

   LISP is not intended to address problems of connectivity and scaling
   on behalf of arbitrary communicating parties.  Relevant situations
   are described in the scoping section of the introduction to
   [I-D.ietf-lisp-rfc6830bis].

It looks like we inline that text into this document as Section 1.1, below;
perhaps this paragraph is no longer needed, then?

Section 2

I don't think the  "In may IETF documents...near the beginning of their
document" needs to be included, as the genart reviewer noted.

Section 4

   A Map-Server is a device that publishes EID-Prefixes in a LISP
   mapping database on behalf of a set of ETRs.  When it receives a Map
   Request (typically from an ITR), it consults the mapping database to

nit: isn't it typically from a Map-Resolver (or other
mapping-system-internal entity)?  It's originally from an ITR, of course,
but the flow assumed by this document is described as
ITR->Map-Resolver->mapping-system-internals->Map-Server->ETR.

   Note that while it is conceivable that a Map-Resolver could cache
   responses to improve performance, issues surrounding cache management
   will need to be resolved so that doing so will be reliable and

nit: s/will/would/?

   practical.  As initially deployed, Map-Resolvers will operate only in
   a non-caching mode, decapsulating and forwarding Encapsulated Map
   Requests received from ITRs.  Any specification of caching
   functionality is out of scope for this document.

I think it's better to say something like "In this specification," rather
than "As initially deployed".

Also, I've confused myself a couple times from this -- it's only the
Map-Resolver that doesn't cache; the ITR is free to cache.  It might be
helpful to call out that distinction here.

Section 5

I still think it's needlessly confusing to duplicate the IP/UDP header
layout figure here, at least without a prefacing comment noting that this
is the standard IP+UDP header with the IP addresses replaced by RLOCs.
But this is a non-blocking comment and the authors have already replied, so
feel free to ignore.

   Implementations MUST be prepared to accept packets when either the
   source port or destination UDP port is set to 4342 due to NATs
   changing port number values.

It's not entirely clear to me what this requirement is saying.

Section 5.2

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.  It is set to 1 when an ITR wants the
      destination site to return the Map-Reply rather than the mapping
      database system returning a Map-Reply.

Given that we've already disclaimed caching in the mapping system, aren't
all responses supposed to come from the destination site rather than the
mapping system?  Searching the rest of the document for the string
"authoritative" suggests that this is perhaps intended to avoid proxying
behavior from terminating Map-Servers (but when an ETR requests proxying is
it still guaranteed to be able to generate its own Map-Replys?), in which
case this could probably be phrased better.

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

Why are these only SHOULD?

I still think it is needlessly confusing to have bit labels that differ
only by letter case.  While this may not be confusing for the authors,
there are plenty of other people who could potentially be confused by it.
(Also, why are there two bits 'R' next to a 'Rsvd' field that all have the
same "reserved" semantics?)

   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.

At this point in the document, we haven't seen anything to suggest that an
xTR is going to be sending Map-Requests to other xTRs in the same site; a
forward reference is probably in order.

   D: This is the dont-map-reply bit.  It is used in the SMR procedure
      described in Section 6.1.  When an xTR sends an SMR Map-Request
      message, it doesn't need a Map-Reply returned.  When this bit is
      set, the receiver of the Map-Request does not return a Map-Reply.

nit: I'd suggest consolidating the behavior description and leaving the
explanations all at the end, so "This is the dont-map-reply bit.  When this
bit is set, the receiver of the Map-Request does not return a Map-Reply.
It is used in the SMR procedure described in Section 6.1; when an xTR
sends an SMR Map-Request message, it doesn't need a Map-Reply returned."

      Support for processing multiple EIDs in a single Map-Request
      message will be specified in a future version of the protocol.

I would suggest not using the assertive future tense here, as we cannot
really bind our future actions to guarantee its truth.  Wordings like "may
be specified" or "is left for a future version" are alternative options.

   EID mask-len:  This is the mask length for the EID-Prefix.

In bits, right? ...

   EID-Prefix:  This prefix address length is 4 octets for an IPv4
      address family and 16 octets for an IPv6 address family when the

... then maybe we shouldn't switch to bytes for just one sentence (and go
back to bits later in the paragraph)?

      entry, the EID-Prefix is set to the destination IP address of the
      data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4
      or IPv6, respectively.  When an xTR wants to query a site about

Is this really an xTR-specific action, or does it apply to any ITR
functionality?

            This allows the ETR that will receive this Map-Request to
      cache the data if it chooses to do so.

OTOH, this one does seem to require an xTR.

Section 5.3

                           For the initial case, the destination IP
   address used for the Map-Request is the data packet's destination
   address (i.e., the destination EID) that had a mapping cache lookup
   failure.  [...]

This seems like a type mismatch between RLOC/EID -- per the headers, the
destination address should be an RLOC, but we are forced to use an EID in
this case.  The disparity should probably be called out and explained,
e.g., clarify that it's okay to use an EID as destination inside ECM
encapsulation (and, apparently, if we believe Section 5.8, that it's
required to do so).

                                        A successful Map-Reply, which is
   one that has a nonce that matches an outstanding Map-Request nonce,
   will update the cached set of RLOCs associated with the EID-Prefix
   range.

nit: A negative Map-Reply will match the nonce.  Will it also update the
cached set?  Is it still considered to be "successful"?

                                          If the ITR erroneously
   provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
   Request.

I see we talked about this last time around; did you want to add some text
about how, despite the protocol message not definitionally allowing for
this detection, in practice it is still possible?

   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request and it does

So, "(i.e., it is also an ITR)"?

                       If the ETR (when it is an xTR co-located as an
   ITR) has a Map-Cache entry that matches the "piggybacked" EID and the
   RLOC is in the Locator-Set for the entry, then it MAY send the

nit: "cached entry" would help clarify the prerequisites here.

   source.  If the RLOC is not in the Locator-Set, then the ETR MUST
   send the "verifying Map-Request" to the "piggybacked" EID.  [...]

"send ... to the [...] EID" seems like a type mismatch again, since we only
can send Map-Requests to RLOCs.

Section 5.4

      Map-Request.  See RLOC-probing Section 7.1 for more details.  When
      the probe-bit is set to 1 in a Map-Reply message, the A-bit in
      each EID-record included in the message MUST be set to 1.

Do we want to specify any special handling if that NUST is disobeyed?

   S: This is the Security bit.  When set to 1, the following
      authentication information will be appended to the end of the Map-
      Reply.  The details of signing a Map-Reply message can be found in
      [I-D.ietf-lisp-sec].

Please do not use the word "signing" here; it is a term of art that is not
appropriate to the actual operation performed.

   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

I think "can" is more appropriate than "will"; generally a local cache can
safely be invalidated at will.

   Locator Count:  This is the number of Locator entries.  A Locator

Please scope this to "in the given Record".

   EID mask-len:  This is the mask length for the EID-Prefix.

(in bits, right?)

   ACT:  This 3-bit field describes Negative Map-Reply actions.  In any
      other message type, these bits are set to 0 and ignored on
      receipt.  These bits are used only when the 'Locator Count' field
      is set to 0.  The action bits are encoded only in Map-Reply
      messages.  [...]

This is the section on Map-Reply messages; why are we talking about other
message types?  Also, do we want to mention that the possible values are
managed by IANA?

   A: The Authoritative bit, when set to 1, is always set to 1 by an
      ETR.  When a Map-Server is proxy Map-Replying for a LISP site, the
      Authoritative bit is set to 0.  This indicates to requesting ITRs
      that the Map-Reply was not originated by a LISP node managed at
      the site that owns the EID-Prefix.

nit: This text is needlessly confusing.  How about "The authoritative bit
can only be set to 1 by an ETR (and not a Map-Server generating Map-Reply
messages as a proxy).  If this bit is set to 0, that indicates ..."?

Section 5.5

Please provide a link/reference for Data-Probe on first usage.

   For each Map-Reply record, the list of Locators in a Locator-Set MUST
   appear in the same order for each ETR that originates a Map-Reply
   message.  The Locator-Set MUST be sorted in order of ascending IP
   address where an IPv4 locator address is considered numerically 'less
   than' an IPv6 locator address.

IIUC, there is no need for "MUST appear in the same order" if you also
mandate a specific sorting function.

Section 5.6

   P: This is the proxy Map-Reply bit.  When set to 1, an ETR sends a
      Map-Register message requesting the Map-Server to proxy a Map-
      Reply.  [...]

nit: "just one?"

Do you want to give a mnemonic for the 'I' bit?

The "Nonce" field is acting as a sequence number, not just as a number used
once.  I strongly suggest changing the name accordingly.

   Authentication Data Length:  This is the length in octets of the
      'Authentication Data' field that follows this field.  The length
      of the 'Authentication Data' field is dependent on the MAC
      algorithm used.  The length field allows a device that doesn't
      know the MAC algorithm to correctly parse the packet.

Why does a device that won't be able to validate the authentication data
need to be able to parse the packet?  I thought all Map-Registers needed to
be authenticated.

   xTR-ID:  xTR-ID is a 128 bit field at the end of the Map-Register
      message, starting after the final Record in the message.  The xTR-
      ID is used to uniquely identify a xTR.  The same xTR-ID value MUST
      NOT be used in two different xTRs.

Globally, over all time?  Within a single LISP domain, over all time?
Please be specific.

   Site-ID:  Site-ID is a 64 bit field at the end of the Map- Register
      message, following the xTR-ID.  Site-ID is used to uniquely
      identify to which site the xTR that sent the message belongs.

Where is a (LISP) "site" formally defined?  Are there weird topologies or
edge cases that we need to consider when assigning numbers, risk of having
two IDs that might validly apply to a single xTR, etc.?

Section 5.7

(If Nonce is renamed above, it should be renamed here as well.)

   The fields of the Map-Notify are copied from the corresponding Map-
   Register to acknowledge its correct processing.  [...]

Is the authentication data recomputed?

                                      The fields of the Map-Notify-Ack
   are copied from the corresponding Map-Notify message to acknowledge
   its correct processing.

(ditto)

   The Map-Notify-Ack message has the same contents as a Map-Notify
   message.  It is used to acknowledge the receipt of a Map-Notify
   (solicited or unsolicited) and for the sender to stop retransmitting

So a normal exchange would include Map-Register, Map-Notify, and
Map-Notify-Ack?

   A Map-Server sends an unsolicited Map-Notify message (one that is not
   used as an acknowledgment to a Map-Register message) that follows the
   Congestion Control And Relability Guideline sections of [RFC8085].  A

This second clause ("that follows") is rather a non sequitur here.  And we
still don't know what purpose the unsolicited Map-Notify serves!

   Map-Notify is retransmitted until a Map-Notify-Ack is received by the
   Map-Server with the same nonce used in the Map-Notify message.  If a

Presumably we care about (e.g.) the key ID matching and the authentication
data validating, as well?

   Map-Notify-Ack is never received by the Map-Server, it issues a log
   message.  An implementation SHOULD retransmit up to 3 times at 3
   second retransmission intervals, after which time the retransmission
   interval is exponentially backed-off for another 3 retransmission

"exponentially" is not well defined unless the base of the exponent is
specified.

   attempts.  After this time, an xTR can only get the RLOC-set change
   by later querying the mapping system or by RLOC-probing one of the
   RLOCs of the existing cached RLOC-set to get the new RLOC-set.

What RLOC-set change?  This text doesn't seem to indicate what
functionality is going on here.

Section 5.8

   An Encapsulated Control Message (ECM) is used to encapsulate control
   packets sent between xTRs and the mapping database system.

Some of the flag bit descriptions appear to describe usages that are or can
be entirely within the mapping system.

   D:    This is the DDT-bit.  When set to 1, the sender is requesting a
         Map-Referral message to be returned.  The details of this
         procedure are described in [RFC8111].

E.g., here, the sender can be (IIUC) within the mapping system.

   E:    This is the to-ETR bit.  When set to 1, the Map-Server's
         intention is to forward the ECM to an authoritative ETR.

I'm not sure that "intention" is quite right, here -- as far as this
document is concerned, a Map-Server will always know whether it is sending
an ECM to an authoritative ETR.  Also, this bit does not seem to be used
for anything within this document, and no external reference is given.

Are the 'M' and 'E' bits mutally exclusive?  (Would we even care?)

I suggest adding more text about which sender/receiver pairs are permitted
(or allowed or expected) to set the D, E, and M bits.

         invoking Map-Request.  Port number 4341 MUST NOT be assigned to
         either port.  The checksum field MUST be non-zero.

This is the only place in this document that we disallow port 4341.  Should
we also be disallowing it from being used as the non-4342 port for other
exchanges?

   LCM:  The format is one of the control message formats described in
         this section.  [...]

nit: "this section" means 5.8; presumably we mean Section 5.

Section 6.1

I agree with Warren that the direct usage of mapping information included
in an SMR presents a substantial attack surface, both for DoS and
potentially for redirecting traffic wholesale (whether for snooping
purposes or use as volumetric DoS to a third-party target).  There is some
discussion of the risks of spoofing with this sort of "gleaming" behavior,
but I strongly suggest mentioning something like "this technique presents a
risk of off-path spoofing; see Section 9 for details" at each such
non-validated scheme for learning mapping information.

   Since ETRs are not required to keep track of remote ITRs that have
   cached their mappings, they do not know which ITRs need to have their
   mappings updated.  As a result, an ETR will solicit Map-Requests
   (called an SMR message) to those sites to which it has been sending
   LISP encapsulated data packets for the last minute.  In particular,
   an ETR will send an SMR to an ITR to which it has recently sent
   encapsulated data.  This can only occur when both ITR and ETR
   functionality reside in the same router.

I still think that this text is needlessly confusing about which action is
taken by which router, and could be improved as, e.g., "this can only occur
when the ETR also provides ITR functionality (that is, it is an xTR)".

   Both the SMR sender and the Map-Request responder MUST rate-limit
   these messages.  Rate-limiting can be implemented as a global rate-
   limiter or one rate-limiter per SMR destination.

What is the goal of this rate-limiting; how is the threshold determined?

   The following procedure shows how an SMR exchange occurs when a site
   is doing Locator-Set compaction for an EID-to-RLOC mapping:

Where is locator-set compaction defined?

Throughout this whole example, "the site with the changed mapping" and "the
site that sent the Map-Request" are kind of clunky phrases; it might be
cleaner writing to give them names (like "site A" and "site B").

   2.  A remote ITR that receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message or to the mapping database system.  [...]

How does the ITR decide which destination to send the Map-Request to?

       copied from the SMR message.  If the source Locator is the only
       Locator in the cached Locator-Set, the remote ITR SHOULD send a
 
just to double-check: this is the source Locator from the SMR?

       Map-Request to the database mapping system just in case the
       single Locator has changed and may no longer be reachable to
       accept the Map-Request.

Is this the only case that the Map-Request would go to the mapping system?

   3.  The remote ITR MUST rate-limit the Map-Request until it gets a
       Map-Reply while continuing to use the cached mapping.  When

nit: I suggest a comma after "Map-Reply" to avoid the misparse that the
Map-Reply must be received while the cached mapping is in use (and that the
rate limiting would continue indefinitely if the cached mapping expired in
the meantime).

   5.  The ETRs at the site with the changed mapping record the fact
       that the site that sent the Map-Request has received the new
       mapping data in the Map-Cache entry for the remote site so the
       Locator-Status-Bits are reflective of the new mapping for packets
       going to the remote site.  [...]

The Locator-Status-Bits in which direction?  (Probably should also give a
section ref to 6830bis for the definition.)

   For security reasons, an ITR MUST NOT process unsolicited Map-
   Replies.  To avoid Map-Cache entry corruption by a third party, a
   sender of an SMR-based Map-Request MUST be verified.  If an ITR

To be clear, the verification here is essentially return-routability
verification, aka proof that the sender actually owns the claimed address,
right?  I think it is appropriate to have some text noting the specific
behavior, and that this is not any sort of cryptographic or strongly
authenticated verification.

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

What is an "SMR-based Map-Request" (also appears in the next paragraph and
one other place)?  Is it just an SMR?  If it's some actual Map-Request, I'm
confused at why an *I*TR would be receiving it.

Section 7

   3.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts to use
       interworking [RFC6832] and LISP-encapsulated data is sent to a
       non-LISP-capable site.

Is the ITR supposed to conclude that the RLOC is likely down in this
situation?

   When ITRs receive ICMP Network Unreachable or Host Unreachable
   messages as a method to determine unreachability, they will refrain
   from using Locators that are described in Locator lists of Map-
   Replies.  [...]

Is this really as precise as it can be?  It kind of sounds like it says
that all Map-Replies will be ignored when any ICMP Network/Host Unreachable
message is received.

            If it does not find one and BGP is running in the Default-
   Free Zone (DFZ), it can decide to not use the Locator even though the

Is running in the DFZ consistent with the reduced scope of running in a
single administrative domain?

   Optionally, an ITR can send a Map-Request to a Locator, and if a Map-
   Reply is returned, reachability of the Locator has been determined.

Is this describing the same flow as item (5) above and Section 7.1 below?
If so, it seems totally redundant and could be omitted.

   Obviously, sending such probes increases the number of control
   messages originated by Tunnel Routers for active flows, so Locators
   are assumed to be reachable when they are advertised.

I'm not sure what "advertised" is intended to mean, here.  Is it
"advertised into the mapping system"?  But that is not directly visible to
the ITR, only indirectly through the results of an actual mapping request
(and even then, the Map-Reply from an ETR could be invalid, e.g.,
overclaiming, unless LISP-SEC is used.

                               Both Requests and Replies MUST be rate-
   limited.  [...]

I believe this requirement duplicates requirements already made elsewhere;
the other locations also include more guidance on actual rates.

Section 7.1

                                                   A Map-Request used as
   an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to
   the mapping database system as one would when soliciting mapping
   data.  [..]

I strongly suggest using a word other than "soliciting" to avoid confusion
with SMR.

   data.  The EID record encoded in the Map-Request is the EID-Prefix of
   the Map-Cache entry cached by the ITR or PITR.  The ITR MAY include a

Is it worth reminding the reader that the source EID here is zero-length
and source-EID-AFI set to zero?

   mapping data record for its own database mapping information that
   contains the local EID-Prefixes and RLOCs for its site.  [...]

To double-check: this mapping data record is included in the "Map-Reply
Record" field of the Map-Request message?  It would probably help the
reader to be consistent about this terminology.

Section 8.1

                                                  In particular, the ITR
   need not connect to the LISP-ALT infrastructure or implement the BGP
   and GRE protocols that it uses.

Why does LISP-ALT get a callout but not (e.g.) LISP-DDT?

Section 8.3

   In response to a Map-Request (received over the ALT if LISP-ALT is in
   use), the Map-Server first checks to see if the destination EID

I see no reason to mention LISP-ALT here.

                                      If the EID-prefix is registered or
   not registered and there is a authentication failure, then a Drop/

What is the authentication flow that would be failing here?  The
Map-Register for the corresponding prefix?

                                                If either of these
   actions result as a temporary state in policy or authentication then
   a Send-Map-Request action with 1-minute TTL MAY be returned to allow
   the requestor to retry the Map-Request.

How can an SMR have an associated TTL?  The message format is that of a
regular Map-Request, is it not?

Section 8.4

   Upon receipt of an Encapsulated Map-Request, a Map-Resolver
   decapsulates the enclosed message and then searches for the requested
   EID in its local database of mapping entries (statically configured
   or learned from associated ETRs if the Map-Resolver is also a Map-
   Server offering proxy reply service). 

This seems to be the first time the document admits the possibility for a
local database of mapping entries on a Map-Resolver; this makes me wonder
if there was an incomplete removal of such functionality from the document,
especially given that local caching of responses on the Map-Resolver is
explicitly disclaimed in Section 4.

Section 8.4.1

   ETRs MAY have anycast RLOC addresses which are registered as part of
   their RLOC-set to the mapping system.  However, registrations MUST
   use their unique RLOC addresses or distinct authentication keys to
   identify security associations with the Map-Servers.

xTR-IDs cannot be used for this purpose?

Section 9

I think we should have some discussion here about how mapping information
gleamed from SMR messages does not necessarily benefit from the on-path
guarantee that the nonce provides for regular mapping-system exchanges.

   The 2-way LISP control-plane header nonce exchange can be used to
   avoid ITR spoofing attacks, but active on-path attackers (e.g 'man-

Do we really need to limit ourselves to "ITR spoofing" as opposed to
generic spoofing, here?

           The Map-Register message is vulnerable to replay attacks by a
   man-in-the-middle.  A compromised ETR can overclaim the prefix it
   owns and successfully register it on its corresponding Map-Server.
   To mitigate this and as noted in Section 8.2, a Map-Server SHOULD
   verify that all EID-Prefixes registered by an ETR match the
   configuration stored on the Map-Server.

The conversion of the Map-Register 'Nonce' field into a sequence number
provides some moderate remediation against the replay attack; that should
be included in this discussion.

   Encrypting control messages via DTLS [RFC6347] or LISP-crypto
   [RFC8061] SHOULD be used to support privacy to prevent eavesdroping
   and packet tampering for messages exchanged between xTRs, xTRs and
   the mapping system, and nodes that make up the mapping system.

nit: "to support privacy to prevent eavesdropping and packet tampering"
doesn't read as grammatical; is the "to support privacy" still needed?

Section 10

Thank you for adding the Privacy Considerations section; it is imporant to
document this property of the system and let the operator make informed
decisions.

   As noted by [RFC6973] privacy is a complex issue that greatly depends
   on the specific protocol use-case and deployment.  As noted in
   section 1.1 of [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases

Also Section 1.1 of this document.

Section 11

   o  The "m", "I", "L", and "D" bits are added to the Map-Request
      message.  See Section 5.3 for details.

Isn't this more a Section 5.2 thing than 5.3?  Also, I don't see "m" or "I"
bits described (though I do see "M").

   o  The "S", "I", "E", "T", "a", and "m" bits are added to the Map-
      Register message.  See Section 5.6 for details.

I see an "M" bit but not an "m" one.

Section 12.3

It feels a little weird to lump the ACT fields (which have a registry)
together in a section with the flag fields scattered throughout the
protocol (which do not).  Is it bad to have separate subsections for them
(especially when Section 12.6 already exists and does provide a registry
for other flag bits)?

Section 12.6

                        A sub-registry needs to be created per each
   message and record.  [...]

What is a "record" in this context?  (It does not seem like a mapping
record.)

I mostly expect IANA to ask for a listing of which bits/ranges are/aren't
allocatabale.

Mirja Kühlewind Discuss

Discuss (2018-09-11 for -13)
1) Versioning and backward compatibility

Section 5.2 says: "Support for requesting multiple EIDs in a single Map-Request
      message will be specified in a future version of the protocol."
However, there is no versioning mechanism for this protocol specified. How is versioning supposed to work?

Further given there is no new version, I wonder if the changes as outlined in section 10 are all backward-compatible? Especially for the introduction of the Message-Notify-Ack message, I guess there is no problem if a server sends it, however, as the sender of the Message-Notify message might not know if the other end supports sending of the Message-Notify-Ack it can't rely on it. This should be further discussed in the doc! Or is there another strategy to achieve backward compatibility?

2) Size and MTU

As outlined in the TSV-ART review (Thanks Colin!) this document does not discuss fragmentation or Path MTU discovery. RFC8085 recommends to either perform Path MTU discovery or limit the message to 576 bytes for IPv4 or 1280 bytes for IPv6 (minus any static header). As this seems to be an appropriate size for LISP messages, I would recommend this approach. Relying on IP fragmentation (as indicated in the reply to the TSV-ART review) is not recommended by RFC8085 as this would lead to IP packet without a UDP header, in the case of LISP, which can cause problem and loss when NATs are involved. In any case the chosen approach needs to be further discussed in the doc.

3) Rate-limiting and congestion control

Sec 5.3: "Map-Requests MUST be rate-limited.  It is RECOMMENDED that a Map-
   Request for the same EID-Prefix be sent no more than once per second."
As already noted by the TSV-ART review (Thanks Colin!), RFC8085 actually recommends to not send more the one packet per 3 seconds, and that is a restriction for all traffic not on a per-receiver base, or implement congestion control. This limit is meant to not only protect the receiver but also the network from overloading. Why do you use a smaller interval here? Also if (appropriate) rate limiting is used, this should either be a MUST or more explanation when it is okay to use a smaller rate limit should be provided.
However, after all, I don't think you those the right approach here for rate limiting. A Map-Request is always expected to be followed by some reply. For these kind of communication pattern, RFC8085 recommends to limit the number of outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one packet per RTT), also for all traffic and not only per receiver. However, this would also require to implement some simple mechanism to detect a message as lost (see also further below in point 4).

Similarly I'm not sure about the intent of this requirement in section 5.5:
"Map-Replies SHOULD be sent for an EID-Prefix no more often than once
   per second to the same requesting router. "
My understanding is that Replies are only sent when a request is received. Why is this additional rate limit needed? Again if used it should be 3 seconds for all traffic to be inline with RFC8085. Also again, why is that not a MUST? Further recommendation are needed here.

Further section 6.1 say "Both the SMR sender and the Map-Request responder MUST rate-limit
   these messages.  Rate-limiting can be implemented as a global rate-
   limiter or one rate-limiter per SMR destination."
This seems to be the same rate limit as mention above, or not...? It would probably make sense to rate limit the SMR even further. Please clarify and provide more guidance, e.g. what should the value of a potential additional rate limit for SMR be?

Respectively the following sentence in section 6.1 is also unclear:
"The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply"
Why is the rate-limit as currently proposed depend on the fact if a Map-Reply is received? Is the ITR supposed to retransmit the Map-Request...? 

And finally the Map-Register, Map-Notify and Map-Notify-Ack messages does not seem to have any rate-limits. Recommendations inline with RFC8085 should be provided for the total traffic and not only for a few message types. Again, Map-Notify and Map-Notify-Ack messages should be send only once per RTT as there is a feedback mechanism.

For Map-Register sec 8.2 say: "Map-Register messages are sent periodically from an ETR to a Map-
   Server with a suggested interval between messages of one minute."
However, this a rather a low bound than an upper bound. A required (MUST) rate limit is still needed.

4) Loss detection and retransmission

As also mention by the TSV-ART review (Once more thanks to Colin!), this spec has an ACK mechanism for Map-Requests and now also for Map-Notify, however, it does not specify what to do if the ACK is not received (loss detection and retransmission scheduling). This makes the spec incomplete and needs to be further specified in the doc (and also has a relation to the point 3 above of course).
Comment (2018-09-11 for -13)
Further comments:

1) The example given in 5.5 should probably used IPv6 addresses and use the IP address space that is reserved for documentation purposes.

2) I find the security requirements in this doc very unsatisfying. Most important the doc requires the support of authentication mechanism but not the use of it. I would like to see more clear MUST requirements here. Further, today and at this stage of the protocol (moving from exp to PS) I find it not acceptable anymore to have certain security feature as optional and outsourced into a different work-in-process draft. However, I leave further discussion to the SEC ADs.

3) Given the following statement:
"Note that while this document assumes a LISP-ALT database mapping
   infrastructure to illustrate certain aspects of Map-Server and Map-
   Resolver operation..."
it seems that RFC6836 should be a normative reference, as it might not be possible to understand all details explained in this doc with knowing ALT.

4) Further I would also think that I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub should be normative references as the meaning of the respective bits it not further specified in this doc. Or can these bits just be ignored if I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that should be stated.

Clarification questions:
1) Sec 5.3.:
"For the initial case, the destination IP
   address used for the Map-Request is the data packet's destination
   address (i.e., the destination EID) that had a mapping cache lookup
   failure."
Does that mean that the Map-Request needs to use the IPv4 or IPv6 depending on the IP version used by the initial message from the EID. Is that always the case or just for this initial message? I would assume that for all other cases this is actually independent...? Because otherwise there would be a constraint on what needs to be requested. I would like t see further clarification about this in the doc.

2) In section 5.3: "The ITR MAY include all locally
   configured Locators in this list or just provide one locator address
   from each address family it supports."
Would it make sense to include a SHOULD requirement to at least the address family that is used to send the Request is included (to increase chance to enable a communication/get a reply)...?

3) Sec 5.4: "If all Weights for a Locator-Set are equal,
      the receiver of the Map-Reply will decide how to load-split the
      traffic. "
Shouldn't the receiver in this case split the traffic equally? Otherwise how would you signal that the traffic should be split equally? Maybe use all zero instead to let the receiver decide...?

4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which it does not
   have a cached mapping for the EID in the SMR message, it may not send
   an SMR-invoked Map-Request."
I guess this should be normative and probably also a MUST NOT or at least SHOULD NOT.

5) Section 7 seems to imply that if it is detected that no route is available, the ITR should basically do nothing and just drop any incoming packets for that ETR. Would it make sense for incremental deployability, to just forward the packet to the IP address of the EID instead...? This way the source host would not benefit in mobility cases but still gets connectivity otherwise. Or is that anyway not the implication? If that is the case, that should be further clarified in the doc.

6) Section 8.2 says: "Note that the Map-Notify message
   is sent to UDP destination port 4342, not to the source port
   specified in the original Map-Register message."
Actually why is that?

Some minor editorial comments:

1) First sentence in intro: the pointer to ietf-lisp-introduction as currently introduced, makes this reference look very normative:
"The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and [I-D.ietf-lisp-rfc6830bis] specifies..."
I would recommend the following wording:
"The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also [I-D.ietf-lisp-introduction]) specifies..."

2) Also in intro: Given that 6830bis is a normative reference "LISP RFC 6830bis" should be replaced with the new RFC number in the text. This should be noted to the RFC editor; probably this is more obvious if RFCXXX is used instead.

3) Sec 5.4: "...for another way the R-bit MAY be used."
This looks like a lower case may would be more appropriate.

(Eric Rescorla) Discuss

Discuss (2018-09-27 for -16)
This DISCUSS is somewhat arbitratrily on 6833bis, but many
of the same issues apply to 6830bis.

I concur with Ben's DISCUSS. I do not believe that these documents
have adequate security to advance to Proposed Standard.

I thought it might be helpful for me to lay out my starting
assumptions and threat model and what I think the appropriate standard
is here. That gives us an opportunity to discuss them prior to
getting into the specific security issues I raise below.


SYSTEM ARCHITECTURE
Per offline discussion, I understand that despite some of the
introductory material, LISP is not currently intended to be Internet
scale but rather to run in what seem to be fairly tightly controlled
environments. Thus, I am assuming the following facts about
the system:

- The Mapping Service itself is secure and trusted.  For the purposed
  of this discussion, I'm modelling all the entities in the services
  as one trusted element.

- The ETRs have a preconfigured relationship with the Mapping Service,
  which includes some sort of shared key and an ACL on the Mapping
  Service which tells it which EIDs anm ETR can advertise. How
  this gets established is out of scope of this discussion.

Note that neither of these assumptions would be reasonable in
an Internet scale system, but I'm assuming that the text about
that in these documents will be removed.

Because it's not in the document set before us, nor is it a normative
reference, I am disregarding LISP-SEC and only analyzing the system as
specified in these documents.


THREAT MODEL
I'm assuming the usual RFC 3552 threat model, I.e.,

- All non-Map Server elements in the system (specifically, endpoints
  and the xTRs are potentially malicious).
  
- Aside from the links between the Map Server elements, the network
  is controlled by the attacker.

Against this background, my expectation is that the attacker
should not be able to affect traffic in any fashion significantly
more effective than tampering with the data plane. For instance,
it's clearly the case that an on-path attacker between two xTRs
can drop all the packets or forward them to some third xTR, but
it should not be able to send a small number of packets which
would then affect the routing of a large number of packets.

I do not expect that the data plane should have better security
than native (non-IPsec) traffic. Given the nature of LISP and
the existence of a mapping system, it seems like it's kind of
a missed opportunity to deploy a credentials system that would
support IPsec-style data plane security, but given that this
isn't a generally safe assumption for IP traffic, and therefore
you need to provide some sort of transport or application security
anyway, I don't think it's the right standard to hold LISP to.


ATTACKS
LISP appears to be vulnerable to a number of routing attacks that
I claim above it should not be subject to. For example:

1. An on-path attacker can forge Map Replys to the ITR,
   thus redirecting traffic.

2. An ETR can perform an "overclaiming" attack in which it
   claims to be responsible for EIDs which it is not actually
   responsible for.

3. An off-path attacker can temporarily reroute traffic by exploiting
   the "gleaning" feature to cache poison an ITR. In addition, the
   "echo noncing" feature does not appear to have a sufficiently strong
   nonce to protect against forgery, and thus turning this into a
   long-term attack

4. An attacker may be able to perform a number of cache invalidation
   and contamination attacks by exploiting the Map-Version and
   Locator-Status bits. This may lead to DoS.

5. An attacker who was at time T responsible for an EID block
   can probably prolong its ability to respond for that block
   even after it is no longer responsible.
  
6. A number of the components appear to be subject to various replay
   attacks.

I note that many of these attacks are documented in the Security
Considerations for these documents. Also, I doubt this list is
exhaustive. As noted above, I have spent no time on the data plane
protocol.


DEFENSES
When looking at attacks, it's important to determine whether there are
plausible defenses. For most of these, I believe that the answer is
"yes", at varying levels of cost. As noted above, LISP-SEC appears to
be intended to address a number of these issues, so it's possible that
requiring LISP-SEC would go a fair ways towards addressing these
issues. A cursory look at LISP-SEC turns up some somewhat concerning
design choices, so I would have to examine it more closely to give a
real opinion.

I do not believe that LISP-SEC will address the attacks that do not
involve the Mapping Server. For instance, the gleaning
contamination/nonce attacks (3) would not appear to be fixed by
LISP-SEC. However, it's probably possible to fix them by lengthening
the nonce.

With that said, I tend to think that the overall authentication
architecture here would benefit from a rethink. At a high level, the
source of most of these problems is the "non-transferability" of the
mapping information from the Map Server. If the Map Server instead had
an asymmetric key pair which it used to sign mappings, then almost all
of these attacks would not work. Specifically:

- The map server could send signed Map Replys so forgery wouldn't work

- Map Replys from ETRs would be signed, so you couldn't overclaim

- Gleaning attacks would sort of work, but because the probe would
  elicit a Map Reply, you couldn't persist them

- Map Versions could be tied to signed objects, so you couldn't do
  cache invalidation by version. You'd probably need some other
  approach for Locator Status bits.

And so on.

Detailed review below, with some duplication....


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.


S 5.2.
>      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].
>   
>      I: This is the xTR-ID bit.  When this bit is set, what is appended to
>         the Map-Request is a 128-bit xTR router-ID.  See LISP PubSub usage
>         procedures in [I-D.ietf-lisp-pubsub] for details.

here too you seem to be creating a normative reference.


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? Also, when you talk about prefix
length, I assume you mean the length fo the mask?





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.


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


S 8.2.
>      authentication data, so prior to sending a Map-Register message, the
>      ETR and Map-Server SHOULD be configured with a shared secret or other
>      relevant authentication information.  A Map-Server's configuration
>      SHOULD also include a list of the EID-Prefixes for which each ETR is
>      authoritative.  Upon receipt of a Map-Register from an ETR, a Map-
>      Server accepts only EID-Prefixes that are configured for that ETR.

How does it know?
Comment (2018-09-27 for -16)
S 5.
>        \ |           UDP Length          |        UDP Checksum           |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |                                                               |
>          |                         LISP Message                          |
>          |                                                               |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What do these two diagrams correspond to? v4 and v6? This needs
explanation.


S 5.2.
>      Type:   1 (Map-Request)
>   
>      A: This is an authoritative bit, which is set to 0 for UDP-based Map-
>         Requests sent by an ITR.  It is set to 1 when an ITR wants the
>         destination site to return the Map-Reply rather than the mapping
>         database system.

I don't understand this sentence, as literally it would say that you
should not return "the mapping database system" but that doesn't make
any sense.


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.


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.


S 5.2.
>   
>      Nonce:  This is an 8-octet random value created by the sender of the
>         Map-Request.  This nonce will be returned in the Map-Reply.  The
>         security of the LISP mapping protocol critically depends on the
>         strength of the nonce in the Map-Request message.  The nonce
>         SHOULD be generated by a properly seeded pseudo-random (or strong

This seems like it needs to be a MUST.


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.





S 5.4.
>   
>      Nonce:  This is a 24-bit value set in a Data-Probe
>         [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request
>         is echoed in this 'Nonce' field of the Map-Reply.  When a 24-bit
>         value is supplied, it resides in the low-order 64 bits of the
>         'Nonce' field.

Nit: a 64-bit quantity doesn't really have low-order bits if it's not
numeric. Do you mean "rightmost"? Also, what are the other bits.


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?


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

Deborah Brungard (was Discuss, Yes) Yes

Comment (2018-11-30 for -22)
This has been resolved.

Ignas Bagdonas No Objection

Comment (2019-02-07 for -24)
NO OBJECTION for the same reasoning as for 6830bis.

(Ben Campbell) No Objection

Comment (2018-09-27 for -16)
I support the Security ADs DISCUSS positions.

I agree with Alexey that [I-D.ietf-lisp-sec] should be a normative reference. It seems to me that the full security considerations depend upon it.

(I was unfortunately not able to do more than a cursory review due to external time constraints.)

Alissa Cooper No Objection

Comment (2019-02-06 for -24)
I find the SEC ADs' DISCUSS positions concerning and support the resolution of their security concerns.

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2019-02-06 for -24)
I support the DISCUSSES - I was going to say "especially X's", but I support them all...

(Terry Manderson) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2019-02-07 for -24)
Thank you for addressing my DISCUSS.

Alvaro Retana No Objection

Comment (2019-02-04 for -23)
(1) s/rfc8113/draft-ietf-lisp-rfc8113bis

(2) §5.1: "Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126]."  This sentence is out of place because it doesn't specify which procedure...and the action is already specified in rfc8113bis anyway.

(3) s/Not assigned/Unassigned     To match what the registry says.

Adam Roach No Objection

Martin Vigoureux No Objection

Roman Danyliw No Record

Barry Leiba No Record

Éric Vyncke No Record

Magnus Westerlund No Record