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

[Ballot comment]
Thanks for addressing my DISCUSS.

I would suggest the following rewordings:
OLD
Map-Notify messages are only transmitted upon the reception of a Map-
  Register with the M-bit set, Map-Notify messages are not
  retransmitted.  The only exeption to this is for unsolicited Map-
  Notify messages, see below.

NEW
When transmitted in response to a Map-Register with the M-bit set, Map-Notify messages are not
  retransmitted. 

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

NEW
An unsolicited 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.

s/Notifiy/Notify

[Ballot comment]
* The last sentence of the 2nd paragraph of the abstract doesn't seem like a complete sentence to me, somehow.  Perhaps s/it the/it reduces the/?

[Ballot discuss]
Two issues rise to DISCUSS level, IMO:

Sec 5.7. Is the intent that the Map-Notifies are only retransmitted if they are unsolicited? If not, repeated Map-Registers could result in a storm of Map-Notifies.

Thanks for addressing the second DISCUSS.

[Ballot comment]
Thanks for the updates in the -28 and -29; they do resolve all my
Discuss points (and AFAICT the comment ones, too).  Just a handful of
remaining comments (mostly nits, though the last few are more
substantive).

We should probably normalize the spelling of "SHA256" vs "SHA-256" --
there is even one place where we write "HMAC-SHA-256-128+HKDF-SHA256"
with both forms in the same expression.

Abstract

  database designs.  Since these devices implement the "edge" of the
  LISP Control-Plane infrastructure, connecting EID addressable nodes
  of a LISP site, it the implementation and operational complexity of
  the overall cost and effort of deploying LISP.

nit: something seems off starting around "it the implementation".

Section 1.1

  1.  LISP-SEC MUST be implemented [I-D.ietf-lisp-sec].  This means
      that the S-bit MUST be set in the Map-Reply (Section 5.4), Map-
      Register (Section 5.6) and Encapsulated Control messages
      (Section 5.8).

nit: while this is (IMO) unambiguous, s/implemented/in force/ (or
similar) might be a more conventional way to refer to the behavior
presented in the second sentence.

Section 5.3

  "verifying Map-Request" through the mapping database to validate thge
  "piggybacked" mapping data.

nit: s/thge/the/

Section 6.1

It looks like in the process of cleaning up after "SMR-triggered
Map-Requests always go to the mapping system" we also (accidentally?)
removed a sentence about "for security reasons, an ITR MUST NOT process
unsolicited Map-Replies".  IIUC that sentence was here to motivate the
SMR/SMR-invoked-Map-Request processing, and so it no longer makes much
sense in this location, but it does still seem an important point to
make.  I could see this going in either Section 5.5 (defining the
EID-to-RLOC UDP Map-Reply processing) or Section 9 (security
considerations), though of course if you think it makes sense somewhere
else that would be fine, too.

Section 12.5

Please update the 'KDF' reference for HMAC-SHA256-128+HKDF-SHA256 to
point to RFC 5869 (not RFC 4868).

Also, please add a brief note that specifies the interpretation of the
KDF() arguments when the RFC 5869 HKDF is used.  This could be something
like:

% When HKDF [RFC5869] is used as the LISP KDF, the first argument to
% KDF() is used as the HKDF 'IKM', and the second argument to KDF() is used
% as the HKDF 'info'.

(If we were really excited we could rename 's' from being a "salt" to
being a "contextualization string", but I feel like the cost/benefit
analysis does not actually favor making that change.  I merely note it
because what we call a "salt" is different than what RFC5869 uses as
"salt", but there is not a strong requirement for consistency of
terminology across the entire RFC corpus.)

[Ballot comment]
I support Ben Kaduk’s DISCUSS position on the MTI MAC-KDF and LISP-SEC clarity.

Per the issues of the MTI MAC-KDF, I recommend Section 9 (“An implementation MUST support HMAC-SHA256-128+HKDF-SHA256 [RFC4868]”)

I support Martin Duke’s DISCUSS position.

Thanks for addressing my DISCUSS items.

====
** Section 9.  The assumption that “The ETRs have a pre-configured trust relationship with the Mapping System, which includes some form of shared secret … [and] establishment is out of scope of this document.” seems like a significant unaddressed hurdle at scale.

** Section 9.  Per assumption 2 that a “… Mapping System is aware of which EIDs an ETR can advertise.”, what behavior should the mapping system take when it gets a Map-Register whose scope does not match this information?

[Ballot comment]
This is the final document in a long queue, so I did only a cursory review.  Having gone over my colleague's DISCUSS positions and other comments, and the change history since its first pass through the IESG, I doubt I'd be able to add much, so I'm balloting No Objection.

[Ballot comment]
Thank you for the work put into this document.

Due to time contraints, I had no time to do a deep review of this document. But, I support Erik Kline's DISCUSS points and also extend it to 2001:db8:1:2::/32 that is a /64 (cfr section 5.5)

I hope that this helps to improve the document,

Regards,

-éric

[Ballot discuss]
[ __all__ ]

* Is there somewhere a broad prohibition for all IPv6 EID addresses and IPv6
  EID prefixes that they MUST NOT be IPv6 link-local addresses?

  Related: are there any use cases for an IPv6 link-local RLOC?  Perhaps in
  some IXP scenarios?

[ section 5.5 ]

* Are these example prefixes correct?  2001:db8::/16 is really just 2001::/16,
  right? Similarly, I think /24 should be /48 and /32 should be /64, yes?

  I feel like I must be misunderstanding something important...

[Ballot comment]
[ section 5.2 ]

* Can the ITR-RLOC Address be the same as the source of the packet containing
  the Map Request?

[ section 5.4 ]

* I think the EID-Prefix field in the packet layout diagram needs a ... or ~'s
  to indicate variable length? (Same in 5.6, 5.7 and also for Locator field)?

* Can this S bit be cleared by an on-path attacker without consequence?

* ACT values of 4 and 5: should an ICMP admin prohibited be sent back to the
  EID source?

* Weight: "...the 2nd and 3rd Locators will *each* get 25% of the traffic..."

* WRT the recommended once per 3 seconds: is that per-query source or across
  all querying clients?

[Ballot discuss]
(1) The -27 brought back the "MUST" for HMAC-SHA256-128 in Section 5.6 per
my ballot on the -26, but left unchanged section 9, so we still have a
SHOULD vs. MUST inconsistency w.r.t. implementing
HMAC-SHA256-128+HKDF-SHA256.  (I would of course prefer the same
resolution of the inconsistency that Roman does, but have forgotten to
what extent we have to defer to the deployed reality.)

(2) It looks like the update in Section 5.7 is attempting to address my
point about only terminating Map-Notify retransmission when the
authentication data of the Map-Notify-Ack validates, but the added text
is either misplaced or malformed.  Perhaps

CURRENT:
  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 and
  for the sender to stop retransmitting a Map-Notify with the same
  nonce and the authentication data validates.  [...]

NEW:
  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 and,
  once the the authentication data is validated, allows for the
  Map-Notify sender to stop retransmitting a Map-Notify with the same
  nonce. [...]

(3) I think that Eric Rescorla's concern about a misbehaving ETR being
able to prevent an ITR from learning that the ETR is no longer the
appropriate ETR for a given prefix remains unaddressed.  I wrote up a
longer description at
https://mailarchive.ietf.org/arch/msg/lisp/O2ycn4CkWsPhFyqrZuB4ZJBNnl0/
but in short, we only require the ITR to send its Map-Request through
the mapping system (vs. directly to the ETR) when SMR is sent from an
address not in the current mapping data for that prefix -- if the SMR is
sent from an address in the current mapping data, we allow sending
Map-Request directly to the ETR, outside the mapping system.  I don't
see a mechanism that guarantees that such a "revocation" event is
noticed by the ITR.

(4) The specification of the MAC+KDF algorithms doesn't seem detailed
enough to be implementable.  RFC 4868 is attempted to be used as a
reference for both HMAC-SHA256-128 (er, and the one-character-off
HMAC-SHA-256-128) and HKDF-SHA2562 (note spurious final '2'), but I
think it can only work as a reference for the MAC algorithm.  Presumably
we need RFC 5869 or such for the KDF part

(5) This is probably my fault, but we're missing a step with how we
describe the Map-Notify/Map-Notify-Ack per-message authentication.
Specifically, while we do say that the authentication data needs to be
recomputed each time, we don't clearly state that this is because the
correct per-message key is different, because we are using a different
's' input to the KDF function for the different messages.  In line with
the "Map-Register Authentication" used for Map-Register, this would
presumably be "Map-Notify Authentication" and "Map-Notify-Ack
Authentication", but neither of those strings appear in this document.
We might be able to localize the change to Section 5.6, akin to

OLD:
      4:  The derived per-message key is computed as: per-msg-
          key=KDF(nonce+s+PSK[Key ID]).  Where the nonce is the value in
          the Nonce field of the Map-Register and 's' is a string equal
          to "Map-Register Authentication".  [...]

NEW:
      4:  The derived per-message key is computed as: per-msg-
          key=KDF(nonce+s+PSK[Key ID]).  Where the nonce is the value in
          the Nonce field of the Map-Register and 's' is a string that
          corresponds to the message type being authenticated.  For
          Map-Register messages, it is equal to "Map-Register
          Authentication".  Similarly, for Map-Notify and Map-Notify-Ack
          messages, it is "Map-Notify Authentication" and
          "Map-Notify-Ack Authentication", respectively.

However, I think the rhetoric would be more robust if we also modified
Section 5.7 to mention the existence of the different 's' values (or,
rather, the different per-message key) when we say that the
authentication data is recomputed.  Perhaps, s/is recomputed/is
recomputed using the corresponding per-message key/ (twice).

[Ballot comment]
Abstract

  database designs.  Since these devices implement the "edge" of the
  LISP Control-Plane infrastructure, connecting EID addressable nodes
  of a LISP site, their implementation and operational complexity
  reduces the overall cost and effort of deploying LISP.

I think there might be a "simplifying" or "reducing" missing here
(w.r.t. "their implementation and operational complexity").

Section 1

  Conceptually, LISP Map-Servers share some of the same basic
  configuration and maintenance properties as Domain Name System (DNS)
  [RFC1035] servers; likewise, Map-Resolvers are conceptually similar

I suggest adding "authoritative" to the DNS servers of the analogy.

Section 3

  Map-Resolver:  A network infrastructure component that accepts LISP
      Encapsulated (ECM) Map-Requests, typically from an ITR, and
      determines whether or not the destination IP address is part of
      the EID namespace; if it is not, a Negative Map-Reply is returned.
      Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC
      mapping by consulting a mapping database system.

