Subject: [v6ops] Deprecating the Generation of IPv6 Atomic Fragments (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-00.txt)

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 11:50:26 -0300

Folks,

FYI, this is
<http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt>
our Std-track "patch" to fix this:
<http://www.ietf.org/mail-archive/web/v6ops/current/msg19746.html>

Comments welcome ;-)

Thanks!
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-6man-deprecate-atomfrag-generation-00.txt
Date: Tue, 19 Aug 2014 07:47:03 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, Will(Shucheng) Liu
<[email-masked]>, Fernando Gont <[email-masked]>,
Shucheng LIU (Will) <[email-masked]>

A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-deprecate-atomfrag-generation
Revision:	00
Title:		Deprecating the Generation of IPv6 Atomic Fragments
Document date:	2014-08-19
Group:		Individual Submission
Pages:		7
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00

Abstract:
   The core IPv6 specification requires that when a host receives an
   ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
   than 1280, the host includes a Fragment Header in all subsequent
   packets sent to that destination, without reducing the assumed Path-
   MTU.  The simplicity with which ICMPv6 "Packet Too Big" messages can
   be forged, coupled with the widespread filtering of IPv6 fragments,
   results in an attack vector that can be leveraged for Denial of
   Service purposes.  This document briefly discusses the aforementioned
   attack vector, and formally deprecates the generation of IPv6 atomic
   fragments, such that the aforementioned attack vector is eliminated.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Antonios Atlasis <[email-masked]>
Date: Tue, 19 Aug 2014 18:14:43 +0300

Hi,

regarding the second paragraph of section 5, I thought that the fragment
ID, included both in the IPv6 atomic fragments (the half of the ID
actually) and in the IPv4 header was necessary to track the end-to-end
connection. If a fragment ID is used only in the IPv4 part of the
end-to-end path, how does IPv6-to-IPv4 translation node is going to track
the end-to-end connection? Unless I miss sthg here.

Best

Antonios

2014-08-19 17:50 GMT+03:00 Fernando Gont <[email-masked]>:

> <
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA