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

Martin Duke <martin.h.duke@gmail.com> Thu, 06 August 2020 22:24 UTC

Return-Path: <martin.h.duke@gmail.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 BD9E53A08AB; Thu, 6 Aug 2020 15:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lwWwgI6w6TAw; Thu, 6 Aug 2020 15:24:48 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FC93A0807; Thu, 6 Aug 2020 15:24:47 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id z17so184731ill.6; Thu, 06 Aug 2020 15:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AP6NVojKlCBvghmaP2WuqMC7qUCMA0p6NYmEP57sk54=; b=jEIjm6tT0kTLVc18S2lluQU4ces5gs2nFF4aJSBjT1P0ThAZkwbkvRgXUZDkQHaxqY 7Co4+U7eEMfx/pKRfnqSVzF69FaQ4vmm2jGKzDOkP7Hwju41EDS3hi+2cA6hLpMyxM8S jOWpMDkuXU9qB9uSOIaKv4cCg3rbxw4UI6sGFnaDvucWaTaLhpHS36DFQF0iBuZXoWB6 WjJGrW38AbmbO85ARHeuAfmNxBHp3inA3HFDAMSLNhV05qiVRQoFfmh/U1zAnDYQx73U C+RNpeVGe8riCZ/eQ57gY+S4leb5rj7YDE3d+/Uc4MiKNX/4KcmxsAkQJYCwG7UAIOuM qyBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AP6NVojKlCBvghmaP2WuqMC7qUCMA0p6NYmEP57sk54=; b=SPww4ZeP8mgzJsGwGKNNcS650V3uTK69ttyceFXzXf2F1Cgqxjk5J62Vcgxk0DUDEb HUZzzhzQzD0lZCKQPrUEyG2J5Se3W4yBQdA5Lvw/JdhARstrq29g/WPxEYo0H2OjsLtj J+2MLKFbAeElJebk15bmpo2HooS+iTA9pYjL3OA73wnQr5iUSYS4nBD7wDvCc2vJiuvr HVTmVTCD6FHBBgFskZzGiiy3zaKYOdwj6c9igHjWeO08IBZOnbKONaKTQC/+Zy+JmCyE j5UkWG2HkY0ik+VyfM07LP6euA5PqY9ySHxDSZxtoH3GZnOKKoGLYYQC6VJRfiF9k0/Q l6Nw==
X-Gm-Message-State: AOAM533IjZIfw2Z6YSVQP9SLEu5E14/Q0B6vLSirUYivvkQLRQFQQOqA q1SwlPSnOmdIrQRJ6zSFWPjwFTtnuiPT+jw63zg=
X-Google-Smtp-Source: ABdhPJy9cgV6A72vq/LgSI+sipfZ9j5G6HdyNC6g5w+qezsPTcsWxhmErAmy+SuURc+UsuBCmLZ8BgbqxvNwNc/Z/rs=
X-Received: by 2002:a92:d30a:: with SMTP id x10mr1232310ila.287.1596752687237; Thu, 06 Aug 2020 15:24:47 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <59c9e927-3273-a0ff-9147-98a9d8b0f649@joelhalpern.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 6 Aug 2020 15:24:46 -0700
Message-ID: <CAM4esxSf_uhCqUn0KGumj_6nzuj63DPyNz11mqD7Fw9GOpAcDQ@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Albert Cabellos <albert.cabellos@gmail.com>, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6830bis@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b790a605ac3cf44d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/tuxhlRb920XXRzTyo2ZCqQ06XGs>
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: Thu, 06 Aug 2020 22:24:50 -0000

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> 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>> wrote:
> >
> >
> >     On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker
> >     <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
> > https://www.ietf.org/mailman/listinfo/lisp
> >
>