This could perhaps be misread as implying that the Map-Resolver returns
the appropriate EID-to-RLOC mapping to the requestor directly, whereas
IIRC the reply is sent directly from the ETR/Map-Server.

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

I feel like I said this already but forgot the answer; sorry for the
duplication: the Map-Server is not getting the request directly from the
ITR, but rather from the mapping system or a Map-Resolver.  Do we want
to say something like "originating from an ITR" to clarify?

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.

I'm not sure this paints a clear picture of when the bit is/isn't set.
Are Map-Requests sent by an ITR that want the destination site to reply
(rather than the mapping database) sent over some non-UDP-based scheme?
Do ECM messages count as UDP-based?
(I would make this a Discuss for lack of clarity but that would be
double-jeopardy.)

  p: This is the PITR bit.  This bit is set to 1 when a PITR sends a
      Map-Request.

It might be worth saying something about what the recipient would do
with the knowledge that the Map-Request was PITR-generated (rather than
ITR-generated?).

  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.

I'm not sure which RLOC is "the" RLOC -- the message format seems to
allow multiple ITR-RLOC entries.

  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

Should this get s/SMR Map-Request message/SMR message/ as was done
elsewhere in response to my comments on a previous version?

  EID-Prefix:  This prefix address length 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
      address length varies and for the LCAF AFI the format is defined
      in [RFC8060].  [...]

Just to check: if I get a Map-Request that uses an AFI I don't
recognize, I have to abort parsing the packet since I don't know how
many bytes to skip?  It seems like this might negatively affect the
ability to introduce new AFIs.

  Map-Reply Record:  When the M-bit is set, this field is the size of a
      single "Record" in the Map-Reply format.  This Map-Reply record
      contains the EID-to-RLOC mapping entry associated with the Source
      EID.  This allows the ETR that will receive this Map-Request to
      cache the data if it chooses to do so.

We could perhaps mention something about whether the ETR believes the
message is trustworthy, too, since it does not have the benefit of
having gone through mapping system validation.

Section 5.3

  Map-Requests MUST be rate-limited to 1 per second per EID-prefix.
  After 10 retransmits without receiving the corresponding Map-Reply
  must wait 30 seconds.

nit: incomplete sentence.

  a Map-Cache entry.  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 cached entry, then it MAY send the
  "verifying Map-Request" directly to the 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.

side note: Does it make much practical difference to send the
Map-Request to the EID as the destination address vs. just consulting
the mapping system to look up that EID?  It seems like the former is
strictly more work, and I'm not sure what additional benefit is gained
from that additional work.  I guess, reachability information for the
EID in question.

Section 5.4

  P: This is the probe-bit, which indicates that the Map-Reply is in
      response to a Locator reachability probe Map-Request.  The 'Nonce'
      field MUST contain a copy of the nonce value from the original
      Map-Request.  [...]

The description of the nonce field says that it's always copied from the
Map-Request; is this MUST adding any additional requirements?

  Record Count:  This is the number of records in this reply message.
      A record is comprised of that portion of the packet labeled
      'Record' above and occurs the number of times equal to Record
      Count.

We say earlier that the record count in a Map-Request is (artificially)
limited to 1 for this document; we might note here that the reply count
can be larger than the request count, e.g., when there's a need to
return more-specifics that are carved out from the best match to the
requested EID.

  Locator Count:  This is the number of Locator entries in the given
      Record.  A Locator entry comprises what is labeled above as 'Loc'.
      The Locator count can be 0, indicating that there are no Locators
      for the EID-Prefix.

Do we want to say "also known as a negative Map-Reply"?

      (0) No-Action:  The Map-Cache is kept alive, and no packet
          encapsulation occurs.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
          but natively forwarded.

It might be worth a few words about how these two differ, as the "no
encapsulation" part is superficially similar.

  A: The Authoritative bit MAY only be set to 1 by an ETR.  A Map-
      Server generating Map-Reply messages as a proxy MUST NOT set the
      A-bit to 1 by an ETR, and not a Map-Server generating Map-Reply
      messages as a proxy.  This bit indicates to requesting ITRs that

nit: looks like a botched edit, with the "and not a Map-Server
generating Map-Reply messages as a proxy" sticking around when it should
have been removed.

      the Map-Reply was not originated by a LISP node managed at the
      site that owns the EID-Prefix.

Please confirm that the "not" is correct, here.

      12.5% of the traffic.  If all Weights for a Locator-Set are equal,
      the receiver of the Map-Reply will decide how to load-split the
      traffic.  See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a

"equal" or "equal to zero"?  Just "equal" seems like it needlessly
overloads the semantics for uniform balancing.  (Similarly for the
multicast weight.)

  R: This is set when the sender of a Map-Reply has a route to the
      Locator in the Locator data record.  This receiver may find this
      useful to know if the Locator is up but not necessarily reachable
      from the receiver's point of view.  See also EID-Reachability
      Section 7.1 for another way the R-bit may be used.

I'm not finding mention of the R-bit in Section 7.1; am I missing
something?

  The Record format, as defined here, is used both in the Map-Reply and
  Map-Register messages, this includes all the field definitions.

(We also mentioend in the previous section that a single record in this
format can be present in the Map-Request.)

Section 5.5

  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

nit(?): "EID of a record of a Map-Request"?

  invoking the reply.  The source address of the Map-Reply is one of
  the local IP addresses chosen, to allow Unicast Reverse Path

Something seems amiss here.  It might just be that the comma is
misplaced (after chosen vs. before it), but that hinges on the nature of
the choice in question.

Section 5.6

  E: This is the Map-Register EID-notify bit.  This is used by a First-
      Hop-Router (FHR) which discovers a dynamic-EID.  This EID-notify
      based Map-Register is sent by the FHR to the same site xTR that
      propogates the Map-Register to the mapping system.  The site xTR

nit(???): I think maybe s/the same site/a same-site/, though that
nominally changes the meaning.

      4:  The derived per-message key is computed as: per-msg-
          key=KDF(nonce+s+PSK[Key ID]).  Where the nonce is the value in

There's some notational quirks to handle here, since a KDF() function is
typically represented as taking two inputs, an input key material and a
salt, and depending on context an output length as well.  (Though
resolving this may depend on how discuss point (4) is resolved.)

We should probably also say that '+' is used to represent concatenation.

Section 5.7

  procedure defined in the previous section.  For an unsolicited Map-
  Notify, the fields of a Map-Notify used for publish/subscribe are
  specified in [I-D.ietf-lisp-pubsub].

We probably want to tweak how we make this reference to avoid a
perceived need to make pubsub a normative reference.  Perhaps something
like "the Map-Notify message can also used, outside the scope of this
specification, in an unsolicited manner, such as is specified in
[pubsub]".  Also, there are other ways to get an unsolicited Map-Notify,
right?  This text doesn't really make that clear.

  A Map-Server sends an unsolicited Map-Notify message (one that is not
  used as an acknowledgment to a Map-Register message) in only

nit: s/in only/only in/ (my fault, sorry)

  conformance the Congestion Control And Relability Guideline sections
  of [RFC8085].  A Map-Notify is retransmitted until a Map-Notify-Ack

nit: s/conformance/conformance with/

  Upon reception of Map-Register, Map-Notify or Map-Notifiy-Ack, the
  receiver verifies the authentication data.

I suggest adding "If the authentication data fails to validate, the
message is dropped without further processing".

Section 5.8

  LISP: Type 8 is defined to be a "LISP Encapsulated Control Message",
        and what follows is either an IPv4 or IPv6 header as encoded by
        the first 4 bits after the 'Reserved' field.
  [...]
  S:    This is the Security bit.  When set to 1, the field following
        the 'Reserved' field will have the following Authentication
        Data format and follow the procedures from [I-D.ietf-lisp-sec].

So is it the IP version or the authentication data that follows the
Reserved field?

Section 6.1

  mapping data.  Please note that this procedure does not result in
  cryptographic or strongly authenticated verification.

"in the absence of [LISP-SEC]".

  When an ITR receives an SMR-based Map-Request for which it does not

One more s/SMR-based Map-Request/SMR message/, I think (I missed it in
my review of the -26).

Section 7

  4.  An ITR may receive a Map-Reply from an ETR in response to a
      previously sent Map-Request.  The RLOC source of the Map-Reply is
      likely up, since the ETR was able to send the Map-Reply to the
      ITR.

I note that in the analogous text in 6830bis (Section 10), we have a
furthe statement "Please note that in some scenarios the RLOC [from the
outer header] can be an spoofable field."

  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.  However, using this approach is unreliable because many
  network operators turn off generation of ICMP Destination Unreachable
  messages.

I think there is also some level of unreliability in the other direction
-- even when following draft-ietf-opsec-icmp-filtering and validating
the echoed contents, the contents could in some cases be sufficiently
predictable that an attacker could spoof them.  Having random
nonces/ports be in use helps, of course, but the ICMP message could be
generated in response to arbitrary traffic, not all of which will
necessarily have all of those.

  The ITR can test the reachability of the unreachable Locator by
  sending periodic Requests.  Both Requests and Replies MUST be rate-

nit: I think we haven't been using the bare forms of "Requests" and
"Replies" (in favor of the "Map-" prefixed forms).

Section 8.1

  o  A Negative Map-Reply, with action code of "Natively-Forward", from
      a Map-Server that is authoritative (within the LISP deployment
      Section 1.1) for an EID-Prefix that matches the requested EID but
      that does not have an actively registered, more-specific EID-
      prefix.  In this case, the requested EID is said to match a "hole"

Presumably the more-specific prefix still needs to match the requested
EID?

Section 9

  3.  LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented.  Network
      operartors should carefully weight how the LISP-SEC threat model

nit: s/operartors/operators

  The Map-Request/Map-Reply message exchange to inject forged mappings
  directly in the ITR EID-to-RLOC map-cache.  This can lead to traffic

nit: the grammar's a bit off, maybe s/to inject/can inject/?

  attacks.  In this case, attackers can claim to own an EID-prefix that
  is larger than the prefix owned by the ETR.  Such attacks can be

I'd consider adding ", since the Map-Reply is sent directly from ETR to
ITR without a chance for validation by the mapping system".

  addressed by using LISP-SEC [I-D.ietf-lisp-sec].  The LISP-SEC
  protocol defines a mechanism for providing origin authentication,
  integrity, protection, and prevention of 'man-in-the-middle' and

nit: s/integrity,/integrity/ (spurious comma)

  replay attacks by a man-in-the-middle.  However, 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

