draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration

"Black, David" <david.black@emc.com> Wed, 01 April 2015 02:06 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CF11A007B; Tue, 31 Mar 2015 19:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 AvmL2-_feD2o; Tue, 31 Mar 2015 19:06:29 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 324981A00C0; Tue, 31 Mar 2015 19:06:26 -0700 (PDT)
Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t3126INn013218 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 22:06:20 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t3126INn013218
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1427853983; bh=IJ83JxOdbAmmcJZe1uku93jppuE=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=q/yKgzzmtyslA3brY3YaFp3kmATKQZ1pnCpwZ5n4v833YNESN9d2rcinaxRlfmvfR FGHV+UC8CrlMxzgrDQXUWfKhHkhe5ZiiuQ5edLaYXs8tUNimHbUY9OVlPilHxuTpYh ZNxVGnn2jD16BhTs+ptrScpQgW+66+GBATa3bRR4=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t3126INn013218
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Tue, 31 Mar 2015 22:05:31 -0400
Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t31265UH008854 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 22:06:05 -0400
Received: from MXHUB210.corp.emc.com (10.253.68.36) by mxhub26.corp.emc.com (10.254.110.182) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 31 Mar 2015 22:06:05 -0400
Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB210.corp.emc.com ([10.253.68.36]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 22:06:04 -0400
From: "Black, David" <david.black@emc.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, "int-area@ietf.org" <int-area@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration
Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration
Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAw==
Date: Wed, 01 Apr 2015 02:06:04 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949364314CF@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.120]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: public
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/Unqa3mvLiyBng7_rqPD9KepccMw>
X-Mailman-Approved-At: Wed, 01 Apr 2015 00:24:59 -0700
Cc: "Black, David" <david.black@emc.com>, "draft-ietf-intarea-gre-ipv6@tools.ietf.org" <draft-ietf-intarea-gre-ipv6@tools.ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2015 02:06:34 -0000

So, I talked to Ron off-list and it looks like something is missing from
this discussion.

