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

[Albert Cabellos <[e-mail]>]

Hi

I´ve posted -29 following your comments, please find inline specific responses:

On Thu, Jul 9, 2020 at 6:26 AM Benjamin Kaduk via Datatracker
<[e-mail]> 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.

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


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

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


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


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


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

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

>    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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp