FW: [OPS-DIR] Ops Dir review: draft-ietf-6man-overlap-fragment-03
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 27 October 2009 12:32 UTC
Return-Path: <dromasca@avaya.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23B028C187 for <ipv6@core3.amsl.com>; Tue, 27 Oct 2009 05:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.408
X-Spam-Level:
X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iweSL-jgnWWj for <ipv6@core3.amsl.com>; Tue, 27 Oct 2009 05:32:28 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 8806928C118 for <ipv6@ietf.org>; Tue, 27 Oct 2009 05:32:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,633,1249272000"; d="scan'208";a="161467560"
Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Oct 2009 08:32:40 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 27 Oct 2009 08:32:39 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: FW: [OPS-DIR] Ops Dir review: draft-ietf-6man-overlap-fragment-03
Date: Tue, 27 Oct 2009 13:32:28 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401B4C68E@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPS-DIR] Ops Dir review: draft-ietf-6man-overlap-fragment-03
Thread-Index: AcpWvagLXBB7ic5ESbSghFPyDSYpjgAQ6OkQ
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: ipv6@ietf.org
Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 27 Oct 2009 12:32:29 -0000
-----Original Message----- From: ops-dir-bounces@ietf.org [mailto:ops-dir-bounces@ietf.org] On Behalf Of Nevil Brownlee Sent: Tuesday, October 27, 2009 6:26 AM To: suresh.krishnan@ericsson.com; ops-dir@ietf.org Subject: [OPS-DIR] Ops Dir review: draft-ietf-6man-overlap-fragment-03 Hi, I have performed an Operations directorate review of draft-ietf-6man-overlap-fragment-03, Handling of overlapping IPv6 fragments This draft points out that IPv6 fragments can overlap, allowing an attacker to get through firewalls that only look at the first packet in a TCP connection. It proposes to change the IPv6 specification (RFC 2460) to forbid overlapping fragments, thus fixinf this security problem. -- 1. Is the specification complete? Can multiple interoperable implementations be built based on the specification? Yes 2. Is the proposed specification deployable? If not, how could it be improved? Yes 3. Does the proposed approach have any scaling issues that could affect usability for large scale operation? None that I can see. Although fragmentation is much less used than it used to be, it's probably still neccessary. 4. Are there any backward compatibility issues? No. This change would simply fix a protocol vulnerability. 5. Do you anticipate any manageability issues with the specification? No. 6. Does the specification introduce new potential security risks or avenues for fraud? No. Now, for something completely different, a question: In IPv4 (RFC 791), Fragment Offset is relative to the original unfragmentsed packet (Stevens, TCP/IP Illustrated). RFC 1858, when describing the 'tiny fragment' attack, uses Fragment Offset 1. But that would point at IP header byte 8! Seems to me that the smallest usable value of Fragment Offset is 3, pointing to byte 24, i.e. just past the shortest IPv4 header. Does this seem to you like an error in RFC 1858? IPv6 (RFC 2460) has the notion of 'Unfragmentable Part,' i.e. v6 Header + sub-headers, and its Fragment Offset field is relative to the Fragmentable Part - so Fragment Offsets 0 and 1 are allowed. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
- FW: [OPS-DIR] Ops Dir review: draft-ietf-6man-ove… Romascanu, Dan (Dan)
- Re: FW: [OPS-DIR] Ops Dir review: draft-ietf-6man… Suresh Krishnan