The "alternative configuration" is not motivated by a desire to allow
implementation flexibility or bless broken implementations.  It's motivated
by consideration of networks with operational practices wherein a GMTU of
less than 1280 octets is evidence that something is seriously wrong.  That
something might be misconfiguration (quoting RFC 5706, "Anything that
can be configured can be misconfigured."), or an attack on the GRE
ingress's PMTU estimation.

So, in the situation of interest (GMTU < 1280) something is wrong, and
the operator may be faced with a Hobson's choice: either blackhole the
traffic that can no longer be sent without fragmentation, or fragment a
lot of traffic, causing problems at the GRE egress by overwhelming its
reassembly code - there may be good operational and/or security reasons
to not want to do the latter.  All of this ought to be explained in the
draft.

Thanks,
--David

> -----Original Message-----
> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Tuesday, March 31, 2015 6:39 PM
> To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org
> Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
> Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
> 
> Hi Ron,
> 
> > -----Original Message-----
> > From: Ronald Bonica [mailto:rbonica@juniper.net]
> > Sent: Tuesday, March 31, 2015 3:12 PM
> > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org
> > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.org;
> intarea-chairs@ietf.org
> > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
> >
> > Fred,
> >
> > It appears that we disagree and have taken to repeating ourselves.
> 
> This is not a disagreement; this is a case in which the text is actually
> broken
> which you have more or less acknowledged. You can fix the text in question
> as follows:
> 
> OLD:
> ****
>    In its default configuration, the GRE ingress router MUST:
> 
>    o  encapsulate the entire IPv6 packet in a single GRE header and IP
>       delivery header
> 
>    o  fragment the delivery header, so that it can be reassembled by the
>       GRE egress
> 
>    However, in an alternative configuration, the GRE ingress MAY:
> 
>    o  discard the IPv6 packet
> 
>    o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6
>       packet source.  The MTU field in the ICMPv6 PTB message is set to
>       the GMTU.
> 
> NEW:
> ****
>    The GRE ingress router MUST:
> 
>    o  if the IPv6 payload packet includes a fragment header, fragment the
>        payload packet into fragments no larger than the GMTU and encapsulate
>       each fragment in a single GRE header and IP delivery header. Otherwise:
> 
>       o encapsulate the entire IPv6 packet in a single GRE header and IP
>           delivery header
> 
>       o fragment the delivery packet, so that it can be reassembled by the
>           GRE egress
> 
>      o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6
>          packet source, subject to rate limiting.  The MTU field in the ICMPv6
> PTB
>         message is set to the GMTU.
> 
> > So, why don't we solicit opinions from the rest of the WG and defer to their
> will.
> 
> We can't do that for broken text. Ram-rodding broken text through the
> process based on popular opinion does not make it good.
> 
> Thanks - Fred
> fred.l.templin@boeing.com
> 
> >
> >                                                         Ron
> >
> >
> > > -----Original Message-----
> > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> > > Sent: Tuesday, March 31, 2015 4:38 PM
> > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org
> > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.org;
> intarea-
> > > chairs@ietf.org
> > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
> > >
> > > Hi Ron,
> > >
> > > I will say again that the minimum IPv6 link MTU is 1280 bytes and so the
> > > design must account for tunnel paths that include links with such a small
> > > MTU. The design must also account for nested tunnels-within-tunnels,
> > > where the MTU seen by the first tunnel ingress may be reduced by
> > > potentially many layers of additional encapsulation.
> > >
> > > But again, the point is that the tunnel ingress cannot legitimately send
> PTBs
> > > that report a size smaller than 1280 *and* perpetually drop packets
> smaller
> > > than 1280 which is exactly the behavior your text is permitting.
> > >
> > > Thanks - Fred
> > > fred.l.templin@boeing.com
> > >
> > > > -----Original Message-----
> > > > From: Ronald Bonica [mailto:rbonica@juniper.net]
> > > > Sent: Tuesday, March 31, 2015 1:21 PM
> > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org
> > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.org;
> > > > intarea-chairs@ietf.org
> > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
> > > >
> > > > Fred,
> > > >
> > > > In the last network that I operated, all interior links had MTU
> > > > greater than 9k. If I configured a GRE tunnel between two points in that
> > > network and detected a GMTU less than 1280, it would have indicated one of
> > > the following:
> > > >
> > > > - Phenomenal brokenness
> > > > - An ICMP PTB-based attack in progress
> > > >
> > > > In such cases, operators need some flexibility in how their networks
> > > > would behave. Why deny them this flexibility by taking away the
> > > configuration option?
> > > >
> > > > Isn't it an operator's prerogative to discard any packet that might
> degrade
> > > network performance?
> > > >
> > > >
> > > > Ron
> > > >
> > > > > -----Original Message-----
> > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> > > > > Sent: Tuesday, March 31, 2015 3:01 PM
> > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org
> > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.org;
> > > > > intarea- chairs@ietf.org
> > > > > Subject: RE: [Int-area] Start of WGLC for
> > > > > draft-ietf-intarea-gre-ipv6
> > > > >
> > > > > Hi Ron,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net]
> > > > > > Sent: Tuesday, March 31, 2015 11:38 AM
> > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org
> > > > > > Cc: Zuniga, Juan Carlos;
> > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org;
> > > > > > intarea-chairs@ietf.org
> > > > > > Subject: RE: [Int-area] Start of WGLC for
> > > > > > draft-ietf-intarea-gre-ipv6
> > > > > >
> > > > > > Fred,
> > > > > >
> > > > > > Some (if not most) operators maintain networks in which all links
> > > > > > have MTU greater than or equal to 1500. In those networks, the
> > > > > > very detection of a GMTU smaller than 1280 indicates brokenness.
> > > > > > Those
> > > > > operators, the alternative behavior may be preferable to the default.
> > > > >
> > > > > The minimum IPv6 MTU is 1280 bytes; that is how much the link must
> > > > > deliver no matter what. A GMTU smaller than 1280 does not indicate
> > > > > brokennesss; it can naturally happen if 1) there is a link with a
> > > > > small MTU in the path, or
> > > > > 2) there are multiple tunnel nesting levels, or both.
> > > > >
> > > > > As such, sustained dropping of packets less than 1280 is a no-no,
> > > > > and cannot be specified in a document like this.
> > > > >
> > > > > Thanks - Fred
> > > > > fred.l.templin@boeing.com
> > > > >
> > > > > >
> > > > > > Ron
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM
> > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org
> > > > > > > Cc: Zuniga, Juan Carlos;
> > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org;
> > > > > > > intarea- chairs@ietf.org
> > > > > > > Subject: RE: [Int-area] Start of WGLC for
> > > > > > > draft-ietf-intarea-gre-ipv6
> > > > > > >
> > > > > > > Hi Ron,
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net]
> > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM
> > > > > > > > To: int-area@ietf.org; ipv6@ietf.org
> > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L;
> > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org;
> > > > > > > > intarea-chairs@ietf.org
> > > > > > > > Subject: Re: [Int-area] Start of WGLC for
> > > > > > > > draft-ietf-intarea-gre-ipv6
> > > > > > > >
> > > > > > > > Hi Fred,
> > > > > > > >
> > > > > > > >      Inline.....
> > > > > > > >
> > > > > > > >                Ron
> > > > > > > >
> > > > > > > >
> > > > > > > > > Hi Juan Carlos,
> > > > > > > > >
> > > > > > > > > Final passage of Section 3.1 says:
> > > > > > > > >
> > > > > > > > >    ?However, in an alternative configuration, the GRE ingress
> MAY:
> > > > > > > > >
> > > > > > > > >    o  discard the IPv6 packet
> > > > > > > > >
> > > > > > > > >    o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message
> > > > > > > > > to the
> > > > > IPv6
> > > > > > > > >       packet source.  The MTU field in the ICMPv6 PTB message
> is set
> > > to
> > > > > > > > >       the GMTU.?
> > > > > > > > >
> > > > > > > > > This means that there may be circumstances when the GRE
> > > > > > > > > ingress sends a PTB reporting a size less than 1280.
> > > > > > > > > According to RFC2460, Section 5, the standard behavior for a
> > > > > > > > > host that receives
> > > > > such a PTB is:
> > > > > > > > >
> > > > > > > > >    ?In that case, the IPv6 node
> > > > > > > > >   is not required to reduce the size of subsequent packets to
> less
> > > than
> > > > > > > > >    1280, but must include a Fragment header in those packets?
> > > > > > > > >
> > > > > > > > > So, hosts that obey RFC2460 Section 5 will see a perpetual
> > > > > > > > > black hole if the GMTU is smaller than 1280 which is
> > > > > > > > > probably not what we
> > > > > > > want.
> > > > > > > >
> > > > > > > >
> > > > > > > > [RPB]
> > > > > > > > All true. This is why the WG decided to make this the
> > > > > > > > alternative behavior
> > > > > > > and not the default behavior.
> > > > > > >
> > > > > > > Behavior that is broken is still broken regardless of whether it
> > > > > > > is alternative or default.
> > > > > > >
> > > > > > > > > ?draft-templin-6man-linkadapt? attempts to provide guidance
> > > > > > > > > to hosts on how to react to PTB messages that report a small
> size.
> > > > > > > > > But, as of right now,
> > > > > > > > > RFC2460 Section 5 is the normative behavior.
> > > > > > > > [RPB]
> > > > > > > >
> > > > > > > > Absolutely correct. The procedures described in Section 5 or
> > > > > > > > RFC
> > > > > > > > 246 are
> > > > > > > normative.
> > > > > > > >
> > > > > > > > I don't how this impacts the WG's LC decision regarding the
> > > > > > > > current
> > > > > draft.
> > > > > > >
> > > > > > > Broken behavior should not be specified, whether alternative or
> > > default.
> > > > > > >
> > > > > > > Thanks - Fred
> > > > > > > fred.l.templin@boeing.com
> > > > > > >
> > > > > > > >
> > > > > > > > Ron
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks ? Fred
> > > > > > > > > fred.l.templin@boeing.com
> > > > > > > > >
> > > > > > > >
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area