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

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 08 July 2020 03:05 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 B2B8A3A1025; Tue, 7 Jul 2020 20:05:02 -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-rfc6833bis@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: <159417750218.21269.13323185361160360005@ietfa.amsl.com>
Date: Tue, 07 Jul 2020 20:05:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/UCbb6ZvS9-Q-Vf5QBx7eq7mP_zc>
Subject: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-rfc6833bis-27: (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: Wed, 08 Jul 2020 03:05:03 -0000

Roman Danyliw 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:
----------------------------------------------------------------------

** The applicability statement in Section 1.1. notes that this will be used on
the “public Internet”.  Therefore, I think we need to consider the use of
“secure defaults”.  Making lisp-sec and a strong MAC-KDF mandatory to implement
is helpful.  However, it’s use must also be normatively specified. 
Specifically, stronger guidance needs to be given when communicating over the
public Internet.  My thinking would be something like:

-- lisp-sec SHOULD (MUST?) be used in for Map-Reply, Map-Notify, Map-Notify-Ack
and ECM (i.e. SHOULD/MUST set S=1)

-- Map-Register SHOULD (MUST?) use HMAC-SHA256-128+HKDF-SHA256

-- MUST NOT use Algorithm ID = 0 and 1


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

I support Ben Kaduk’s DISCUSS position on the MTI MAC-KDF and LISP-SEC clarity.

Per the issues of the MTI MAC-KDF, I recommend Section 9 (“An implementation
MUST support HMAC-SHA256-128+HKDF-SHA256 [RFC4868]”)

I support Martin Duke’s DISCUSS position.

** Section 5.3.  Per “After 10 retransmits without receiving the corresponding
Map-Reply must wait 30 seconds.”, should this be a normative MUST?

** Section 5.6.  Per “If a Map-Register is received with a nonce value that is
not greater than the saved nonce, it drops the Map-Register message and logs
the fact a replay attack could have occurred”, should normative language used
here – “… it MUST drop the Map-Register message and SHOULD log the fact that a
replay attack …”?

** Section 9.  The assumption that “The ETRs have a pre-configured trust
relationship with the Mapping System, which includes some form of shared secret
… [and] establishment is out of scope of this document.” seems like a
significant unaddressed hurdle at scale.

** Section 9.  Per assumption 2 that a “… Mapping System is aware of which EIDs
an ETR can advertise.”, what behavior should the mapping system take when it
gets a Map-Register whose scope does not match this information?

** Editorial Nits

-- Section 5.4.  Typo. s/encapsualted/encapsulated/

-- Section 5.6.  Typo. s/the the/the/

-- Section 5.6.  Typo. s/section Section/Section/

-- Section 9.  Typo. s/operartors/operators/

-- Section 9.  Typo. s/eavesdroping/eavesdropping/