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