The "can overclaim" is a little weird since we go on to describe the
mandatory mitigation against this attack.  Maybe something with "could"
or a more drastic rewording to "there is a potential attack where a
compromised ETR could"?

Section 11

[I did not attempt to double-check that the listed changes match the
actual differences between RFC 6833 and this document, but do note that
it looks like the authors did so at some point since my initial review.]

  o  This document is incorporating the codepoint for the Map-Referral
      message from the LISP-DDT specification [RFC8111] to indicate that
      a Map-Server must send the final Map-Referral message when it
      participates in the LISP-DDT mapping system procedures.

It's pretty hard to claim that RFC 8111 is only an informative reference
in light of statements like this that a Map-Server needs to do something
from it when a flag bit defined by this document is set.

Section 12.3

  New ACT values can be allocated through IETF review or IESG approval.
  Four values have already been allocated by [RFC6830], IANA is
  requested to replace the [RFC6830] reference for this registry with
  the RFC number assigned to this document and the [RFC6830].  Action

nit: comma splice.

  values references with the RFC number assigned to this document.

nit: incomplete sentence (lingering remnants of a previous edit that
should just get removed?)

Section 12.4

  The IANA registry "LISP Canonical Address Format (LCAF) Types" is
  used for LCAF types.  The registry for LCAF types use the
  Specification Required policy [RFC8126].  Initial values for the

"Specification Required" includes review by designated experts.  Do we
want to give any guidance to the experts for reviewing new submissions?
(Similarly for other registries; I note that the LISP Bit Flags section
doesn't use the "Specification Required" keyword.)

Section 13.1

We don't currently cite RFC 6347 in a way that requires a normative
reference.  Though I for one wouldn't mind if we made DTLS mandatory
somewhere :)

Section 13.2

We nominally have a "MUST" for behavior from RFC 1071, that would make
it a normative reference, but this is pretty foundational so it seems a
bit like overkill.

[Ballot discuss]
** The applicability statement in Section 1.1. notes that this will be used on the “public Internet”.  Therefore, I think we need to consider the use of “secure defaults”.  Making lisp-sec and a strong MAC-KDF mandatory to implement is helpful.  However, it’s use must also be normatively specified.  Specifically, stronger guidance needs to be given when communicating over the public Internet.  My thinking would be something like:

-- lisp-sec SHOULD (MUST?) be used in for Map-Reply, Map-Notify, Map-Notify-Ack and ECM (i.e. SHOULD/MUST set S=1)

-- Map-Register SHOULD (MUST?) use HMAC-SHA256-128+HKDF-SHA256

-- MUST NOT use Algorithm ID = 0 and 1

[Ballot comment]
I support Ben Kaduk’s DISCUSS position on the MTI MAC-KDF and LISP-SEC clarity.

Per the issues of the MTI MAC-KDF, I recommend Section 9 (“An implementation MUST support HMAC-SHA256-128+HKDF-SHA256 [RFC4868]”)

I support Martin Duke’s DISCUSS position.

** Section 5.3.  Per “After 10 retransmits without receiving the corresponding Map-Reply must wait 30 seconds.”, should this be a normative MUST?

** Section 5.6.  Per “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”, should normative language used here – “… it MUST drop the Map-Register message and SHOULD log the fact that a replay attack …”?

** Section 9.  The assumption that “The ETRs have a pre-configured trust relationship with the Mapping System, which includes some form of shared secret … [and] establishment is out of scope of this document.” seems like a significant unaddressed hurdle at scale.

** Section 9.  Per assumption 2 that a “… Mapping System is aware of which EIDs an ETR can advertise.”, what behavior should the mapping system take when it gets a Map-Register whose scope does not match this information?

** Editorial Nits

-- Section 5.4.  Typo. s/encapsualted/encapsulated/

-- Section 5.6.  Typo. s/the the/the/

-- Section 5.6.  Typo. s/section Section/Section/

-- Section 9.  Typo. s/operartors/operators/

-- Section 9.  Typo. s/eavesdroping/eavesdropping/

[Ballot discuss]
Two issues rise to DISCUSS level, IMO:

Sec 5.7. Is the intent that the Map-Notifies are only retransmitted if they are unsolicited? If not, repeated Map-Registers could result in a storm of Map-Notifies.

Sec 7.1. I very well may have missed something, but it doesn't look like the Map-Request is authenticated. So how can the ETR safely update its Map Cache based on the information in the Map-Reply?

[Ballot comment]
Sec. 5. Please clarify that the 576B and 1280B limits include the entire IP packet.

Sec 5.4. Does the "weight" refer to the percentage of packets or bytes?

Sec 5.5. The first sentence should suggest that the Map Reply could return multiple EID prefixes.

draft-ietf-lisp-6833bis-27.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  This draft is targeting Standard Track publication. It is the proper type of RFC, since is the evolution of RFC 6833, which is experimental and is one of items in the LISP WG charter. The RFC type is indicated in the page header.



