[lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-gpe-08: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 25 October 2019 00:45 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 B6215120019; Thu, 24 Oct 2019 17:45:27 -0700 (PDT)
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.108.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <157196432774.11379.4337977686963900033.idtracker@ietfa.amsl.com>
Date: Thu, 24 Oct 2019 17:45:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/BI1AP5Bhf_KpR8Wd-pKkbA7FW80>
Subject: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-gpe-08: (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: Fri, 25 Oct 2019 00:45:28 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-gpe-08: 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-gpe/



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

Thank you for the updates in the -08!
Can you please say "partially mitigates" instead of "mitigates" in "However,
the use of common anti-spoofing mechanisms such as uRPF mitigates this
form of attack."?

Now that RFC 8060 is a normative reference, it's a downref that I believe will
need to be IETF LC'd again.


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

[original COMMENT section unchanged; contents presumably stale]

Section 1

   LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
   has allocated all by defining a Next Protocol "shim" header that

nit: allocated all of what?

Section 3

This is not exactly the responsibility of LISP-GPE merely because it
allocates the last bit in this bitmap, but it seems like it would be quite
useful to have a table of which combinations of values are valid vs.
nonsensical, given the somewhat complicated interaction between some of
these flag bits.

      Similarly, the encoding of the Source and Dest Map-Version fields,
      compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8
      bits.  This still allows to associate 256 different versions to
      each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping
      to inform commmunicating ITRs and ETRs about modifications of the
      mapping.

Are we limited to 256 versions total, or is there some sort of larger
version space that we truncate to send (a la a wraparound process)?
I understand that map-versioning is primarily in a separate document but it
seems important for this document to describe to what extent it is limiting
functionality.

Section 3.1

   To ensure that protocols that are encapsulated in LISP-GPE will work
   well from a transport interaction perspective, the specification of a
   new encapsulated payload MUST contain an analysis of how LISP-GPE
   SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit
   Congestion Notification (ECN) bits whenever they apply to the new
   encapsulated payload.

This MUST is duplicated in the next three paragraphs; I would suggest
leaving this introduction as non-normative, with something like "needs to
contain an analysis of how LISP-GPE will deal with [...]"
Also, nit: "the outer UDP Checksum"

Section 4

   When encapsulating IP packets to a non LISP-GPE capable router the
   P-bit MUST be set to 0.  [...]

   A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the
   P-bit set to 1) to a non-LISP-GPE capable router.

I'm failing to see how these two sentences are not redundant.

Section 5.1

Just to be clear, the intent is that if there is some non-IETF protocol
that we want to encapsulate, we write a two-page Standards-Track RFC that
says "this GPE codepoint means to do what this non-IETF document says"?

Section 6

                       However, the use of common anti-spoofing
   mechanisms such as uRPF prevents this form of attack.

I think "mitigates" is probably better than "prevents" in this case.

   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
   protection mechanisms (such as IPsec) SHOULD be used in combination
   with LISP-GPE by those protocol extensions that want to protect from
   on-path attackers.

The g-Bit is present in the Map-Reply message, which can in the general
case be sent via triangle-routing, in which case the establishment and
selection of IPsec security associations is somewhat nontrivial and
probably does not quality as "typical", based on my limited experience.
I think a more general scheme for providing integrity protection for
mapping messages is needed as a mandatory mechanism, but that's a topic for
the control-plane document so I will not belabor it here.