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, 16 October 2013 15:45 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 4347A11E8318; Wed, 16 Oct 2013 08:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.507
X-Spam-Level:
X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 NSNxkJotu5im; Wed, 16 Oct 2013 08:45:29 -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 D414F11E82B3; Wed, 16 Oct 2013 08:45:29 -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 r9GFjL75011680; Wed, 16 Oct 2013 08:45:22 -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 r9GFjJtO011633 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 16 Oct 2013 08:45:19 -0700
Received: from XCH-BLV-208.nw.nos.boeing.com (10.57.37.5) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 16 Oct 2013 08:45:09 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.85]) by XCH-BLV-208.nw.nos.boeing.com ([169.254.8.27]) with mapi id 14.03.0158.001; Wed, 16 Oct 2013 08:45:08 -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: AQHOyoRrebc9KTehbEGO6mhunuAlj5n3duEg
Date: Wed, 16 Oct 2013 15:45:07 +0000
Message-ID: <2134F8430051B64F815C691A62D9831812F69E@XCH-BLV-504.nw.nos.boeing.com>
References: <20131002185522.20697.96027.idtracker@ietfa.amsl.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> <2134F8430051B64F815C691A62D9831811F688@XCH-BLV-504.nw.nos.boeing.com> <5257AD5E.9090806@globis.net> <5257B870.1060003@si6networks.com> <2134F8430051B64F815C691A62D9831812C120@XCH-BLV-504.nw.nos.boeing.com> <52582F8B.8040306@si6networks.com> <52585658.50205@gmail.com> <2134F8430051B64F815C691A62D9831812C654@XCH-BLV-504.nw.nos.boeing.com> <52587EB8.4020506@gmail.com> <f0df0113f68045a1bdadf0155eae5e34@CO1PR05MB442.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D9831812D72D@XCH-BLV-504.nw.nos.boeing.com> <525DD007.8030100@si6networks.com> <2134F8430051B64F815C691A6! 2D9831812 F4CA@XCH-BLV-504.nw.nos.boeing.com> <57E5A58E-0DAF-4545-8580-ACDB59475F46@employees.org>
In-Reply-To: <57E5A58E-0DAF-4545-8580-ACDB59475F46@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: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, 6man Mailing List <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Ray Hunter <v6ops@globis.net>, Fernando Gont <fgont@si6networks.com>
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, 16 Oct 2013 15:45:38 -0000

Hi Ole,

> -----Original Message-----
> From: Ole Troan [mailto:otroan@employees.org]
> Sent: Wednesday, October 16, 2013 8:29 AM
> To: Templin, Fred L
> Cc: Fernando Gont; Ronald Bonica; Brian E Carpenter; 6man-
> chairs@tools.ietf.org; Ray Hunter; 6man Mailing List; 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,
> 
> > To repeat what has already been said many times (and hopefully for
> > just one final time), if the host is permitted to include an MTU-
> sized
> > header chain and if there is a tunnel on the path that needs to
> fragment
> > for whatever reason, then that header chain is going to spill into a
> > second fragment. Then, middleboxes that wish to examine the entire
> > header chain in the first fragment for whatever reason will be unable
> > to do so. Consensus or no, those are the facts.
> 
> absolutely.
> 
> the outer IPv6 header is a new datalink for the inner IPv6 header.
> there is no architectural difference if that L2 is IPv6, IPv4 or PPP.
> take IPv4 or PPP as an example, if PPP provides fragmentation, then
> there is no expectation that the PPP or IPv4 layer keeps the payload
> IPv6 header chain in one PPP or IPv4 fragment.
> 
> the rules in this document are not recursive. the header chain
> terminates as soon as another IPv6 header is encountered.

I disagree with the header chain terminating as soon as another IPv6
header is encounter. That defeats defense-in-depth, since outer
perimeter middleboxes would be forced to admit packets with unexamined
header chains inward to inner perimeter middleboxes. And, if the
unexamined header chains contain bad stuff inserted by an attacker,
the attack is successful.

That requirement is also not observed by common middlebox systems
such as Wireshark and tcpdump. Both will blast past encapsulating
IPv6 headers through to the header chain inserted by the original
host without stopping at the outermost IPv6 header.

Thanks - Fred
fred.l.templin@boeing.com
 
> does that clarification help?
> I'm not quite sure if the document is clear enough on this point.
> 
> Best regards,
> Ole

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