[lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-gpe-12: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Mon, 30 December 2019 19:48 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 AA265120B6F; Mon, 30 Dec 2019 11:48:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.115.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <157773531769.4591.17385552684076890219.idtracker@ietfa.amsl.com>
Date: Mon, 30 Dec 2019 11:48:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/6Qh-y52DzLNXQWaFUunseSTQ1_o>
Subject: [lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-gpe-12: (with 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: Mon, 30 Dec 2019 19:48:42 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-gpe-12: No Objection

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-gpe/



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

Thanks for the updates in -10 through -12 to leave nonce/versioning to
additional shim headers/extensions; that does alleviate the concerns that
left me balloting Abstain on the -09.

I do have some (new) comments on the -12.

Section 3

Conceptually, I'm thinking about this document as allocating the 'P' bit in
the header and specifying its format when the P bit is set to 1; I don't
expect it to be making changes to generic non-GPE LISP behavior.  So it's
a little surprising to see that bits 0-3 are now marked as Reserved (though
that could probably be wordsmithed away, and the existing Section 2 probably
sets the reader up to do the right thing already), and fairly surprising to
see the following in the P-Bit description:

      If the P-bit is clear (0) the LISP header is bit-by-bit equivalent
      to the definition in [I-D.ietf-lisp-rfc6830bis] with bits N, L, E
      and V set to 0.

Is the claim that once an implementation supports GPE, it will never use the
non-shim-header versions of echo-nonce, map-versioning, etc?  If not, then I
don't think it's appropriate to say "with bits N, L, E, and V set to 0"
here.

I'm also not sure I fully understand the motivation for pulling out
the Locator-Status-Bits, as that field's width is unchanged from stock
6830bis.  Leaving them to a TBD shim-header does prevent the conflict with
the Instance ID field, and perhaps the current usage patterns justify such a
shift, so this may be more of a side note than an indication of a flaw in
the document.

Section 7

   LISP-GPE, as many encapsulations that use optional extensions, is
   subject to on-path adversaries that by manipulating the g-Bit and the
   packet itself can remove part of the payload.  Typical integrity

Is "g-Bit" supposed to be "P-Bit"?  I am failing to remember what the g-Bit
is, at least...

   With LISP-GPE, issues such as data-plane spoofing, flooding, and
   traffic redirection may depend on the particular protocol payload
   encapsulated.

I'd consider adding another clause, "noting that an attacker that is
spoofing LISP-GPE traffic can claim to encapsulate any protocol payload
type" -- the risk here is based on what types the receiver's implementation
supports, not just what the legitimate sender is encapsulating.