[lisp] Roman Danyliw's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 07 July 2020 22:03 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 811763A0B58; Tue, 7 Jul 2020 15:03:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lisp-rfc6830bis@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org, Luigi Iannone <ggx@gigix.net>, ggx@gigix.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <159415941702.24136.15542441294809192846@ietfa.amsl.com>
Date: Tue, 07 Jul 2020 15:03:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/SqmcUaWQc5B_Wk0YGq1vXjWQzUc>
Subject: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2020 22:03:44 -0000
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/
- [lisp] Roman Danyliw's Discuss on draft-ietf-lisp… Roman Danyliw via Datatracker
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Albert Cabellos