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 23:13 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 DAE5421E81F2; Wed, 9 Oct 2013 16:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.335
X-Spam-Level:
X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 dJFQgSs59KA4; Wed, 9 Oct 2013 16:13:19 -0700 (PDT)
Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 227D121E81ED; Wed, 9 Oct 2013 16:13:14 -0700 (PDT)
Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r99NDDWV009348; Wed, 9 Oct 2013 16:13:13 -0700
Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r99NDCkY009345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 9 Oct 2013 16:13:12 -0700
Received: from XCH-BLV-301.nw.nos.boeing.com (130.247.25.213) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 9 Oct 2013 16:13:11 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-301.nw.nos.boeing.com ([169.254.1.180]) with mapi id 14.02.0328.011; Wed, 9 Oct 2013 16:13:11 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
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: AQHOxT3pVHjrcZv7kkeUppI3Iq7lo5ns+Qtg
Date: Wed, 09 Oct 2013 23:13:11 +0000
Message-ID: <2134F8430051B64F815C691A62D9831811F688@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> <2134F8430051B64F815C691A62D9831811EF1C@XCH-BLV-504.nw.nos.boeing.com> <5255D6EE.4050300@gmail.com>
In-Reply-To: <5255D6EE.4050300@gmail.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="utf-8"
Content-Transfer-Encoding: base64
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 23:13:34 -0000
Hi Brian, Responding in a slightly re-arranged order: > The problem is that you are asserting that middleboxes that a tunnel > passes through are expected to examine the complete header chain of > the encapsulated packet even if the encapsulated packet is a fragment. Yes, but change "are expected to" to "should be able to". > I think that's an unreasonable expectation. A reasonable expectation > is that middleboxes should identify the encapsulated packet as > a payload that they cannot analyse, and let it go (unless they > have a policy setting to drop tunnelled packets, which is a > different discussion). But why? If headers beyond the first IPv6 encapsulation header are available in the clear, the middlebox should be able to parse them if it wants to. Wireshark already does exactly that - it keeps on parsing beyond the first encapsulation header up to and including the true ULP header. And, if Wireshark can do it, so can any other middlebox that believes security would be improved by continuing to parse the entire chain - whether or not there is a standard saying it must not do so. Parsing the additional headers beyond the first encapsulation header provides defense-in-depth. Perimeter middleboxes can then weed out the bad stuff without either allowing the bad stuff to penetrate more deeply into the organization or dropping good stuff that should be allowed through. > Since the problem recurses as we tunnel tunnels, I don't see how any > finite limit can solve the problem. 1280 itself is a pragmatic choice > of "a bit shorter than 1500". The 1280 is assuming that all links in the path have a 1500 MTU and so RFC2460 allowed (1500 - 1280) = 220 bytes for additional IPv6 headers added by nested tunnels without incurring fragmentation. I am asserting instead that we have to allow for paths that include links with a 1280 MTU and so tunnels will have to fragment over such paths. That means that the first fragmenting tunnel would have room for 1240 in the first fragment, the second fragmenting tunnel would have room for 1200 in the first fragment, etc. That is why I would prefer that hosts limit the size of their header chains to 1024; so that nested tunnels that fragment will still be highly likely to have the entire header chain in the first fragment. > I understood that to be the basis on which the WG reached consensus. Maybe the WG didn't understand that such a consensus would make tunnels less reliable and less secure. Thanks - Fred fred.l.templin@boeing.com > Brian
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Ole Troan
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Fernando Gont
- RE: Last Call: <draft-ietf-6man-oversized-header-… Ronald Bonica
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Ole Troan
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Ole Troan
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Brian E Carpenter
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Fernando Gont
- Re: RE: Last Call: <draft-ietf-6man-oversized-hea… Ray Hunter
- RE: RE: Last Call: <draft-ietf-6man-oversized-hea… Templin, Fred L
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Fernando Gont
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Brian E Carpenter
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Brian E Carpenter
- RE: Last Call: <draft-ietf-6man-oversized-header-… Ronald Bonica
- Re: Last Call: <draft-ietf-6man-oversized-header-… SM
- RE: Last Call: <draft-ietf-6man-oversized-header-… Ronald Bonica
- Re: Last Call: <draft-ietf-6man-oversized-header-… Ray Hunter
- RE: Last Call: <draft-ietf-6man-oversized-header-… SM
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- RE: Last Call: <draft-ietf-6man-oversized-header-… Ronald Bonica
- Re: Last Call: <draft-ietf-6man-oversized-header-… Brian E Carpenter
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Masataka Ohta
- Re: Last Call: <draft-ietf-6man-oversized-header-… Masataka Ohta
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Ray Hunter
- Re: Last Call: <draft-ietf-6man-oversized-header-… Ray Hunter
- Re: Last Call: <draft-ietf-6man-oversized-header-… Fernando Gont
- Re: Last Call: <draft-ietf-6man-oversized-header-… Fernando Gont
- Re: Last Call: <draft-ietf-6man-oversized-header-… Fernando Gont
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Ole Troan
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Fernando Gont
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Fernando Gont
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-oversized-header-… Fernando Gont
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L
- RE: Last Call: <draft-ietf-6man-oversized-header-… Templin, Fred L