IETF Logo Mail Archive

Re: FW: [OPS-DIR] Ops Dir review: draft-ietf-6man-overlap-fragment-03

Suresh Krishnan <suresh.krishnan@ericsson.com> Mon, 02 November 2009 21:38 UTC

Return-Path: <suresh.krishnan@ericsson.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 D886B28C0F4 for <ipv6@core3.amsl.com>; Mon, 2 Nov 2009 13:38:51 -0800 (PST)
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4khVbQ6g9M0p for <ipv6@core3.amsl.com>; Mon, 2 Nov 2009 13:38:51 -0800 (PST)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B6C803A6768 for <ipv6@ietf.org>; Mon, 2 Nov 2009 13:38:50 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nA2LcuCd031254; Mon, 2 Nov 2009 15:38:57 -0600
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 15:37:56 -0600
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 15:37:56 -0600
Received: from [142.133.10.113] (147.117.20.212) by eusaamw0706.eamcs.ericsson.se (147.117.20.91) with Microsoft SMTP Server id 8.1.375.2; Mon, 2 Nov 2009 16:37:55 -0500
Message-ID: <4AEF5100.1070401@ericsson.com>
Date: Mon, 02 Nov 2009 16:37:04 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Subject: Re: FW: [OPS-DIR] Ops Dir review: draft-ietf-6man-overlap-fragment-03
References: <EDC652A26FB23C4EB6384A4584434A0401B4C68E@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0401B4C68E@307622ANEX5.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Nov 2009 21:37:56.0311 (UTC) FILETIME=[BD8B0670:01CA5C04]
Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>, "ipv6@ietf.org" <ipv6@ietf.org>
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: Mon, 02 Nov 2009 21:38:51 -0000

Hi Nevil,
   Thanks for the comment. Please see response inline.

On 09-10-27 08:32 AM, Romascanu, Dan (Dan) wrote:
>  
> 
> -----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.

The fragment offset describes the offset into the DATA part of the 
datagram. Thus, the TCP header would begin at offset 0 and not offset 3.

> 
> Does this seem to you like an error in RFC 1858?

Not really. I think the RFC1858 definition is correct in this matter.

Thanks
Suresh

v2.23.0 | Report a Bug | By Email