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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 07 August 2020 01:28 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C285A3A0BD5; Thu, 6 Aug 2020 18:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ysubu0uWjEpY; Thu, 6 Aug 2020 18:28:37 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D513A0BD3; Thu, 6 Aug 2020 18:28:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4BN76X5kHrz1ntYj; Thu, 6 Aug 2020 18:28:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1596763716; bh=/JmcFTflBbNN3FQ96QJfhaxVX71Bw/uTA28HaeGhhjs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Wgoj2NnqAtDxmEMwbSdfuKwAXwSmR1XzJe20cJLVzq6mWlxEG8HjmhFYnpHjHbM7f lTG3Ni2pyWMz/zVK7TwLctG0UfXJTdVimvJ/KnXWTdPgi0B0+2ZwqYbJ/ucJiAN3B0 QfwXVQ0uOprCHuVO3QqAIyCl+ElnPX/4Xl36Lxro=
X-Quarantine-ID: <AjexILzY0VAH>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4BN76W68Gfz1nswn; Thu, 6 Aug 2020 18:28:35 -0700 (PDT)
To: Albert Cabellos <albert.cabellos@gmail.com>
Cc: Luigi Iannone <ggx@gigix.net>, "lisp@ietf.org list" <lisp@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6830bis@ietf.org
References: <159380321143.12143.6218644796105686951@ietfa.amsl.com> <CAGE_QexhF9P5p48qMv83daGcPUB7QQuJif_O__XtAge+Y=rvtQ@mail.gmail.com> <CAM4esxQGF-Ppb2LLf_pHUVREhbzkUOotep9QaPWjqwVPHSGQ=w@mail.gmail.com> <59c9e927-3273-a0ff-9147-98a9d8b0f649@joelhalpern.com> <CAM4esxSf_uhCqUn0KGumj_6nzuj63DPyNz11mqD7Fw9GOpAcDQ@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <1774564a-c449-145e-8fa0-b3e6c178b4d6@joelhalpern.com>
Date: Thu, 06 Aug 2020 21:28:34 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAM4esxSf_uhCqUn0KGumj_6nzuj63DPyNz11mqD7Fw9GOpAcDQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/LSlXuu8q5RCi63UDvld1E4bI_pE>
Subject: Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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, 07 Aug 2020 01:28:39 -0000

Exploring Martin's second comment, I looked at section 7.2 of the draft. 
  I do not see any obvious reason why this section is restricted to 
IPv4.  If there is a reason, we need to state it.  If there is no 
reason, we should allow it for the v6 case as well.

Yours,
Joel

On 8/6/2020 6:24 PM, Martin Duke wrote:
> Hi Joel,
> 
> I'm realizing that we may not have a consensus document that provides 
> good guidance on how to proceed. I'm going to consult with a couple of 
> SMEs and come up with a reasonable recommendation. This shouldn't take 
> any more than a couple of days.
> 
> However the "IPv4 only" recommendation is just wrong and should be reverted.
> 
> On Thu, Aug 6, 2020 at 1:48 PM Joel M. Halpern <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> wrote:
> 
>     Martin, I want to check one aspect of your response about MTU handling.
> 
>     The entity which is originating the packets, and receiving the ICMP
>     responses, is the ITR.  In most cases, the ITR is a router.  I do not
>     know of any tunnel protocol for rotuers that expects the routers to
>     store state about the packets it has sent in the tunnels.
>     As these are low-state tunnels, and as the packets are those
>     provided by
>     the sources behind the ITR, I doubt that we can use PLPMTUD, although I
>     would be happy to be given enough information to find I am wrong
>     about that.
> 
>     I am somewhat confused as to what you would have us do.
>     Yours,
>     Joel
> 
>     On 8/6/2020 4:35 PM, Martin Duke wrote:
>      > 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
>      > <albert.cabellos@gmail.com <mailto:albert.cabellos@gmail.com>
>     <mailto:albert.cabellos@gmail.com
>     <mailto:albert.cabellos@gmail.com>>> wrote:
>      >
>      >
>      >     On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker
>      >     <noreply@ietf.org <mailto:noreply@ietf.org>
>     <mailto:noreply@ietf.org <mailto:noreply@ietf.org>>> 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
>      > octets?
>      >
>      >
>      >      >
>      >      > 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
>      >
>     <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-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?
>      >
>      > Martin
>      >
>      > _______________________________________________
>      > lisp mailing list
>      > lisp@ietf.org <mailto:lisp@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/lisp
>      >
>