Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)

Martin Duke <> Thu, 06 August 2020 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A59F3A0EAD; Thu, 6 Aug 2020 13:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dM2NdfGcKKwZ; Thu, 6 Aug 2020 13:36:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 732A43A0EAB; Thu, 6 Aug 2020 13:36:00 -0700 (PDT)
Received: by with SMTP id e16so6908922ilc.12; Thu, 06 Aug 2020 13:36:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bvC0yYDaXegyVqHl++Tep1ue9PZF67nteg1cWniGx+4=; b=o+CWliapKIgKwLCExB4GVy5PZQUd5gvCz96G34jB6mpdFYB/ADgQftAPvBLz1gMxgF +UJSdHz/sUo9PwxVY0UkNY9Fdw/z+4DJNwpPOSVUsYB1tzOLJcz1OsqnmjnbhGcQV6oR z/KU9LfVtE9JKbgSCzcZ9n2Ab2Xd4M3rnPBW26a3vChjVrPpbh42+gfVuFHh/qpuZj3w wcK4cFs585fii2ogQYjdev4QCdjp8eP1EVpdLZ/JUJAcBgwRU7DubRNq67COqz4rRQaJ xxN1B4K9NtW1kof8TD0948XUtEY5jYAk370htCCk6ZomRQav/l6oorctgcgJl23WAF+B 9aAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bvC0yYDaXegyVqHl++Tep1ue9PZF67nteg1cWniGx+4=; b=ARqAJXspSSdF2BMpT2GMbjXoL9xyZuKhOgY22KFgoaky01HrKpQmoSMzNEzO61mM6m dttt/5zu4oiROITM4slkRmYx2B1wn7PahuMoXgyOt4xd3rNM+rnccUAJSJwWxAw3zFbr gOm3Ao6iDUuWPiau6ZGS507IXHxC3C3GICHOVkOZhabZ2D7N20ypRM3TDhEOBlZ057dL 2ibvlJzcdNwj2Ga9Aq5jPOoOsT6G+Z1s8vSe+jHxe0ntfZ+EvNWHtrY1btnOuwehH7DL x4XCDWj8yjYqjyjAK/Hux076rupjYFrbOBvMv+mevByj/b+pUszHNvK/AiKE0fboyar/ oZpQ==
X-Gm-Message-State: AOAM530nINl2B784LLZnNPOtZ1jSDpTVg8E0NqQY8pNys1pR2EQTQmsE /o8FwOSmsPyDw7MFYpGtpH7a4+jv33wmSMdWH5I=
X-Google-Smtp-Source: ABdhPJwkEwuF+gCJisDVFbyT4xkKcT3WQFnL4z+JwXufajGrF1BP61OkD9ow9Dzz/8CMe5SJjS3rhTIwzupz1Ea7FRI=
X-Received: by 2002:a92:1f0f:: with SMTP id i15mr805968ile.237.1596746159682; Thu, 06 Aug 2020 13:35:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Thu, 6 Aug 2020 13:35:58 -0700
Message-ID: <>
To: Albert Cabellos <>
Cc: The IESG <>,,, " list" <>
Content-Type: multipart/alternative; boundary="000000000000a4fa3405ac3b6ffc"
Archived-At: <>
Subject: Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Aug 2020 20:36:03 -0000

Hi Albert,

thanks for the edits, and sorry for the delay! We're not quite there on a
few of the items:

Though first, there is now a duplicate paragraph in Section 7. Please
delete one.

On Fri, Jul 31, 2020 at 5:43 AM Albert Cabellos <>

> On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker <
>> wrote:
> >
> > Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits
> are
> > zero?
> >
> There is no field then.

so the bits are set to zero, or is the LISP header actually shorter by 3

> >
> > Sec 7.2 The stateful MTU design does not incorporate any security
> measures
> > against ICMP spoofing. At the very least, the ITR needs to make sure
> that some
> > fields in the outer IP and UDP headers are hard to guess, and that this
> > information is stored to verify that the ICMP message came from on-path.
> If
> > this is not possible, the design is not safe to use over IPv4.  If
> > hard-to-guess information is not available to be stored deeper in the
> packet,
> > then it is not safe over IPv6 either.
> >
> The source UDP port is random. We have therefore added the following
> statement at the beginning of section 7.7:
>    An ITR stateful solution to handle MTU issues is described as follows,
> this solution can only be used with IPv4-encapsulated packets:
This is backwards, and anyway inadequate.

An off-path attacker can generate a fairly small number of ICMP messages to
reduce the MTU to ridiculously low levels (e.g. 68 bytes), which depending
on tunneling overhead could render the path unusable. The defense against
this is to either ignore ICMP messages (instead using PLPMTUD
<> to
find the MTU) or to compare the echoed information the ICMP message against
the stored contents of the packet, where obviously there needs to be enough
entropy to make it hard to guess. Generally the port is not sufficient
entropy, since it takes fewer than 2^16 packets to take you down, but
admittedly there isn't much UDP-based protocols can do about this.

In IPv6, the router should include as much of the packet as possible in the
ICMP packet, so the chance of guessing is low. It's therefore it's simply a
matter of specifying that hosts should store the packet payload and do the
validation step.

In IPv4, the router is required to include the first 8 bytes of the IP
payload (eg the UDP header), so all you have are the IP and UDP headers.
Hosts should still do the validation.

The main thing is to tell them to do that validation.

> >
> > Sec 7.2 There is a fourth situation which can arise. If the ETR receives
> an
> > ICMP packet from an EID in its network. I have a couple of questions
> about what
> > should happen in this case:
> >
> In this case the EID is locally attached to the xTR. Therefore, the xTR
> has a locally configured MTU to reach the EID. So what is written in the
> section already covers this scenario.
> >
> > - How is this communicated to the sender of the flow that triggered the
> > message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the
> source
> > EID, both, or neither?
> >
> > - Is the ETR responsible for enforcing the MTU to that EID for
> subsequent flows?
> >

I read 7.2 again and I don't see that it does. According to this section,
what does the ETR do when it receives a packet from the ITR that exceeds
the locally configured MTU?