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

[Dino Farinacci <[e-mail]>]

Thanks Benjamin for your comments. Both yours and Eric’s were really detailed and right on. Its folks like you that will make the Internet much better. Thanks for that.

As I said with Eric’s comments, I’m fixing the simple things from your comment section. I have attached a diff file for -22 of 6833bis that include changes for Eric’s comments (last email I sent) and comments from this email.

> On Sep 26, 2018, at 9:51 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> ----------------------------------------------------------------------
> 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?

If the packet that arrives at the ITR has a source EID in the source address field and the destination is not an EID (and in this case it it not because the destination address does not match a mapping in the mapping system), then the packet is forwarded natively. And the delay incurred is a map-cache lookup versus a regular FIB lookup from a typical IP forwarding engine. There is an internal latency added yes.

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

I made it 2 sentences.

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

Changed.

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

It says that in the last sentence of the “Map-Register message” definition.

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

Map-Servers get Map-Requests indirectly via the Map-Resolver an the Database Mapping Transport system. And yes, the map-server needs to consult the mapping system beacuse it is a sharded database and it may not have the entries it needs to look up.

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

Yes, we are for a desire to be explicit.

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

Have a suggestion?

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

We want them to be easily remembered and the text is consistent about how we reference them. And I have dealt with them quite easily after doing 2 different LISP implementations.

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

I think less when it is opaque via random address assignment or use of crypto-EIDs (see draft-ietf-lisp-ecdsa-auth for details).

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

There is no need for this restriction. It is not helpful.

> 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

The low-order bits. This is a well-known technique used in routing protocols for decades.

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

The Map-Request has an IP header in front of it. That packet is encapsulated in an ECM message which has another IP header wrapped around it. This is a Map-Request sent to the mapping system.

> Where is the term "Map-Replier" defined?

Can’t you assume it is the sender of a Map-Reply? I don’t tink tha tis a stretch.  ;-)

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

It would be a field with all 0s. A martian IPv4 address perhaps.

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

But in this case, the role is very important. Generalizing it would lose the specification of which side does what.

> 
>   [...] If the ETR has a Map-Cache entry that matches the

I changed this to “If the ETR (when it is an xTR co-located as an ITR) …”

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

Hmm, it is clear to me. There is only one RLOC to verify because each remote xTR may not have to full RLOC-set (example is two xTRs each behind different NATs, where they need to determine their global RLOC address).

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

The LISP-SEC MUST specify the use of DTLS to avoid this attack. And we are going through discussions to ask the WG if it is desirable to make LISP-SEC normative.

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

We removed Data-Probes and this text didn’t get removed. The reference to 24-bits will be removed.

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

No.

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

We thought it would be useful for network management purposes to distinguish the two cases.

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

Changed to “when set to 1”.

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

No, it is completely a different record type. Unless I’m not following your point.

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

It would be no different than “U” priority and weight so not sure why are say this.

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

We are saying it should not set more than 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?

I changed to “first set p-bit locator”.

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

We are referring to RLOCs in a data-packet. I’ll make more clear.

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

Fixed.

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

Added.

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

I have no idea.  ;-)

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

Done. I think Eric made this comment too.

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

Changed.

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

That is explained in sections that are not packet format sections.

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

In routing protocols, it is known as doubling the backoff. How would you want to explain that?

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

It’s an option to have reliability through periodic transmission versus incremental transmission.

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

We do in other sections.

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

That is too much detail to put in here and we have a whole LISP-SEC document to explain that.

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

It is necessary for the Map-Resolver that gets ECM based Map-Request.

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

This is LISP-DDT related and in that document.

>   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

It doesn’t need to know. The ITR can set the bit for efficiency purposes but the MSP (mapping system provider needs to tell them to set the bit).

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

This is being done in RFC6831. Rather than predicting, I’ll make a refrence to it. The prediction came true.  ;-)

Good catch. Another reminder, that we have been working on these specs for way too long.

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

Changed.

> 
>   [...] 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”)?

Change to “LISP encapsulated data packets”.

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

Change to “...in each Map-Cache entry the ETR (when it is an xTR co-located as an ITR) caches….”

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

Changed text to your suggestion.


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

I am deferring answer security questions in this email until we have the conference call.

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

Since we did a shuffle of the control-plane and data-plane documents, I will fix this. Thanks for the comment.

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

Changed “greatest” to “main”. Is that okay?

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

It is. So why is that bothering you? The text is providing an architectural constant.

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

Same response.

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

They usually are not and we shouldn’t imply they are.

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

I am not sure what you think I should change.

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

I would like to keep them where they are introduced.

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

Leaving it up to the implementation.

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

This was added to support draft-ietf-lisp-ecdsa-auth. If a Map-Request is required to be signed by a map-server and doesn’t include a signature, than Drop-Action/Auth-failure is returned. If a Map-Request includes a signature and it verifies false or the public-key cannot be found, than Drop-Action/Auth-failure is returned.

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

Done.

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

Let’s save this for the conference call.

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

They are all documented in 6830bis. And the one reserved bit is used for LISP-GPE. And we are deciding if it should be put in there or kept out. WG mulling this over.

> 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

Fixed.

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

The WG decided on this. The WG needs to discuss this.

Thanks so much for your thorough comments. They are really helpful and making the documents better!

Dino