Subject: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 07 Jul 2020 15:03:37 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-32: 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-rfc6830bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 1.1. The applicability statement of “large set of cooperating
entities seeking to communicate over the public Internet or other large
underlay IP infrastructures” seems inconsistent with many of the protocol
mechanics described.  Specifically, most of the capabilities in the LISP header
(Locator-Status-Bits, Echo-nonce mechanism, Map-Versioning, Instance ID) and
the “Gleaning mechanism” are explicitly noted as not being suitable for
Internet use.  This section needs to be explicit that only a subset of the
protocol is suitable for the Internet.  Likewise, it should be clearer about
what is assumed elements of the closed network are trusted for what particular
behaviors.

** Section 16. Per “Locator-Status-Bits, echo-nonce and map-versioning SHOULD
NOT be used over the public Internet and SHOULD only be used in trusted and
closed deployments” -- not disagreement.  However, under what circumstances
would they be used on the internet to warrant a SHOULD NOT instead of a
stronger MUST NOT?

** Section 8.  Per “Participants within a LISP deployment must agree on the
meaning of Instance ID values.  The source and destination EIDs MUST belong to
the same Instance ID.”  Could parties agree that the Instance ID is 802.1Q tags
and send those across the internet?  Recommend stronger cautionary language on
using Instance ID.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for being responsive to the prior security feedback from the SECDIR
(and thanks to Kyle Rose for performing it) and Security ADs in the return of
this document to the telechat.

I support Martin Duke’s DISCUSS position and endorse the creation of a
dedicated section covering which protocol features should not be used on the
internet.

**  Section 4.0.  Per “… this document recommends that a maximum of two LISP
headers …”, should a normative RECOMMENDED be used here instead?

** Section 5.3. Per “However, the same nonce can be used for a period of time
when encapsulating to the same ETR.”, should this be bounded, even
qualitatively?

** Section 9.
      A
      "gleaned" Map-Cache entry is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner-header IP
      source address) of the received encapsulated packet.

-- Is there any more precision that could be provided about the cache lifetime
beyond “a few seconds”

-- Should normative language be provided that this cache should be aged and
verification performed?

** Editorial Nit
-- Section 13.2. Typo s/synzhronization/ synchronization/

---

From: Albert Cabellos <[email-masked]>
Date: Fri, 31 Jul 2020 14:33:45 +0200

Hi,

Thanks for your comments, we have updated the draft accordingly (-28):

Find below the specific changes and responses to your comments:

> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

 We have added this to the following new section (section 4.1):

4.1.  Deployment on the Public Internet
   Several of the mechanisms in this document are intended for
   deployment in controlled, trusted environments, and are insecure for
   use over the public Internet.  In particular, on the public internet
   xTRs:
   o  MUST set the N, L, E, and V bits in the LISP header (Section 5.1)
      to zero.
   o  MUST NOT use Locator-Status-Bits and echo-nonce, as described in
      Section 10 for Routing Locator Reachability.  Instead MUST rely
      solely on control-plane methods.
   o  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
      as described in Section 13 to update the EID-to-RLOC Mappings.
      Instead relying solely on control-plane methods.

> would they be used on the internet to warrant a SHOULD NOT instead of a

Gleaning, Locator-Status-Bits, echo-nonce and Map-Versioning elevated to
MUST NOT.

> and send those across the internet?  Recommend stronger cautionary
language on

We don´t want to specifically restrict communications between different
Instance IDs, this is up to the deployer. Yes, Instance ID can be used to
carry 802.1Q tags, this is an example stated in the document.

Changed, thanks

> when encapsulating to the same ETR.”, should this be bounded, even

I have removed this sentence, so the same nonce can not be used when
encapsulating to the same ETR.

> -- Should normative language be provided that this cache should be aged
and

Changed to:

 “A "gleaned" Map-Cache entry is only stored and used for a RECOMMENDED
period of 3 seconds, pending verification.  Verification MUST be performed
by …”

> -- Section 13.2. Typo s/synzhronization/ synchronization/

Changed, thanks!

Albert