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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 21:51:39 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-rfc6833bis-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/

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

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

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 29 Sep 2018 11:52:55 -0700

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 <[email-masked]> wrote:
> 

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.

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

I made it 2 sentences.

> reference to the existing (and without errata fix!) RFC 2119 boilerplate.

Changed.

> Map-Server returns the registered RLOCs in normal Map-Replys?

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

> the Map-Server comprises part of the mapping database and has local

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.

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

Yes, we are for a desire to be explicit.

> 8126 has lots of procedures; generally we use a name to indicate which one

Have a suggestion?

> Using the same letter with different case for different flag bits sounds

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.

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

> text should be tweaked to avoid suggesting that it is.)

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

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

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

> blindly trying to interpret the start of the request records as an

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

> clarify the flows and the role in which each entity is acting, at each

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

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

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

> don't you need to say that the other 40 bits are used by the mapping

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

> Map-Replies?  If so, I'm confused what the semantics are supposed to be.

No.

> information.  (But maybe not; this needs more analysis)

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

> Map-Reply is sent by an ETR”?

Changed to “when set to 1”.

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

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

> Exactly one or at most one?

We are saying it should not set more than one.

> First overall or first that sets the p bit?

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

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

> nit: This last sentence is a sentence fragment.

Fixed.

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

Added.

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

I have no idea.  ;-)

> just say "This is the output of the MAC algorithm.”

Done. I think Eric made this comment too.

> Also, the MUST/RECOMMENDED status seems backwards.

Changed.

> or uniquely handled for the Map-Register message.

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

> This is underdefined without specifying the exponent base for the

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.

> Please be explicit about whether all such messages are encapsulated or only

We do in other sections.

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

> directly in the Map-Request, though I guess it's a bit late to be changing

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

> places where ECM wrapping is used.

This is LISP-DDT related and in that document.

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

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

> required to keep track of [...]”.

Changed.

> normative requirement (with the use of "will”)?

Change to “LISP encapsulated data packets”.

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

> Map-Request in question and not a global property?

Changed text to your suggestion.

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

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

> but rather network failures of some form?

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

> the 15-minute TTL for this case; please use normative language to that

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

> (Same comment as above about normative language)

Same response.

> Map-Server being part of a single administrative domain.

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

> prone to becoming stale and does not scale.

I am not sure what you think I should change.

> normative requirements to just one location and have a pointer from the

I would like to keep them where they are introduced.

> Should the document reflect that ordering as well?

Leaving it up to the implementation.

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

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

Done.

> [edit: this text changed in the -16]

Let’s save this for the conference call.

> flags fields?  Are documents allocating new ones supposed to Update: this

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.

>   Specification Required policy [RFC8126]. [...]

Fixed.

> 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