(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

The document provides the specifications for the control-plane of LISP  (Locator/Id Separation Protocol).  LISP defines two namespaces, End-point  Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. In this way, LISP effectively separates control from data, and allows routers to create overlay networks.  LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.
  Mappings are distributed using a mapping distribution service. This document defines the front-end of such service, leveraging on the LISP Map-Server and LISP-Map-Resolver elements.


Working Group Summary:

The current LISP WG charter has as main task porting the main LISP specifications on Standard Track. The WG has decided to focus on two main documents, one with the specifications of the data-plane and the other with the specifications of the control-plane. This document concerns the control-plane. The WG has showed support to the document from its first submission as individual draft and adopted it right away. On the technical side there was agreement in the WG and little discussion took place, mainly related include some features/improvements not present in RFC 6833 and adding text that originally was in the LISP data-plane document. On the organisation of the document, more specifically on what to put in the data-plane document and what to put in the control-plane document there has been quite some discussion. The current version is the trade-off the WG  achieved and for which clear consensus has been reached. The version of the document that was approved during WG Last Call is -10. As a shepherd I required a few editorial changes to the document to fix some nits.

Post-Publication Request Summary:

  After requesting publication the document went through IESG review. The document raised several question from the Security and Transport Area ADs.
  In order to solve the issues raised the document went through 16 revisions (publication was requested for revision 11, now is 27).
  All revisions have been also presented in the LISP WG so to be sure that the group was aware of all changes and that there were no objections. No concerns were raised by the LISP WG. All issues seem to be addressed. That is why a new Internet reviews has been performed so to check whether there are concerns from the IETF community.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

There are at least three independent implementations of the LISP control-plane.


Personnel:

Who is the Document Shepherd?

  Luigi Iannone


Who is the Responsible Area Director?

  Deborah Brungard .



(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


I closely followed the document while in the WG and afterwards as a shepherd during IESG review.
The document has improved a lot in quality thanks to the IESG and the authors working together. As previously stated, document changes have been always presented to the LISP WG to make sure that the updated do not raise any concern.  The output of the IDnits tool for the -27 version of the document is provided on point 11. The following issues easily fixable have been found:
  - The draft header indicates that this document obsoletes RFC6833, but the
    abstract doesn't seem to directly say this.  It does mention RFC6833
    though, so this could be OK.
    ==> Actually it obsoletes 6830 and 6833 as correctly written in header+abstract+intro. It appears to be a limitation of the IDnitstool.
  - Missing Reference: 'Key ID' is mentioned on line 1088, but not defined
    => Not actually a reference the IDnits tool is misled by the use of brackets.
  - 3 Unused references: Can be deleted while in the RFC Editor queue.
  - 8 Outdated references, from which 3 are normative but are documents that already past the WG Last Call, hence, the RFC Editor will fix it zith the right RFC numbers.




(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

As the document shepherd I have no concerns.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No broader review is required for this document. It went under a through reviewduring the last year.



(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

I have no specific concerns or issues to point out.



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  All authors have made conforming IPR disclosure.



(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed concerning this specific document. However, there is an IPR disclosure filled by Huawei on RFC 6833, hence, because this document is based on that one, the same IPR disclosure may relate to this document.



(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There has been clear strong consensus behind this document, showing that the WG as a whole understand and agree with it and no objection have been raised during the document review.




(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Nobody did show extreme discontent nor threatened an appeal.



(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

idnits 2.16.04

/tmp/draft-ietf-lisp-rfc6833bis-27.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest one
    being 3 characters in excess of 72.

  -- The draft header indicates that this document obsoletes RFC6833, but the
    abstract doesn't seem to directly say this.  It does mention RFC6833
    though, so this could be OK.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (January 9, 2020) is 175 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'Key ID' is mentioned on line 1088, but not defined

  == Unused Reference: 'I-D.meyer-loc-id-implications' is defined on line
    2165, but no explicit reference was found in the text

  == Unused Reference: 'RFC2104' is defined on line 2178, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC6234' is defined on line 2192, but no explicit
    reference was found in the text

  == Outdated reference: A later version (-06) exists of
    draft-ietf-lisp-6834bis-04

  == Outdated reference: A later version (-32) exists of
    draft-ietf-lisp-rfc6830bis-28

  == Outdated reference: A later version (-20) exists of
    draft-ietf-lisp-sec-19

  == Outdated reference: A later version (-03) exists of
    draft-ietf-lisp-ecdsa-auth-02

  == Outdated reference: A later version (-06) exists of
    draft-ietf-lisp-eid-mobility-05

  == Outdated reference: A later version (-16) exists of
    draft-ietf-lisp-gpe-14

  == Outdated reference: A later version (-07) exists of draft-ietf-lisp-mn-06

  == Outdated reference: A later version (-05) exists of
    draft-ietf-lisp-pubsub-04


    Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

--------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review is required.



(13) Have all references within this document been identified as
either normative or informative?

  Yes.



(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

There are no normative references in unclear state. For clarification, there is a normative reference to draft-ietf-lisp-rfc6830bis, draft-ietf-lisp-rfc6834bis, draft-ietf-lisp-sec, draft-ietf-lisp-rfc8113bis. These documents passed as well WG Last Call. draft-ietf-lisp-rfc6830bis is in IESG hands. draft-ietf-lisp-rfc6834bis and draft-ietf-lisp-sec are waiting for the shepherd writeup, but they have been hold back to make sure that any change due to modifications in  6830bis and 6833bis are included in the documents before submitting them to the IESG.  draft-ietf-lisp-rfc8113bis is already in the RFC Editor queue.
  The RFC Editor will put the right RFC number in all documents.


(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  There are no downward normative references.



(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

This document will obsolete RFC 6833 and RFC 6830, as mentioned in the header, abstract and introduction.



(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  IANA already allocated UDP port number 4342 for the LISP Data-Plane. This document just ask for the following change:

    The IANA registry has allocated UDP port number 4342 for the LISP
    Control-Plane.  IANA has updated the description for UDP port 4342 as
    follows:

          Keyword          Port    Transport Layer  Description
          -------          ----    ---------------  -----------
          lisp-control      4342    udp              LISP Control Packets


    This document ask IANA to the LISP Packet Type Codes by adding the following entry:
        Name                Number          Defined in
        ----                ------          -----------
        LISP Map-Notify-Ack  5              RFC6833bis

    This document ask IANA to create and populate the following registries:
    - LISP Map-Reply EID-Record Action Codes
    - LISP Bit Flags

    This document demands IANA to remove the following registry:
    - LISP Address Type Codes

    This document demands IANA to modify the name of the registry "LISP Key ID Numbers"; to be updated with "LISP Algorithm ID Numbers".


(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

No expert review is required.



(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The document does not contain anything written in a formal
  language, hence, no validation and/or check has been
  performed.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lisp-rfc6833bis-27. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are twelve actions which we must complete.

First, in the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

The existing port number, 4342 is currently allocated the service name of lisp-control for udp only. The current description for the port is "LISP Control Packets" and the assignee is the IESG. IANA assumes that this meets the needs of section 12.1 of the current document.

IANA Question --> should the reference for this port number be changed from RFC6830 to [ RFC-to-be ]?

Second, in the LISP Packet Types registry on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

the reference for the registry will be changed to [ RFC-to-be ]. In addition, any existing registrations in this registry will have their references changed to [ RFC-to-be ].

Third, also in the LISP Packet Types registry on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

a new registration is to be made as follows:

Code: 5
Message: LISP Map-Notify-Ack
Reference: [ RFC-to-be ]

Fourth, in the LISP ACT values registry also on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

the reference for the registry will be changed from:

RFC6830

to

RFC6830, [ RFC-to-be ]

IANA Question --> should the references for the existing four registrations in the registry be changed in the same way?

Fifth, also in the LISP ACT values registry on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

the name of the action for ACT value 3 will be changed from:

"Drop"

to:

"Drop/No-Reason"

Sixth, also in the LISP ACT values registry on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

two new registrations will be made as follows:

Value: 4
Action: Drop/Policy-Denied
Description: A packet matching this Map-Cache entry is dropped because the target EWID is policy-denied by the xTR or the mapping system.
Reference: [ RFC-to-be ]

Value: 5
Action: Drop/Auth-Failure
Description: A packet matching this Map-Cache entry is dropped because the Map-Request for the target EID fails an authentication check by the xTR or the mapping system.
Reference: [ RFC-to-be ]

Seventh, a new registry is to be created called the LISP Canonical Address Format (LCAF) Types registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page such as the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/?

If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is to be managed via Specification Required as defined in RFC8126. There are initial registrations in the new registry as follows:

+-------+------------------------+--------------------------+
| Value | LISP LCAF Type Name | Reference |
+-------+------------------------+--------------------------+
| 0 | Null Body | [ RFC-to-be; Section 3 ] |
| 1 | AFI List | [ RFC-to-be; Section 3 ] |
| 2 | Instance ID | [ RFC-to-be; Section 3 ] |
| 3 | AS Number | [ RFC-to-be; Section 3 ] |
| 4 | Unassigned | |
| 5 | Geo-Coordinates | [ RFC-to-be; Section 3 ] |
| 6 | Unassigned | |
| 7 | NAT-Traversal | [ RFC-to-be; Section 3 ] |
| 8 | Unassigned | |
| 9 | Multicast Info | [ RFC-to-be; Section 3 ] |
| 10 | Explicit Locator Path | [ RFC-to-be; Section 3 ] |
| 11 | Security Key | [ RFC-to-be; Section 3 ] |
| 12 | Source/Dest Key | [ RFC-to-be; Section 3 ] |
| 13 | Replication List Entry | [ RFC-to-be; Section 3 ] |
| 14-255| Unassigned | |
+-------+------------------------+--------------------------+

Eighth, the LISP Address Type Codes registry on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

has no registrations. Section 12.4 of the current document requests that it be deleted.

IANA Question --> Should the registry remain and be marked "obsolete" with a reference that points to [ RFC-to-be ] to capture the history of this registry?

Ninth, the LISP Key ID Numbers registry, also on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

is to be renamed to:

LISP Algorithm ID Numbers

IANA Question --> should the reference for the registry be changed to [ RFC-to-be ]?

Tenth, in the newly renamed LISP Algorithm ID Numbers on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

the registration procedure is to remain First Come, First Served as defined in RFC8126.

IANA understands that the registry is to change to the following:

Name Number MAC KDF
-------------------------------------------------------
None 0 None None
HMAC-SHA-1-96-None 1 [RFC2404] None
HMAC-SHA-256-128-None 2 [RFC4868] None
HMAC-SHA256-128+HKDF-SHA2562 3 [RFC4868] [RFC4868]
Unassigned 4-255

Eleventh, a new registry is to be created called the LISP Control Plane Header Bits registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page such as the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/?

If not, does it belong in an existing category at http://www.iana.org/protocols?

Are there any registrations in this new registry - or are there only registrations in the subregistries of the LISP Control Plane Header Bits registry?

Twelveth, six subregistries of the new LISP Control Plane Header Bits registry are to be created. Each subregistry will have a reference of [ RFC-to-be ] and each registration in the new subregisties will have a reference of [ RFC-to-be ]. All the subregistries will be managed via Specification Required as defined by RFC8126.

The six new subregistries are as follows:

Map-Request Header Bits subregistry [ RFC-to-be; Section 5.2 ]

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+------+---------------+-----------+-----------------------------+
| Spec | IANA Name | Bit | Description |
| Name | | Position | |
+------+---------------+-----------+-----------------------------+
| A | map-request-A | 4 | Authoritative Bit |
| M | map-request-M | 5 | Map Data Present Bit |
| P | map-request-P | 6 | RLOC-Probe Request Bit |
| S | map-request-S | 7 | Solicit Map-Request (SMR) |
| | | | Bit |
| p | map-request-p | 8 | Proxy-ITR Bit |
| s | map-request-s | 9 | Solicit Map-Request Invoked |
| | | | Bit |
| L | map-request-L | 17 | Local xTR Bit |
| D | map-request-D | 18 | Don't Map-Reply Bit |
+------+---------------+-----------+-----------------------------+

Map-Reply Header Bits Subregistry [ RFC-to-be; Section 5.4 ]

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-----------+-------------+--------------+------------------------+
| Spec Name | IANA Name | Bit Position | Description |
+-----------+-------------+--------------+------------------------+
| P | map-reply-P | 4 | RLOC-Probe Bit |
| E | map-reply-E | 5 | Echo Nonce Capable Bit |
| S | map-reply-S | 6 | Security Bit |
+-----------+-------------+--------------+------------------------+

Map-Register Header Bits Subregistry [ RFC-to-be; Section 5.6 ]

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-----------+----------------+--------------+----------------------+
| Spec Name | IANA Name | Bit Position | Description |
+-----------+----------------+--------------+----------------------+
| P | map-register-P | 4 | Proxy Map-Reply Bit |
| S | map-register-S | 5 | LISP-SEC Capable Bit |
| I | map-register-I | 6 | xTR-ID present flag |
+-----------+----------------+--------------+----------------------+

Encapsulated Control Message (ECM) Header Bits Subregistry [ RFC-to-be; Section 5.8 ]

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=8 |S|D|E|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-----------+-----------+--------------+----------------------------+
| Spec Name | IANA Name | Bit Position | Description |
+-----------+-----------+--------------+----------------------------+
| S | ecm-S | 4 | Security Bit |
| D | ecm-D | 5 | LISP-DDT Bit |
| E | ecm-E | 6 | Forward to ETR Bit |
| M | ecm-M | 7 | Destined to Map-Server Bit |
+-----------+-----------+--------------+----------------------------+

EID-Record Header Bits Subregistry [ RFC-to-be; Section 5.4 ]

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Count | EID mask-len | ACT |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-----------+--------------+--------------+-------------------+
| Spec Name | IANA Name | Bit Position | Description |
+-----------+--------------+--------------+-------------------+
| A | eid-record-A | 19 | Authoritative Bit |
+-----------+--------------+--------------+-------------------+

RLOC-Record Header Bits Subregistry [ RFC-to-be; Section 5.4 ]

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused Flags |L|p|R| Loc-AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-----------+---------------+--------------+----------------------+
| Spec Name | IANA Name | Bit Position | Description |
+-----------+---------------+--------------+----------------------+
| L | rloc-record-L | 13 | Local RLOC Bit |
| p | rloc-record-p | 19 | RLOC-Probe Reply Bit |
| R | rloc-record-R | 19 | RLOC Reachable Bit |
+-----------+---------------+--------------+----------------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-06-18):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, lisp-chairs@ietf.org, Luigi Iannone , draft-ietf-lisp-rfc6833bis@ietf.org, lisp@ietf.org, ggx@gigix.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Locator/ID Separation Protocol (LISP) Control-Plane) to Proposed Standard


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'Locator/ID Separation Protocol
(LISP) Control-Plane'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-06-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting. Note, this is a 2nd IETF Last
Call due to technical changes during IESG review.

Abstract


  This document describes the Control-Plane and Mapping Service for the
  Locator/ID Separation Protocol (LISP), implemented by two types of
  LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server --
  that provides a simplified "front end" for one or more Endpoint ID to
  Routing Locator mapping databases.

  By using this Control-Plane service interface and communicating with
  Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
  Egress Tunnel Routers (ETRs) are not dependent on the details of
  mapping database systems, which facilitates modularity with different
  database designs.  Since these devices implement the "edge" of the
  LISP Control-Plane infrastructure, connecting EID addressable nodes
  of a LISP site, their implementation and operational complexity
  reduces the overall cost and effort of deploying LISP.

  This document obsoletes RFC 6830 and RFC 6833.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-lisp-6834bis: Locator/ID Separation Protocol (LISP) Map-Versioning (None - IETF stream)

[Ballot discuss]
It looks like an edit or two that was supposed to be in the -26 didn't make it
by accident, so sorry for the repeat comments; hopefully the writing work in
question will be easy to retrieve.

Other than that we're down to just a few remaining points, two of which
I believe should be trivial to resolve.


In Section 5.6 we say that "implementations of this spsecification SHOULD include
support for HMAC-SHA256-128+HKDF-SHA256 but section 9 says "implementation
MUST support HMAC-SHA256-128+HKDF-SHA256", which is internally inconsistent;
my understanding from a previous discussion with the authors was that
HMAC-SHA256-128+HKDF-SHA256 would be a SHOULD and it was HMAC-SHA256-128
that was MUST.

The condition for Map-Notify-Ack terminating Map-Notify retransmission
seems incomplete.  Specifically, we should only accept the
Map-Notify-Ack to stop retransmission if the authentication data validates
(and maybe that it uses the same Key-ID as the Map-Notify, though that
might be overkill).  So just "a Map-Notify-Ack is received by the
Map-Server with the same nonce" is not quite enough; we'd want to say
"an authenticated Map-Notify-Ack is received by the Map-Server with the same
nonce".

In Section 9:

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

I think this document provides anti-replay protection for the
Map-Request/Map-Reply exchange (by virtue of the single-use nonce), so
we should remove "anti-replay" from the list of features LISP-SEC provides
for the Map-Request/Map-Reply exchange.

I think we need greater clarity on the 'E' and 'M' bits in the ECM format;
are we perhaps defining them now in anticipation of future usage by
other documents (e.g., ones that define specific mapping system implementations)?
in particular (with quotes from my ballot position on the -24 for context):
>  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 think this needs to say more about which message flows this bit is
> defined for.  Presumably the ITR will never use it for sending an
> encapsulated Map-Request to a Map-Resolver, but there seem to be plenty of
> places where ECM wrapping is used.

IIUC, the main ECM-wrapped messages we consider in this document are
ITR-to-Map-Resolver Map-Requests and Map-Server-to-ETR Map-Requests.
Is it an invariant that the ECM 'E' and 'M' bits can never be set at the same time
(as they are only defined to have meaning for the different flows I list)?
In an off-list discussion I got a clarification that "The ETR bit is used so the
Map-Server knows that the entity registering is an xTR versus a SDN or other
type of controller that is registering mappings but doesn’t have a full LISP
protocol engine implementation and can’t send Map-Replies" which sounds like
it applies to a Map-Register ("is registering mappings") but I didn't think that
Map-Register was defined as a possible LCM to be in an ECM.  (Maybe I'm just
confused about that.)

The main thing I still don't understand here is: what entity is going to interpret
the E-bit and change behavior depending on its value?

>
>  M:    This is the to-MS bit.  When set to 1, a Map-Request is being
>        sent to a co-located Map-Resolver and Map-Server where the
>        message can be processed directly by the Map-Server versus the
>        Map-Resolver using the LISP-DDT procedures in [RFC8111].
>
> How does the sender know that its configured Map-Resolver is also a
> Map-Server?  It's unclear to me why this needs a bit in the message as
> opposed to just happening based on the attributes of the receiving
> Map-Server.

It sounds like this is only useful when the ECM contains a Map-Request
from ITR to Map-Resolver, but I don't know how an ITR would know to
(not) set this bit or what entity is going to change behavior depending
on the value of the bit.

[Ballot comment]
[moving from DISCUSS to COMMENT based on explanation of this usage
being a common historical usage in the LISP community.  It still seems
needlessly ambiguous and confusing to me, though, but no response is
required, as we've discussed this already quite a bit and I just want to
stay "on the record" about it.]
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.

[Also moving from DISCUSS to COMMENT]
I'm still a little nervous about the strong dependencies on lisp-sec and
6834bis that are not yet at IESG evaluation, but perhaps they are sufficiently
mature that I don't need to hold a Discuss point anymore to wait for them.

I got a request for more clarification on my previous remark:
% 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]

I think that the "previous discussion" essentially entailed a LISP deployment
including some configuration information about which sites were allowed/expected
to have certain EID prefixes, so the "authoritative" here is just excluding
sites that are known to not be candidates.  That is, the deployment-specific
"authoritative" nature is essentially coming from configuration, if I understand
correctly.  So I didn't think that any further clarification was needed.

A few more other old comments with extra clarification as-needed; I'll
trim most of the comments from the -25.

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

I see this got changed to add "in decimal" as a result to my earlier
comment, but I think my earlier comment was wrong and that change
should be reverted.  It doesn't make sense to measure a prefix length
in bytes, and we have explicit examples of the mask length for when
we need to limit to an exact IP (v4 or v6) address, which would allow
the reader to figure it out anyway.  Sorry for the extra churn (and noting
that the same thing occurs in a later section).

Section 5.6

Do you want to give a mnemonic for the 'I' bit?  I don't propose changing
its name, but if there was some extra word or two that would help someone
remember why it is the 'I' bit (as opposed to, say, the 'Q' bit) that would be helpful.

Section 5.7

  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; is the intent
something like "sends unsolicited Map-Notify messages in only conformance
with the guidelines from RFC 8085"?

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, so maybe tweak the wording to
"between xTRs and the mapping database system or internal to the mapping
database system"?

Section 6.1

  sender of an SMR-based Map-Request MUST be verified.  If an ITR
  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.  [...]

Based on our offline discussion about which messages go in which
direction between ITR and ETR, I think this would be more clear if it
did s/SMR-based Map-Request/SMR message/ (both times).

[Ballot discuss]
Updating for the -25 by removing points that are fully addressed but leaving
points that I still want to have further discussion on.  It may be most expedient to
continue discussion on my -24 ballot thread.  There are a couple of new items to the
-25, that I attempt to call out as such (they appear right before the "the following items
were present in my original DISCUSS position" section).

Please also note that the COMMENT section was entirely refreshed for the -24,
and I make some additions for the -25.

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


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,
since we need to have at least one MTI, strong, algorithm, and this text did not
pick one to be MTI.  Now (-25) we're at "SHOULD include support for
HMAC-SHA256-128-HKDF-SHA256", which is also not quite MTI (but is
definitely strong).  Of course, I personally
won't complain if we just go with the new HKDF stuff, but I recognize that
it would be a big change for implementations and deployments, and don't
think we need to make the spec completely disjoint from reality just to
check a box.  So we could make HMAC-SHA-256-128 MTI and leave the new
one as SHOULD, for example.

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).
[ed. Even focusing on the scoping while leaving the detailed usage as
deployment-specific would be okay]

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.
[ed. I think just from Map-Notify to Map-Notify-Ack is all that's left]

The condition for Map-Notify-Ack terminating Map-Notify retransmission
seems incomplete.  Specifically, we should only accept the
Map-Notify-Ack to stop retransmission if the authentication data validates
(and maybe that it uses the same Key-ID as the Map-Notify, though that
might be overkill).  So just "a Map-Notify-Ack is received by the
Map-Server with the same nonce" is not quite enough.

                                                    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.
[ed. specifically, the nonce mechanism already in this document provides
a decent level of replay protection, so I am trying to nail down how
LISP-SEC does incrementally better than what's already here, for the
specific case of an attacker literally recording a Map-Reply and replaying
it, bit-for-bit, at a later time.

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.
[ed. Waiting to do this until all other changes are in is fine.]


New in the -25, there's an internal inconsistency between Section 5.6's
description of the Authentication Data procedure, that says implementations
"SHOULD include support for HMAC-SHA256-128+HKDF-SHA256", and Section 9's
"[a]n implementation MUST support HMAC-SHA256-128+HKDF-SHA256".

Not new in the -25, but IIRC not previously discussed, how does a
Map-Server pick a Nonce value for unsolicited Map-Notify messages?


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.

I think we need greater clarity on the 'E' and 'M' bits in the ECM format;
more in the Comment section [of the ballot on -16], quoted here for clarity:
>  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 think this needs to say more about which message flows this bit is
> defined for.  Presumably the ITR will never use it for sending an
> encapsulated Map-Request to a Map-Resolver, but there seem to be plenty of
> places where ECM wrapping is used.
>
>  M:    This is the to-MS bit.  When set to 1, a Map-Request is being
>        sent to a co-located Map-Resolver and Map-Server where the
>        message can be processed directly by the Map-Server versus the
>        Map-Resolver using the LISP-DDT procedures in [RFC8111].
>
> How does the sender know that its configured Map-Resolver is also a
> Map-Server?  It's unclear to me why this needs a bit in the message as
> opposed to just happening based on the attributes of the receiving
> Map-Server.

[Ballot comment]
[moving from DISCUSS to COMMENT based on explanation of this usage
being a common historical usage in the LISP community.  It still seems
needlessly ambiguous and confusing to me, though.]
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.


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 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.  Interestingly, in Section 1 we made
an analogy from DNS *caching* resolvers to Map-Resolvers; would an
analogy from DNS *recursive* resolvers have been more apt?

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

  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
      nonce is used as an index to identify the corresponding Map-
      Request when a Map-Reply message is received.  The nonce MUST be
      generated by a properly seeded pseudo-random (or strong random)
      source.  See [RFC4086] for advice on generating security-sensitive
      random data.

Since this value is just serving as a "number used once" (i.e., to match
replies to requests), this is a stronger requirement than we need -- it
merely needs to be unique per ITR.

  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-Ack
  are copied from the corresponding Map-Notify message to acknowledge
  its correct processing.

Please note that the authorization data is recomputed, here.

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

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

  messages.  It is RECOMMENDED that the SMR sender rate-limits Map-
  Request for the same destination RLOC to no more than one packet per
  3 seconds.  It is RECOMMENDED that the SMR responder rate-limits Map-
  Request for the same EID-Prefix to no more than once per 3 seconds.

Please double-check that "SMR sender"/"SMR responder" and "Map-Request"
usage are consistent/as-intended.

  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.)  It might also be appropriate to
discuss the interaction with the relevant map version.

  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

                                      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 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 or maybe
just a missing "and"?
less-nit: this current wording makes it seem like LISP-crypto should be a
normative reference, but I think the intended semantics are more of "some
mechanism SHOULD be used to provide [privacy/confidentiality protection],
and here is an incomplete list of mechanisms that do so"

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.

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

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

[Ballot comment]
(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.

[Ballot discuss]
I have a list of smaller points that should be relatively easy to address. The two main ones:

I believe [I-D.ietf-lisp-sec] needs to be a Normative Reference for this document. This will address
some of the issues raised by Benjamin, but will also make description of various security bits meaningful.

[Ballot comment]
In 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.

This sentence seems to be missing a word at the end, because you don't return "the mapping database system".

11.4.  LISP Address Type Codes

  Therefore, there is no longer a need for the "LISP Address Type
  Codes" registry requested by [RFC6830].  This document requests to
  remove it.

IANA registries are not supposed to be removed, they typically declared closed when not needed.
Can you elaborate of whether this registry was ever used?

[Ballot comment]
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.)

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

[Ballot discuss]
I have a list of smaller points that should be relatively easy to address. The two main ones:

I believe [I-D.ietf-lisp-sec] needs to be a Normative Reference for this document. This will address
some of the issues raised by Benjamin, but will also make description of various security bits meaningful.

Similarly, in Section 5.6:

  I: This is the xTR-ID bit.  When this bit is set, what is appended to
      the Map-Register is a 128-bit xTR router-ID and then a 64-bit
      site-ID.  See LISP NAT-Traversal procedures in
      [I-D.ermagan-lisp-nat-traversal] for details.

This description makes [I-D.ermagan-lisp-nat-traversal] a normative reference.

[Ballot comment]
Abstract

  By using this Control-Plane service interface and communicating with
  Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
  Egress Tunnel Routers (ETRs) are not dependent on the details of
  mapping database systems, which facilitates modularity with different
  database designs.  Since these devices implement the "edge" of the
  LISP Control-Plane infrastructure, connect directly to LISP-capable
  Internet end sites, and comprising the bulk of LISP-speaking devices,
  reducing their implementation and operational complexity should also
  reduce the overall cost and effort of deploying LISP.

The last sentence: I've reread it several times and still not sure what it says.
I suggest rewording, possibly breaking up into shorter sentences.


In Section 5.1 the acronym SMR is used before it is defined (It is defined on the next page).


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

This sentence seems to be missing a word at the end, because you don't return "the mapping database system".

In Section 5.6:

  T: This is the use-TTL for timeout bit.  When set to 1, the xTR wants
      the Map-Server to time out registrations based on the value in the
      "Record TTL" field of this message.

And what happens when it is 0?

11.4.  LISP Address Type Codes

  Therefore, there is no longer a need for the "LISP Address Type
  Codes" registry requested by [RFC6830].  This document requests to
  remove it.

IANA registries are not supposed to be removed, they typically declared closed when not needed.
Can you elaborate of whether this registry was ever used?

[Ballot comment]
As with 6830bis, I unfortunately ran out of time to do more than a cursory review of the LISP documents on this week's telechat. Here too I find the SEC ADs' DISCUSS
positions concerning and support the resolution of their security concerns.

I'm curious why there are several authors listed with an affiliation (Cisco) who no longer have that affiliation AFAIK.

[Ballot discuss]
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?

[Ballot comment]
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."

[Ballot discuss]
See my ballot position on rfc6830bis for some more general notes.
I did most of my review on the -15, though I attempted to note when
the -16 has changed the text.

I am concerned about the handling procedures for Map-Requests that are
encapsulated with the 'S' bit present.  In particular, the ITR is required
to discard non-secure responses, which is necessary in order to avoid a
downgrade attack (in the current architecture).  However, it seems that
ETRs are not required to enable security in their registrations, and
Map-Servers are supposed to strip the security flag when forwarding
Map-Requests to ETRs that do not register as supporting LISP-SEC, and the
resulting Map-Reply messages would thus not be secured, and dropped by the
initiating ITR.  So support for LISP-SEC would need to be mandatory for all
ETRs in order for any ITR to be able to enforce the downgrade-protection
behavior, which is a pretty bad deployment story.  Making LISP-SEC
mandatory everywhere would, of course, avoid this issue.

I do not understand the procedure for allocation of EIDs.  In a global
mapping database, there needs to be some authoritative procedure for
determining what ETRs and/or Map-Servers are authoritative for a given
subset of EID space.  All I've seen so far to do this effectively boils
down to manual configuration, whether explicitly on a Map-Server or just as
a mapping of what keys are authorized to advertise which EIDs.

A 64-bit (or in some cases 24-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.  24 bits, on the other hand, is
quite small.

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.

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.

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

The Map-Register message format field descriptions includes:
  Nonce:  This 8-octet 'Nonce' field is set to 0 in Map-Register
      messages if no Map-Notify message is expected to acknowledge it.
      Since the Map-Register message is authenticated, the 'Nonce' field
      is not currently used for any security function but may be in the
      future as part of an anti-replay solution.
Having the map registrations subject to replay seems like a critical flaw
that would allow an attacker to disrupt any sort of mobility situation,
even in the presence of LISP-SEC.  I cannot see how this protocol could be
suitable for Proposed Standard status with such a susceptibility to replay.

I think we need more details on the expected Map-Register/Map-Notify and
Map-Notify/Map-Notify-Ack message flows.  In what cases is the ack not
needed, and why?

I think we need greater clarity on the 'E' and 'M' bits in the ECM format;
more in the Comment section.

I am concerned that the extensibility mechanism for ECM encapsulation is
insufficiently well specified.  Is a registry needed?  Will new message
types need to Update: this document to indicate the extension?  What
attributes make a message (un)suitable for encapsulation?

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.

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.

Perhaps I am misunderstanding the desired behavior but when Section 8.4
says:
              To do this, it forwards the unencapsulated Map-Request,
  with the original ITR RLOC as the source, to the mapping database
  system.  [...]
doesn't this carry substantial risk of running afoul of BCP 38 filtering?

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.

In the -15, Section 9 also stated:
  The currently defined authentication mechanism for Map-Register
  messages does not provide protection against "replay" attacks by a
  "man-in-the-middle".  Additional work is needed in this area.
I don't understand how this sort of statement can be present in a document
targetting Proposed Standard status, in effect admitting that there are
grave deficiencies in the security posture of the protocol.  The -16 has
gained some language indicating that LISP-SEC mitigates many attacks in
this space, but that is hardly of much use when LISP-SEC is not a mandatory
protocol feature.

I'm disappointed that there is no Privacy Considerations section, though
given that RFC 7835 seems to attempt to disclaim privacy considerations
entirely, perhaps I should not be surprised.  Tying devices to persistent
Endpoint IDentifiers and using them in mobility situations inherently
raises privacy concerns.  These are not necessarily fatal to a protocol,
but they do need to be discussed and the benefits weighed against the
costs.

[Ballot comment]
I apologize for the somewhat scattered nature of these comments; there are
a lot of them and I was focusing my time more on trying to understand the
broader system, and the intended security posture, so they did not get as
much clean-up as I would have liked.

Map-Reply will typically forward a packet that got a negative reply
onto the public internet, adding extra latency to all flows through
a LISP-enabled ITR; is that correct?

Section 1

  Note this document doesn't assume any particular database mapping
  infrastructure to illustrate certain aspects of Map-Server and Map-
  Resolver operation, the Mapping Service interface can (and likely
  will) be used by ITRs and ETRs to access other mapping database
  systems as the LISP infrastructure evolves.

nit: This looks like a comma splice, though I'm not sure I'm parsing everything
correctly.

Section 2

Use the actual boilerplate from RFC 8174; don't just tack on a new
reference to the existing (and without errata fix!) RFC 2119 boilerplate.

Section 3

Should the Map-Register message's definition also mention that the
Map-Server returns the registered RLOCs in normal Map-Replys?

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
  find an ETR that can answer with the set of RLOCs for an EID-Prefix.

My understanding from the intro document, etc., was that the ITR generally
was not sending Map-Requests directly to Map-Servers, and that rather there
was some triangle routing, with the Map-Request going from ITR to
Map-Resolver to Map-Server, and the Map-Reply directly from Map-Server to
ITR (so "typically one initiated by an ITR" or similar).  It's also odd
language (to me) to have the Map-Server "consult the mapping database" when
the Map-Server comprises part of the mapping database and has local
authoritative data.

Section 5

Are we really just duplicating the IPv4+UDP and IPv6+UDP packet headers
here?

Section 5.1

  Values in the "Not Assigned" range can be assigned according to
  procedures in [RFC8126].  Documents that request for a new LISP
  packet type may indicate a preferred value.

8126 has lots of procedures; generally we use a name to indicate which one
is to be followed.

Section 5.2

Using the same letter with different case for different flag bits sounds
confusing.

Lots of potential fun tampering with these flag bits, whether downgrade
attacks on features or otherwise mucking around.

Source EID address in Map-Request has privacy considerations.

If the multiple ITR-RLOC Addresses is soleyl "to give the ETR the option of
selecting the destination address from any address family" then there
should be a restriction to one ITR address per AFI.  (But it's not, so this
text should be tweaked to avoid suggesting that it is.)

When an EID mask-len smaller than the full length of the given address type
is used, what are the values of the bits in the EID-Prefix field that are
"masked away"?  Leaving unspecified bits like this makes for an easy covert
channel, especially so when the protocol messages are not covered by any
integrity protection scheme and subject to on-path tampering.

Section 5.3

  A Map-Request is sent from an ITR when it needs a mapping for an EID,
  wants to test an RLOC for reachability, or wants to refresh a mapping
  before TTL expiration.  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.  For the latter two cases, the destination IP address used
  for the Map-Request is one of the RLOC addresses from the Locator-Set
  of the Map-Cache entry.

I seem to be confused by the "destination IP address" bits here.
Are we really sending Map-Request UDPgrams from an ITR to the EID
destination address that we failed to look up, hoping that some magic in
the network will cause it to end up at an ETR or Map-Server that can reply?
Or is this talking about how we set the EID-Prefix portion of the
Map-Request?  The latter two cases do seem to be using RLOCs in a way
that I expect, which makes me think I'm confused.

Where is the term "Map-Replier" defined?

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

It's unclear how the Map-Replier would detect this, as opposed to just
blindly trying to interpret the start of the request records as an
ITR-RLOC.

  An ITR that is configured with mapping database information (i.e., it
  is also an ETR) MAY optionally include those mappings in a Map-
  Request.  When an ETR configured to accept and verify such
  "piggybacked" mapping data receives such a Map-Request and it does
  not have this mapping in the Map-Cache, it MAY originate a "verifying
  Map-Request", addressed to the map-requesting ITR and the ETR MAY add
  a Map-Cache entry. [...]

This seems like a place where naming the xTRs not by role would help
clarify the flows and the role in which each entity is acting, at each
point.

  [...] If the ETR 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 "verifying Map-Request" directly to the
  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.

It's probably worth disambiguating that "the RLOC" is the cached RLOC for
the EID in the "piggybacked" Map-Reply record.  (Of course, there could be
more than one cached RLOC for a given EID, so "the" is not really right
anyway.)  Similarly, "the Locator-Set" could become "the Locator-Set in the
piggybacked Map-Reply record".  Additionally, and this may just be my
confusion, but is "send ... to the piggybacked EID" the right terminology?
In my mental model at least, "perform a fresh mapping lookup for the EID in
order to send a verifying Map-Request" would be better.

Section 5.4

'S' bit, so clearing that bit and dropping the AD trailer allows an
attacker to modify the contents.  We would perhaps only saved by the bit in
6830bis where if you ask for a secure resolution you have to get one back,
but that's not deployable.

  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.

Just a 6830bis reference isn't quite enough to describe this case, I think;
don't you need to say that the other 40 bits are used by the mapping
implementation?

In the ACT field, is the "No-Action" value ever used for Negative
Map-Replies?  If so, I'm confused what the semantics are supposed to be.

Differentiating between Drop/policy and Drop/authentication may open up
a side channel for an attacker to learn about authentication or policy
information.  (But maybe not; this needs more analysis)

  A: The Authoritative bit, when sent, is always set to 1 by an ETR.

What does "when sent" mean?  The field is part of the structure; it's
always sent.  Or is this supposed to be "has value 1 if and only if the
Map-Reply is sent by an ETR"?

The EID-Prefix entry should probably reuse (or refer to) the text from the
Map-Request field, covering length for other AFIs.
Also, say what goes on for the bits that are "masked out".

I feel like perhaps less could be said about the 'M' priority and weight
fields, as what's currently there just leaves me confused about ETR vs. ITR
vs. xTR and how this information flow is consumed.

  p: When this bit is set, an ETR informs the RLOC-Probing ITR that the
      locator address for which this bit is set is the one being RLOC-
      probed and may be different from the source address of the Map-
      Reply.  An ITR that RLOC-probes a particular Locator MUST use this
      Locator for retrieving the data structure used to store the fact
      that the Locator is reachable.  The p-bit is set for a single
      Locator in the same Locator-Set. If an implementation sets more

Exactly one or at most one?

      than one p-bit erroneously, the receiver of the Map-Reply MUST
      select the first Locator.  The p-bit MUST NOT be set for Locator-

First overall or first that sets the p bit?

      Set records sent in Map-Request and Map-Register messages.

  Locator:  This is an IPv4 or IPv6 address (as encoded by the 'Loc-
      AFI' field) assigned to an ETR.  Note that the destination RLOC
      address MAY be an anycast address.  A source RLOC can be an
      anycast address as well.  The source or destination RLOC MUST NOT
      be the broadcast address (255.255.255.255 or any subnet broadcast
      address known to the router) and MUST NOT be a link-local
      multicast address.  The source RLOC MUST NOT be a multicast
      address.  The destination RLOC SHOULD be a multicast address if it
      is being mapped from a multicast destination EID.

This is the section on the contents of the Map-Reply message.  Why are we
talking about source RLOCs?  Oh, we're going to refer back to this from
other sections for just the "EID-record" portion (a term which is not
properly defined).  It would be good to mention that up front at the start
of this section or the list of fields in the EID-record.

Section 5.5

  A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a
  record count of 3 to be returned with mapping records for EID-
  Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32.  Note
  filling out the /24 with more-specifics that exist in the mapping
  system.

nit: This last sentence is a sentence fragment.

Requiring numerical sort of the locators seems to make the "inserted in
the middle" case very difficult to reason about, especially relating to
synchronization with the data plane and LSBs in data-plane messages.

  [...]  The source address of the Map-Reply is one of
  the local IP addresses chosen to allow Unicast Reverse Path
  Forwarding (uRPF) checks to succeed in the upstream service provider.

nit: should there be a comma before "chosen"?

Section 5.6

Huh, why did I think that Map-Register was always sent encapsulated?

The key-ID description is a great example of how to best describe the
security properties of a field; thanks!

  Authentication Data:  This is the message digest used from the output

"digest" is a term of art and is not appropriate here.  Probably best to
just say "This is the output of the MAC algorithm."

      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.

It's probably good to explictly clarify that "entire payload" means
"from and including the LISP message type field through the end of the last
record and its locators".
Also, the MUST/RECOMMENDED status seems backwards.

I guess referring back to Section 5.4 for the duplicated fields is probably
okay, but I would suggest calling out the portions that are only applicable
or uniquely handled for the Map-Register message.

Section 5.7

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

This is underdefined without specifying the exponent base for the
exponential backoff.

Why is it allowed to Map-Register without requesting a Map-Notify?

Section 5.8

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

Please be explicit about whether all such messages are encapsulated or only
some of them.

  S:    This is the Security bit.  When set to 1, the field following
        the 'Reserved' field will have the following Authentication
        Data format and follow the procedures from [I-D.ietf-lisp-sec].

Could there be some indication of "optional security fields" in the figure?

It's a bit odd to have the 'D' bit in the encapsulation as opposed to
directly in the Map-Request, though I guess it's a bit late to be changing
that.

  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 think this needs to say more about which message flows this bit is
defined for.  Presumably the ITR will never use it for sending an
encapsulated Map-Request to a Map-Resolver, but there seem to be plenty of
places where ECM wrapping is used.

  M:    This is the to-MS bit.  When set to 1, a Map-Request is being
        sent to a co-located Map-Resolver and Map-Server where the
        message can be processed directly by the Map-Server versus the
        Map-Resolver using the LISP-DDT procedures in [RFC8111].

How does the sender know that its configured Map-Resolver is also a
Map-Server?  It's unclear to me why this needs a bit in the message as
opposed to just happening based on the attributes of the receiving
Map-Server.

  LCM:  The format is one of the control message formats described in
        this section.  At this time, only Map-Request messages are
        allowed to be Control-Plane (ECM) encapsulated.  In the future,
        PIM Join/Prune messages [RFC6831] might be allowed.
        Encapsulating other types of LISP control messages is for
        further study.  When Map-Requests are sent for RLOC-Probing
        purposes (i.e., the probe-bit is set), they MUST NOT be sent
        inside Encapsulated Control Messages.

This type of forward-looking language seems unusuabl for a PS document; I
would expect to not see predictions on what might happen, but rather the
specification of what procedure is used to allow new message types.

Section 6.1

  Since the ETRs don't keep track of remote ITRs that have cached their
  mappings, they do not know which ITRs need to have their mappings
  updated. [...]

Nothing *prevents* ETRs from doing this tracking; they're just not required
to do so.  So it would be better to say something like "Since ETRs are not
required to keep track of [...]".

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

Having just come from the section on the "encapsulated control message",
perhaps the reader could use an extra hint that the "encapsulated data" is
just "LISP-tunneled data-plane traffic".  Also, is this intended to be a
normative requirement (with the use of "will")?

  1.  When the database mappings in an ETR change, the ETRs at the site
      begin to send Map-Requests with the SMR bit set for each Locator
      in each Map-Cache entry the ETR caches.

Map-Cache is an ITR function; this is probably another case where naming
the routers would allow for a more clear description of the protocol
exchanges.  Also, this seems in disagreement with the previous text about
sending data in the previous minute, since Map-Cache entries can persist
for longer than a minute.

  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 ETR then stops sending SMR
      messages.

Perhaps a nit, but the "site with the changed mapping" doesn't make sense
-- the map applies to the EID, and in principle the EID could have moved to
a different site.  So this could be "the site sending SMR messages"
perhaps.  Also, I think there needs to be greater clarity about which
Locator-Status bits are being described.  Finally, the cessation of sending
SMR messages is presumably scoped to those targetted to the sender of the
Map-Request in question and not a global property?

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

The only verification possible in this set of documents does not constitute
a security mechanism worthy of the name.
Also, allowing off-path attackers to induce requests to the mapping system
seems like a DoS vector only partially mitgiated by rate limiting.

Section 7

One could perhaps quibble as to whether (1) through (3) constitute
"control-plane", vs. "out-of-band" given that this documents the LISP
Control-Plane as specific UDP messages.

Section 7.1

  When an ETR receives a Map-Request message with the probe-bit set, it
  returns a Map-Reply with the probe-bit set.  The source address of
  the Map-Reply is set according to the procedure described in
  [I-D.ietf-lisp-rfc6830bis].

Please provide a detailed section reference; 6830bis does not specifically
cover source address selection for probes.

  [...] The greatest
  benefit of RLOC-Probing is that it can handle many failure scenarios
  allowing the ITR to determine when the path to a specific Locator is
  reachable or has become unreachable, thus providing a robust
  mechanism for switching to using another Locator from the cached
  Locator.

nit: "greatest benefit ... handle many failure scenarios" is a strange
wording to me.  Presumably the failures are not failures of the probing,
but rather network failures of some form?

Section 8.1

  o  An immediate Negative Map-Reply (with action code of "Natively-
      Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if
      the Map-Resolver can determine that the requested EID does not
      exist. [...]

This seems to be attempting to instill a normative requirement of setting
the 15-minute TTL for this case; please use normative language to that
effect.

      [...] If the
      requested EID matches a more-specific EID-Prefix that has been
      delegated by the Map-Server but for which no ETRs are currently
      registered, a 1-minute TTL is returned.  If the requested EID
      matches a non-delegated part of the authoritative EID-Prefix, then
      it is not a LISP EID and a 15-minute TTL is returned. [...]

(Same comment as above about normative language)

                                        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.

I think there also needs to be some text about the ETR and associated
Map-Server being part of a single administrative domain.

  Failure to implement such a check would leave the mapping system
  vulnerable to trivial EID-Prefix hijacking attacks.  As developers

As described here, this is essentially relying on local configuration for
information about who is authoritative for what EID prefixes, which is
prone to becoming stale and does not scale.

Section 8.3

                                    If there is no match, the Map-
  Server returns a Negative Map-Reply with action code "Natively-
  Forward" and a 15-minute TTL. [...]

In light of my comments in section 8.2, perhaps we can consolidate the
normative requirements to just one location and have a pointer from the
other(s)?

  If the EID-prefix is either registered or not registered to the
  mapping system and there is a policy in the Map-Server to have the
  requestor drop packets for the matching EID-prefix, then a Drop/
  Policy-Denied action is returned.  [...]

In a Map-Server state machine or flow chart, it seems like this policy
application would come before even the above checks for negative responses.
Should the document reflect that ordering as well?

                                      If the EID-prefix is registered or
  not registered and there is a authentication failure, then a Drop/
  Authentication- failure action is returned. [...]

I'm confused what kind of authentication failure is possible here -- there
does not seem to be any end-to-end client authentication of mapping
requests that I have seen in any LISP documents I've read so far.

Section 9

  To publish an authoritative EID-to-RLOC mapping with a Map-Server, an
  ETR includes authentication data that is a hash of the message using
  a pair-wise shared key. [...]

"hash" is a term of art and is not appropriate here; please use "MAC".

  [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin
  authentication, integrity, anti-replay protection, and prevention of
  man-in-the-middle and "overclaiming" attacks on the Map-Request/Map-
  Reply exchange.  Work is ongoing on this and other proposals for
  resolving these open security issues.

It only partially mitigates some of those, and for others relies on the
mapping system to provide some properties that are not clearly achievable.
It is unwise to claim that they are possible absent further clarity on what
behavior mapping systems can currently provide.
[edit: this text changed in the -16]

Section 11.3

  In addition, LISP has a number of flag fields and reserved fields,
  such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis].  New
  bits for flags in these fields can be implemented after IETF review
  or IESG approval, but these need not be managed by IANA.

How will a prospective implementor know that they have found all defined
flags fields?  Are documents allocating new ones supposed to Update: this
one?

Section 11.4

  The IANA registry "LISP Canonical Address Format (LCAF) Types" is
  used for LCAF types, the registry for LCAF types use the
  Specification Required policy [RFC8126]. [...]

nit: comma splice

Section 11.5

I would suggest Expert Review rather than FCFS, for such a scarce codepoint
space with only 256 total values.

[Ballot discuss]
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).

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

[Ballot comment]
There are several issues in §5.1 (LISP Control Packet Type Allocations) that need to be fixed.  I don't think any of them raise up to a DISCUSS, but I would like to see them resolved before publication.

§5.1 "defines the LISP control message formats and summarizes for IANA the LISP Type codes assigned by this document".

(1) Instructions (or anything directed) to IANA should be in the IANA Considerations section.  There isn't even a pointer to this section later on for IANA to look at it.

(2) The text seems to imply ("Message type definitions are") that the types are defined here (or at least in rfc6833, which this document Obsoletes), but they are defined in rfc6830, rfc8111 and rfc8113.  Please properly identify the source (only the rfc8113 line has a reference).

(3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting rfc6830, I think that, because of how the contents of that RFC were distributed, this document should also be tagged as Obsoleting rfc6830.

(4) The LISP Packet Types registry was set up in rfc8113.  This document asks that IANA "refers to this document as well as [RFC8113] as references" (§11.2), and it seems to try to change the registration (or the text is incomplete) in (§5.1): "Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126]."  Which procedure?  s/Not Assigned/Unassigned (§6 in rfc8126)

(5) Because of the point above, this draft should (at least) Update rfc8113 (see also below).

(6) This document says that "Protocol designers experimenting with new message formats SHOULD use the LISP Shared Extension Message Type".  I think this statement makes rfc8113 a Normative reference -- which results in a DownRef.  Suggestion: given that this document already updates the registry set up in rfc8113, and recommends the use of the Shared Extension Message, it may be a good idea to simply adopt the contents of that document here (grand total of 6 pages) and declare it Obsolete.

(7) Type 7 is missing.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lisp-rfc6833bis-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

IANA Question --> IANA understands that this is a bis document and updates and obsoletes RFC6833. In the registries associated with the Locator/ID Separation Protocol there are many registrations that have a reference of RFC6833. The IANA Matrix also has a reference to RFC6833. Should these be changed in any way upon approval of this document? For instance, should the references to RFC6833 be changed to [ RFC-to-be ]?

First, in the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

we will update the following existing registration to refer to the current version of this document:

Service Name: lisp-control
Port Number: 4342
Transport Protocol: udp
Description: LISP Control Packets
Reference: [ RFC-to-be ]

Second, in the LISP Packet Types registry on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

a new packet type will be registered as follows:

Code: 5
Message: LISP Map-Notify-Ack
Reference: [ RFC-to-be ]

Third, in the LISP ACT values registry also on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

The existing registration:

Value: 3
Action: Drop
Description: A packet that matches this map-cache entry is dropped. An ICMP Unreachable message SHOULD be sent.
Reference: [RFC6830]

will be changed to:

Value: 3
Action: Drop/No-Reason
Description: A packet that matches this map-cache entry is dropped. An ICMP Unreachable message SHOULD be sent.
Reference: [RFC6830]

IANA Question --> Should the reference for Value: 3 be changed to [ RFC-to-be ] or have [ RFC-to-be ] added to the existing reference?

Fourth, also in the LISP ACT values registry also on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

two new registrations will be made as follows:

Value Action Description Reference
----- ------ ----------- -------------
4 Drop/ A Packet matching this Map-Cache [ RFC-to-be ]
Policy-Denied entry is dropped because the target
EID is policy-denied by the xTR or
the mapping system.

5 Drop/ A Packet matching this Map-Cache [ RFC-to-be ]
Auth-Failure entry is dropped because the
Map-Request for target EID fails an
authentication check by the xTR or
the mapping system.

Fifth, regarding the LISP Address Type Codes registry also on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

the authors make the following request: "there is no longer a need for the "LISP Address Type Codes" registry requested by [RFC6830]. This document requests to remove it."

IANA Question --> While this registry has no registrations in it and is a candidate for removal, another alternative is to mark it as Obsolete but retain the registry for historic purposes. You can see an example of this by looking at the IANA-IPPM-METRICS-REGISTRY-MIB on the IANA Matrix [ at https://www.iana.org/protocols ]. Should this registry be removed or marked Obsolete?

Sixth, in the LISP Key ID Numbers registry also on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

the name of the registry will be changed from:

LISP Key ID Numbers

to

LISP Algorithm ID Numbers

and the contents of the registry will be modified to become:

Name Number Reference
---------------------------------------------------
None 0 [ RFC-to-be ]
HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-08-31):

From: The IESG
To: IETF-Announce
CC: lisp-chairs@ietf.org, lisp@ietf.org, db3546@att.com, Luigi Iannone , ggx@gigix.net, draft-ietf-lisp-rfc6833bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Locator/ID Separation Protocol (LISP) Control-Plane) to Proposed Standard


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'Locator/ID Separation Protocol
(LISP) Control-Plane'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-08-31. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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
  -- that provides a simplified "front end" for one or more Endpoint ID
  to Routing Locator mapping databases.

  By using this Control-Plane service interface and communicating with
  Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
  Egress Tunnel Routers (ETRs) are not dependent on the details of
  mapping database systems, which facilitates modularity with different
  database designs.  Since these devices implement the "edge" of the
  LISP Control-Plane infrastructure, connect directly to LISP-capable
  Internet end sites, and comprising the bulk of LISP-speaking devices,
  reducing their implementation and operational complexity should also
  reduce the overall cost and effort of deploying LISP.

  This document obsoletes RFC 6833.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-lisp-6834bis: Locator/ID Separation Protocol (LISP) Map-Versioning (None - IETF stream)

draft-ietf-lisp-6833bis-11.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  This draft is targeting Standard Track publication. It is the proper type of RFC, since is the evolution of RFC 6833, which is experimental and is one of items in the LISP WG charter. The RFC type is indicated in the page header.



(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

The document provides the specifications for the control-plane of LISP  (Locator/Id Separation Protocol).  LISP defines two namespaces, End-point  Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. In this way, LISP effectively separates control from data, and allows routers to create overlay networks.  LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.
  Mappings are distributed using a mapping distribution service. This document defines the front-end of such service, leveraging on the LISP Map-Server and LISP-Map-Resolver elements.


Working Group Summary:

The current LISP WG charter has as main task porting the main LISP specifications on Standard Track. The WG has decided to focus on two main documents, one with the specifications of the data-plane and the other with the specifications of the control-plane. This document concerns the control-plane. The WG has showed support to the document from its first submission as individual draft and adopted it right away. On the technical side there was agreement in the WG and little discussion took place, mainly related include some features/improvements not present in RFC 6833 and adding text that originally was in the LISP data-plane document. On the organisation of the document, more specifically on what to put in the data-plane document and what to put in the control-plane document there has been quite some discussion. The current version is the trade-off the WG  achieved and for which clear consensus has been reached. The version of the document that was approved during WG Last Call is -10. As a shepherd I required a few editorial changes to the document to fix some nits.



Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

There are at least three independent implementations of the LISP control-plane.


Personnel:

Who is the Document Shepherd?

  Luigi Iannone


Who is the Responsible Area Director?

  Deborah Brungard .



(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


  I reviewed carefully the document. The text is clear and understandable. I have checked the mailinglist and meeting minutes and publication WG consensus has been reached appropriately. I checked the ID nits and decided to ask the authors to fix them before submitting this writeup. The output of the IDnits tool for the -12 version of the document is provided on point 11. There is still a warning about a weird spacing, but the authors did not manage to get rid of that warning. May be the RFC Editor can help later on.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

As the document shepherd I have no concerns.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No broader review is required for this document.



(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

I have no specific concerns or issues to point out.



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  All authors have made conforming IPR disclosure.



(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed concerning this specific document. However, there is an IPR disclosure filled by Huawei on RFC 6833, hence, because this document is based on that one, the same IPR disclosure may relate to this document.



(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There has been clear strong consensus behind this document, showing that the WG as a whole understand and agree with it.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Nobody did show extreme discontent nor threatened an appeal.



(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

idnits 2.15.01

/tmp/draft-ietf-lisp-rfc6833bis-12.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 9 instances of lines with private range IPv4 addresses in the
    document.  If these are generic example addresses, they should be changed
    to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
    198.51.100.x or 203.0.113.x.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 1656 has weird spacing: '...-Denied  entry...'

  == Line 1661 has weird spacing: '...Failure  entr...'


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

--------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review is required.



(13) Have all references within this document been identified as
either normative or informative?

  Yes.



(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

There are no normative references in unclear state. For clarification, there is a normative reference to draft-ietf-lisp-rfc6830bis and one to draft-ietf-lisp-rfc6834bis, but these documents passed as well WG Last Call. Worst case the RFC editor can hold this document in the queue until there is a RFC number for them.


(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  There are no downward normative references.



(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

This document will obsolete RFC 6833, as mentioned in the header, abstract and introduction.



(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  IANA already allocated UDP port number 4342 for the LISP Data-Plane. This document just state that such allocation exists.

  This document requests IANA to a new codepoint to the LISP Packet Type Registry.

  Name                Number          Defined in
  ----                ------          -----------
  LISP Map-Notify-Ack  5              RFC6833bis


  Furthermore, this document instruct IANA to change the name of ACT type 3 value from "Drop" to "Drop/No-Reason" as well as adding two new ACT values, the "Drop/Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5).

  Value  Action        Description                          Reference
  -----  ------        -----------                          ---------
  4      Drop/          A Packet matching this Map-Cache    RFC6833bis
        Policy-Denied  entry is dropped because the target
                        EID is policy-denied by the xTR or
                        the mapping system.

  5      Drop/          A Packet matching this Map-Cache    RFC6833bis
        Auth-Failure  entry is dropped because the
                        Map-Request for target EID fails an
                        authentication check by the xTR or
                        the mapping system.


(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

No expert review is required.



(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The document does not contain anything written in a formal
  language, hence, no validation and/or check has been
  performed.