IETF Logo Mail Archive

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 15:38 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF7B11E81A0; Wed, 9 Oct 2013 08:38:34 -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 4jQkWYCyevaE; Wed, 9 Oct 2013 08:38:25 -0700 (PDT)
Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 807FD11E81AC; Wed, 9 Oct 2013 08:38:17 -0700 (PDT)
Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r99FcGCu028861; Wed, 9 Oct 2013 08:38:16 -0700
Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r99FcEUr028393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 9 Oct 2013 08:38:15 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.168]) with mapi id 14.02.0328.011; Wed, 9 Oct 2013 08:38:14 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Ronald Bonica <rbonica@juniper.net>, 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: AQHOv6KsVHjrcZv7kkeUppI3Iq7lo5nlBPWAgASNmgCAAXGqAIAAjlqggAD4aZA=
Date: Wed, 09 Oct 2013 15:38:14 +0000
Message-ID: <2134F8430051B64F815C691A62D9831811EB23@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>
In-Reply-To: <9e33a47bb2834c15ba4269ae8c79c46f@BLUPR05MB433.namprd05.prod.outlook.com>
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: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Oct 2013 15:38:34 -0000

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

Thanks - Fred
fred.l.templin@boeing.com
 
>        Ron
> 
> > -----Original Message-----
> > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf
> Of
> > Ole Troan
> > Sent: Tuesday, October 08, 2013 12:17 PM
> > To: Templin, Fred L
> > Cc: ipv6@ietf.org; ietf@ietf.org; IETF-Announce
> > Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-
> 08.txt>
> > (Implications of Oversized IPv6 Header Chains) to Proposed Standard
> >
> > Fred,
> >
> > > Hi, I would like to make a small amendment to what I said in my
> > > previous message as follows:
> > >
> > > 4) Section 5, change the final paragraph to:
> > >
> > >   "As a result of the above mentioned requirements, a packet's
> header
> > >   chain length MUST fit within the Path MTU associated with its
> > >   destination.  Hosts MAY discover the Path MTU, using procedures
> > such
> > >   as those defined in [RFC1981] and [RFC4821]. However, if a host
> > does
> > >   not discover the Path MTU, it MUST assume the IPv6 minumum MTU of
> > >   1280 bytes [RFC2460]. The host MUST then limit each packet's
> header
> > >   chain length to the Path MTU minus 256 bytes in case additional
> > >   encapsulation headers are inserted by tunnels on the path."
> >
> > I would claim that additional encapsulation headers are already
> > considered in the 1280 minimum MTU.
> > as in: 1500 - 1280.
> >
> > cheers,
> > Ole
>

v2.35.0 | Report a Bug | By Email | System Status