IETF Logo Mail Archive

Re: [tcpm] PLPMTUD for all protocols

William Herrin <bill@herrin.us> Fri, 30 March 2018 15:21 UTC

Return-Path: <bill@herrin.us>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBE0127076 for <tcpm@ietfa.amsl.com>; Fri, 30 Mar 2018 08:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 GHMT4adNpPGQ for <tcpm@ietfa.amsl.com>; Fri, 30 Mar 2018 08:21:54 -0700 (PDT)
Received: from magic.dirtside.com (magics.dirtside.com [199.33.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7230A126FDC for <tcpm@ietf.org>; Fri, 30 Mar 2018 08:21:54 -0700 (PDT)
Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id w2UFLm3c005069 for <tcpm@ietf.org>; Fri, 30 Mar 2018 11:21:48 -0400
X-Really-To: <tcpm@ietf.org>
Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com [74.125.83.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id 8B81FEBDB2 for <tcpm@ietf.org>; Fri, 30 Mar 2018 11:21:48 -0400 (EDT)
Received: by mail-pg0-f53.google.com with SMTP id j3so5233818pgf.2 for <tcpm@ietf.org>; Fri, 30 Mar 2018 08:21:48 -0700 (PDT)
X-Gm-Message-State: AElRT7EelaA6aXgYJ1dVjdF5m12HkRTuTZDNNCHjSvkFQb0zgPKiqXgK sC9F2S26QmQZmp+CEQHNSDPySIMOTYjxob3a87o=
X-Google-Smtp-Source: AIpwx4+QQ0/M+GHspEqwNsujPu2bo9pqpZGj03ql7rSGW9cs9/B413lQQx+xB6QJccDWMIO2TJ6EM20SDLd81nlXpgk=
X-Received: by 2002:a17:902:8602:: with SMTP id f2-v6mr13086331plo.73.1522423307439; Fri, 30 Mar 2018 08:21:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.183.67 with HTTP; Fri, 30 Mar 2018 08:21:26 -0700 (PDT)
In-Reply-To: <20180330140456.GH3590@faui40p.informatik.uni-erlangen.de>
References: <alpine.DEB.2.20.1803281034310.20609@uplift.swm.pp.se> <CAP-guGVEcnk09yi8sz+fmghpeb91Y8tQb+LsEmSF+0e+f6oGhw@mail.gmail.com> <alpine.DEB.2.20.1803281747020.20609@uplift.swm.pp.se> <B323BA47-32DF-498B-9D1F-5A378E7ABB98@strayalpha.com> <CAP-guGXfds60dwJXgnSYdbtQ-qOCJGpiw1kcYUkJR8L3jwsFSA@mail.gmail.com> <alpine.DEB.2.20.1803291727100.20609@uplift.swm.pp.se> <CAP-guGWhyS0UW9YwsQyA10iN_M=yc4H8NqKAgWH=zPBFhscJxQ@mail.gmail.com> <20180329174920.GV30215@faui40p.informatik.uni-erlangen.de> <CAP-guGVGp8k37b__hb6ve5V9h3QyYAivpA+X8iqJB_vskBnc=g@mail.gmail.com> <20180330140456.GH3590@faui40p.informatik.uni-erlangen.de>
From: William Herrin <bill@herrin.us>
Date: Fri, 30 Mar 2018 11:21:26 -0400
X-Gmail-Original-Message-ID: <CAP-guGUzHMLR8goFWpq4RciKZXjXjM2_xcAH1kGF0wuk_p7X0Q@mail.gmail.com>
Message-ID: <CAP-guGUzHMLR8goFWpq4RciKZXjXjM2_xcAH1kGF0wuk_p7X0Q@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: tcpm@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Checker: magic.dirtside.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/39dwe7w961OTQ2S96OJPQeU9dFM>
Subject: Re: [tcpm] PLPMTUD for all protocols
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2018 15:21:56 -0000

On Fri, Mar 30, 2018 at 10:04 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> On Fri, Mar 30, 2018 at 08:44:46AM -0400, William Herrin wrote:
>> 1. Recommend that router implementations "SHOULD" provide the option
>> to generate ICMPv4 type 3 code 4 (fragmentation needed) messages and
>> ICMPv6 type 2 (packet too big) messages from an address different than
>> the source interface address.
>
> rfc1918/ULA on interfaces plus RPF later on ?
> SP edge filtering of IF-address ranges ?

Hi Toerless,

These are the most common ones AFAIK.


> Any other known systematic reasons ?

"Don't ping me bro." ACL drops ICMP except to administrative addresses.

"Can't get there from here." No route to the source available to the
objecting router.

MPLS. Objecting router doesn't have the protocol wrapped inside the
oversize MPLS frame.


> The main problem iwth such a command is to make operators not forget
> applying it. Or even having an address that would allow for the packet
> to be passed back.

Start with making it possible for operators to apply it. If we need
more, ask IANA to assign an IP address dedicated to fragmentation
needed / packet too big messages and define the conditions in which
routers should select that standard address by default instead of the
interface local address. Perhaps when the interface is configured with
an RFC1918 address but the source of the offending packet is not an
RFC1918 address. Then adjust reverse path filtering to pass that
standard address. Maybe some delay so that passing the standard
address becomes a must for RPF implementations immediately but the
default substitution of the standard address should not be enabled by
default in implementations for a few years.

Tunables all around so that sufficiently savvy (or sufficiently
foolish) operators can force the behavior.



> I would also bet there are possible
> attack vectors with ICMP fragmentation needed messages.

One obvious attack vector is to block them. ;)

I do take your point though.

Regards,
Bill




-- 
William Herrin ................ herrin@dirtside.com  bill@herrin.us
Dirtside Systems ......... Web: <http://www.dirtside.com/>

v2.23.0 | Report a Bug | By Email