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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-rfc6833bis-27: 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:
----------------------------------------------------------------------

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


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