RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 09 October 2013 17:43 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F17C21E814A; Wed, 9 Oct 2013 10:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZVczlVSfcOd; Wed, 9 Oct 2013 10:42:59 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id E290C21E8151; Wed, 9 Oct 2013 10:42:58 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r99HgujR023300; Wed, 9 Oct 2013 12:42:56 -0500
Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r99HgtaJ023293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 9 Oct 2013 12:42:56 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.8]) with mapi id 14.02.0328.011; Wed, 9 Oct 2013 10:42:55 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Ole Troan <otroan@employees.org>
Subject: RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Thread-Topic: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Thread-Index: AQHOxRVXebc9KTehbEGO6mhunuAlj5nsok8A
Date: Wed, 09 Oct 2013 17:42:54 +0000
Message-ID: <2134F8430051B64F815C691A62D9831811EF1C@XCH-BLV-504.nw.nos.boeing.com>
References: <20131002185522.20697.96027.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831811AEFC@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831811BDD3@XCH-BLV-504.nw.nos.boeing.com> <9300F272-E282-41C3-9DA8-59134B975FC7@employees.org> <9e33a47bb2834c15ba4269ae8c79c46f@BLUPR05MB433.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D9831811EB23@XCH-BLV-504.nw.nos.boeing.com> <D1F5CE61-253E-4F07-AED1-4A4AB4C4AB68@employees.org> <2134F8430051B64F815C691A62D9831811EE66@XCH-BLV-504.nw.nos.boeing.com> <E29381FD-C839-4DBA-8711-3A4EBA83E379@employees.org>
In-Reply-To: <E29381FD-C839-4DBA-8711-3A4EBA83E379@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Oct 2013 17:43:05 -0000

Hi Ole,

> -----Original Message-----
> From: Ole Troan [mailto:otroan@employees.org]
> Sent: Wednesday, October 09, 2013 10:31 AM
> To: Templin, Fred L
> Cc: Ronald Bonica; ipv6@ietf.org; ietf@ietf.org
> Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
> 
> Fred,
> 
> >>>> -----Original Message-----
> >>>> From: Ronald Bonica [mailto:rbonica@juniper.net]
> >>>> Sent: Tuesday, October 08, 2013 5:46 PM
> >>>> To: Ole Troan; Templin, Fred L
> >>>> Cc: ipv6@ietf.org; ietf@ietf.org
> >>>> Subject: RE: Last Call: <draft-ietf-6man-oversized-header-chain-
> >> 08.txt>
> >>>> (Implications of Oversized IPv6 Header Chains) to Proposed
> Standard
> >>>>
> >>>> I agree with Ole.
> >>>
> >>> How so? A tunnel that crosses a 1280 MTU link MUST fragment
> >>> in order to satisfy the IPv6 minMTU. If it must fragment, then
> >>> an MTU-length IPv6 header chain would not fit within the first
> >>> fragment, and we have opened an attack vector against tunnels.
> >>> This is not a matter to be agreed or disagreed with - it is
> >>> a simple fact.
> >>
> >> right, and RFC2460 has this to say about it:
> >>
> >>   IPv6 requires that every link in the internet have an MTU of 1280
> >>   octets or greater.  On any link that cannot convey a 1280-octet
> >>   packet in one piece, link-specific fragmentation and reassembly
> must
> >>   be provided at a layer below IPv6.
> >
> > Very true. In this case, the "link" is the tunnel and the "link-
> specific
> > fragmentation" is IPv6 fragmentation. Which places the first part of
> an
> > MTU-length IPv6 header chain in the first fragment and the remainder
> of
> > the header chain in the second fragment.
> 
> indeed. which would violate the MUST in oversized-header-chain.
> 
> what do we do?
> a) ignore this particular corner case
> b) suggest the tunnel head end to drop the packet
> c) develop a new tunnel segmentations scheme that doesn't depend on
> IPv6 fragmentation. :-)

You know I have an interest in alternative c), but that does not
address the issue of splitting the header chain across multiple
fragments. So, my choice is:

d) limit the size of the IPv6 header chain so that the chain will
fit within the first fragment by having the host limit the chain
to the MTU size minus 256 bytes.

Actually, I would be even happier if we just asked the host to limit
the size of the header chain to 1024 bytes regardless of the path MTU.

Thanks - Fred
fred.l.templin@boeing.com

> cheers,
> Ole