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

Martin Duke <martin.h.duke@gmail.com> Wed, 09 September 2020 21:37 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 441813A0EE2; Wed, 9 Sep 2020 14:37:07 -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 sIo8KGUig91C; Wed, 9 Sep 2020 14:37:05 -0700 (PDT)
Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 D15643A0EE1; Wed, 9 Sep 2020 14:37:04 -0700 (PDT)
Received: by mail-il1-x143.google.com with SMTP id a8so3803125ilk.1; Wed, 09 Sep 2020 14:37:04 -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=Vi+1R4sIkY+/XAJNnsPlNQc0cS0IHDFKUOpz4AZcPv0=; b=X3x/cx48ArLsJ4coWa+Yw/Cn7TyQAYmDlnTeKNBlWD+2sJC8yEhBNBTI1k8iZ/c9Ne kHfsMxy+AdU/rd67MiyXEr1Df5EMfNa6uUsuJSrJofK4lvBn/RpTZSuFNjpj2gC1/iI/ H0uqJ0KK8JcLV2mDyLtNW0bZg3WiQ5dr6+MmFTg8XOGoihPCaHr8dl2HCpUOs4E7Q2MX Fir40XKqdEAfVp8cr+D588oon/y4nw+7ug/+B4tiT+cgn0KsTk7tariSIzclxLNlnzBY vu4Ws0OAVjqjBYNAI9xKlaGJtz1Tic1bOnXb6LGh2DC8bHqJYo3ST8+nMMbVCVYF68dS Hp6Q==
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=Vi+1R4sIkY+/XAJNnsPlNQc0cS0IHDFKUOpz4AZcPv0=; b=rZLhoBGVSTdcGIxQJs41gx3iTzmYHWH/u8lbMEZyy3MQy5SPASytoNAntBdMZaIXRe vW89SJddL/sZsvRb1pv97jvmuugU2V/r93BuoqGVadhNbv49cZ/4YbB2FAx+um+Fgt6K kYrl7uUaJVxCdKkUtFIP8S63YpR1YCo9Vsx6CUligfUJ+CAA8evGj6jA7sX9O0vKFRvm Q9NHqBz35FMhPSxE1f/L8wptNRXiGhDk+EoALPWfaDnYDfdbmc8Pk6B5ucLgMRqekexX /xF8hcdfkdD8jPWRPhHmga+fCsD9MGiBBiTCQkzVSvPZjG8kgJ97C8naHByfxiiexPpu GFEg==
X-Gm-Message-State: AOAM531I6XuaLhzlNRPbPzGq1lPHAQ68o6q/nvSX3WYtiHFCs871PcDd Woo76JOv7cHTCkzzgcc3WQDaXSONsKn40F1m0s0=
X-Google-Smtp-Source: ABdhPJzMrvOqBgrGKoAP2bbNjM0zq7gjtl9ZZQe8WEsrHCZHfXahlRVDChhFcJyiE0eDPZeR9C/ls4RcgbB+tK0+Ih0=
X-Received: by 2002:a92:c98c:: with SMTP id y12mr5269656iln.272.1599687424022; Wed, 09 Sep 2020 14:37:04 -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> <CAM4esxSf_uhCqUn0KGumj_6nzuj63DPyNz11mqD7Fw9GOpAcDQ@mail.gmail.com> <1774564a-c449-145e-8fa0-b3e6c178b4d6@joelhalpern.com> <CAM4esxTGrAFbbOWHc_R_ULGaAFfHCd6v7ky55JPUwZF0BbTOWQ@mail.gmail.com> <CAGE_Qez_8FuazJ2McDVMnMV50mDq7VV=0Xyt=DhehRinyzy8+A@mail.gmail.com>
In-Reply-To: <CAGE_Qez_8FuazJ2McDVMnMV50mDq7VV=0Xyt=DhehRinyzy8+A@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 9 Sep 2020 14:36:53 -0700
Message-ID: <CAM4esxTRyjOs9Or2Nwu2F3Vvjh4q6rO26Qu9-8-9P_+ZRKDXFw@mail.gmail.com>
To: Albert Cabellos <albert.cabellos@gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, Luigi Iannone <ggx@gigix.net>, draft-ietf-lisp-rfc6830bis@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a91edd05aee840c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/kQxfkbUCaRSkEAa3dKe-M8gGMyQ>
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: Wed, 09 Sep 2020 21:37:07 -0000

Thanks Albert!

This all looks great, except one last thing that dropped out of the thread:

>>
>> 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.

I don't see why this is the case. In Sec 7.2, option 3 implies that the ITR
is not immediately attached to some endpoints. Why couldn't an ETR receive
an ICMP message from one of its destinations?

On Wed, Sep 9, 2020 at 5:56 AM Albert Cabellos <albert.cabellos@gmail.com>
wrote:

> Hi Martin
>
> Just posted -34 per your comments:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-34
>
> 1) Removed duplicate paragraph in section 7
> 2) Added the following sentence for clarification of what happens when N=0
> and V=0: "*Finally, when both the N and V-bit are not set (N=0, V=0),
> then both the Nonce and Map-Version fields are set to 0 and ignored on
> receipt*"
> 3) Removed the IPv4-only requirement in section 7.2. Please note that this
> is in -35 since I missed it in the first place.
> 4) Added the following paragraph (yours, verbatim) at the end of section
> 7.2:
>
> *Please note that [RFC1191] and [RFC1981], which describe the use of ICMP
> packets for PMTU discovery, can behave suboptimally in the presence of ICMP
> black holes or off-path attackers that spoof ICMP. Possible mitigations
> include ITRs and ETRs cooperating on MTU probe packets ([RFC4821],
> [I-D.draft-ietf-tsvwg-datagram]), or ITRs storing the beginning of large
> packets to verify that they match the echoed packet in ICMP Frag
> Needed/PTB.*
>
> Albert
>
>
> On Fri, Aug 14, 2020 at 12:17 AM Martin Duke <martin.h.duke@gmail.com>
> wrote:
>
>> As promised, here are my reconsidered thoughts about Section 7.2:
>>
>> 1) as agreed before, delete the restriction to IPv4 and restore the other
>> references to ICMPv6 in draft-31.
>>
>> 2) There is not an IETF consensus document that describes what I feel to
>> be the most secure way to do tunnel PMTU management. So the current design
>> is acceptable; however, there should be some warning about the robustness
>> issues here. Example text:
>>
>> "Please note that [RFC1191] and [RFC1981], which describe the use of ICMP
>> packets for PMTU discovery, can behave suboptimally in the presence of ICMP
>> black holes or off-path attackers that spoof ICMP. Possible mitigations
>> include ITRs and ETRs cooperating on MTU probe packets ([RFC4821],
>> [I-D.draft-ietf-tsvwg-datagram]), or ITRs storing the beginning of large
>> packets to verify that they match the echoed packet in ICMP Frag
>> Needed/PTB."
>>
>> Feel free to re-word, of course.
>>
>> This can either be in the section or mentioned in security considerations
>> with a pointer in 7.2.
>>
>> Martin
>>
>> On Thu, Aug 6, 2020 at 6:28 PM Joel M. Halpern <jmh@joelhalpern.com>
>> wrote:
>>
>>> 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
>>> >      >
>>> >
>>>
>>>