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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Oct 2020 18:03:27 -0700

Hi Albert,

On Wed, Sep 30, 2020 at 01:31:42AM +0200, Albert Cabellos wrote:
> Hi
> 
> I´ve posted -29 following your comments, please find inline specific responses:

Thanks.  I'll respond to a few things inline, and will then go update my
ballot position.  (To No Objection, hooray!)

> On Thu, Jul 9, 2020 at 6:26 AM Benjamin Kaduk via Datatracker
> <[email-masked]> wrote:
> >
> > 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.)
> >
> 
> From a deployment reality perspective, I think that this makes sense:
> 
>   Implementations of this specification MUST implement
> HMAC-SHA-256-128 and SHOULD implement HMAC-SHA256-128+HKDF-SHA256
> 
> Now it is consistent across the document. Please let me know your view on this.

I think I am resigned to this, since we only added the HKDF stuff at IESG
Evaluation stage.  (I suppose Roman or someone else could feel otherwise,
though.)

> >
> > (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. [...]
> >
> 
> Changed, thanks.
> 
> > (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.
> >
> 
> Updated the section, now all SMR-invoked Map-Requests MUST be sent
> through the Mapping System (This is what deployments are doing):
> 
>           An SMR message is simply a bit set in a Map-Request message.
>           An ITR or PITR will send a Map-Request (SMR-invoked
> Map-Request) when they receive an SMR
>           message. While the SMR message is sent through the
> data-plane, the SMR-invoked Map-Request
>           MUST be sent through the Mapping System (not directly).

Thanks, that does make me feel better about how things work.

> 
> > (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
> >
> 
> Fixed, thanks.
> 
> 
> > (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.
> >
> 
> Fixed.
> 
> > 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).
> >
> >
> 
> Fixed, thanks.
> 
> 
> > ----------------------------------------------------------------------
> > 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").
> >
> 
> Fixed.
> 
> > 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.
> >
> 
> Fixed.
> 
> > 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.
> >
> 
> Fixed.
> 
> > 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?
> >
> 
> Fixed.
> 
> 
> > 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.)
> >
> 
> Reworded to:
> 
> <t hangText="A:"> This is an authoritative bit, 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, and
>         set to 0 otherwise.
> 
> for clarification.

Sounds good.  (The first comma is a comma splice, but I'm sure the RFC
Editor will pick up on it if we don't fix it before then.)

> >    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?).
> >
> 
> Added “the use of this bit is deployment-specific”.

Ah, fair enough.

> 
> >    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.
> >
> 
> This is used when multiple XTR serve the same EID on the same LISP-site.
> 
> 
> >    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?
> >
> 
> Agreed, changed
> 
> 
> >    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.
> >
> 
> Good catch, added this sentence:
> 
> LISP control-plane messages that include an unrecognized AFI MUST be
> dropped and the event MUST be logged.

Thanks.

> 
> >    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.
> >
> 
> Added “It is important to note that this mapping has not been
> validated by the Mapping System.”
> 
> 
> > 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.
> >
> 
> Added “… the sender...”
> 
> 
> >    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.
> >
> 
> Updated to:
> 
>       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 MUST originate
>       a "verifying Map-Request" through the mapping database to validate
>       the "piggybacked" mapping data.
> 
> 
> 
> > 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?
> >
> 
> Updated to “must”
> 
> 
> >    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.
> >
> 
> Changed.
> 
> 
> >    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"?
> >
> 
> There are other reasons for a 0 locator count.

My mistake; sorry.

> 
> >       (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.
> >
> 
> Fixed, thanks.
> 
> 
> >       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.
> >
> 
> Typo, thanks. Changed to:
> 
> This bit indicates to the requesting ITRs if the Map-Reply was
> originated by a LISP node managed at the site that owns the
> EID-Prefix.
> 
> >       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.)
> >
> 
> “equal” seems correct to me.
> 
> 
> >    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?
> >
> 
> correct, removed reference to section 7.1 This was a leftover from
> previous edits.
> 
> 
> >    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"?
> >
> 
> You are right, updated.
> 
> 
> >    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.
> >
> 
> You are right, updated.
> 
> >       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.
> >
> 
> Updated to, please let me know if this is correct:
> 
> The derived per-message key is computed as:
> per-msg-key=KDF(nonce+PSK[Key ID],s). Where the nonce is the value in
> the Nonce field of the Map-Register, '+' denotes concatenation and 's'
> (the salt) 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. For those Algorithm IDs
> defined in <xref target="KEYS"/> that specify a 'none' KDF, the
> per-message key is computed as: per-msg-key = PSK[Key ID]. This means
> that the same key is used across multiple protocol messages.

That should work; thanks.

> > 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.
> >
> 
> Right, updated.
> 
> 
> >    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/
> >
> 
> Fixed both typos, thanks.
> 
> >    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".
> >
> 
> Added
> 
> > 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?
> >
> 
> Correct, updated to:
> 
>         <t hangText="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, or the Authentication Data field <xref
>         target="I-D.ietf-lisp-sec"/> if the S-bit (see below) is set.</t>
> 
> > 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]".
> 
> >
> 
> This text has already changed per another edit.
> 
> 
> >    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).
> >
> 
> Updated in a previous edit.
> 
> > 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."
> >
> 
> Added.
> 
> 
> >    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).
> >
> 
> Agreed, updated.
> 
> 
> > 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?
> 
> >
> 
> It has a less-specific matching the EID, and a more-specific ‘hole’
> (not registered) matching the 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
> >
> 
> Fixed in a previous edit.
> 
> >    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/?
> >
> 
> Added “…can also be exploited…”

That works too; thanks.

Thanks as well for all the other updates that I didn't comment on
specifically!

-Ben

> >    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)
> >
> 
> Removed 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"?
> >
> 
> Updated.
> 
> 
> > 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.
> 
> Updated.
> 
> >
> >    values references with the RFC number assigned to this document.
> >
> > nit: incomplete sentence (lingering remnants of a previous edit that
> > should just get removed?)
> >
> 
> Fixed.
> 
> > 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.
> >
> >
> >
> > _______________________________________________
> > lisp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/lisp