[LACNIC/Seguridad] Fwd: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)

Mie Ago 27 15:04:53 BRT 2014

Estimados,

Revision del I-D que intenta eliminar las vulnerabilidades basadas en
mensajes de error ICMP que publiqué el otro dia:
<http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt>

(debajo encontraan mas detalles)

Cualquier tipo de feedback será bienvenido.

Saludos cordiales, y gracias!
Fernando

-------- Forwarded Message --------
Subject: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New
Version Notification for
draft-gont-6man-deprecate-atomfrag-generation-01.txt)
Date: Wed, 27 Aug 2014 15:01:43 -0300
From: Fernando Gont <fernando en gont.com.ar>
To: 6man en ietf.org <6man en ietf.org>

Folks,

We have published a revision of the aforementioned document:
<http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt>

I'll try to summarize the changes incorporated in this version:

* Section 1 and Section 2 have been augmented to better explain the
rationale for the proposed update -- not just interms of the security
vulnerability being discussed, but also in terms of protocol robustness.

* We have relaxed the update to RFC2460, noting that ICMP PTB<1280
should not elicit atom frags (rather than "these packets should be
dropped"), as suggested by Bob Briscoe

* We have clarified the rationale for relying on IPv6 atom frags as part
of the SIIT design decision.

* We have incorporated an Appendix with a small and non-exhaustive
survey which shows that quite a few widely deployed OSes fail to
generate IPv6 atomic fragments in response to ICMPv6 PTB<1280.

* We have clarified why you cannot simply check the IPv6 Source Address
representing IPv4 nodes as a general mitigation to the vulnerability
discussed in this document. -- this is based on the thread with Tatuya
Jinmei.

* We have included (in Section 6) a formal update to RFC6145, as
suggested by Brian Carpenter. If the working group decides to take on
this document, a second-order decision might be whether to update RFC
2460 and RFC6145 in this doc, or just focus on atom frag generation
here, and do a complete RFC6145bis in a separate document. The whole
Section 6 is mostly meant as "this is what one should patch in RFC6145
such that it does not rely on IPv6 atomic fragments". However, we note
that the core of this document is really all Sections other than Section
6, since those are the ones providing the rationale for deprecating the
generation of IPv6 atomic fragments.

Please do let us know if we have missed anything, if there's anything
that needs further clarification, or if you like the I-D as is.

Thanks so much!
Fernando (and co-authors)

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-6man-deprecate-atomfrag-generation-01.txt
Date: Wed, 27 Aug 2014 10:43:04 -0700
From: internet-drafts en ietf.org
To: Will(Shucheng) Liu <liushucheng en huawei.com>, Shucheng LIU (Will)
<liushucheng en huawei.com>, Tore Anderson <tore en redpill-linpro.com>, Tore
Anderson <tore en redpill-linpro.com>, Fernando Gont
<fgont en si6networks.com>, Fernando Gont <fgont en si6networks.com>

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

Name:		draft-gont-6man-deprecate-atomfrag-generation
Revision:	01
Title:		Deprecating the Generation of IPv6 Atomic Fragments
Document date:	2014-08-27
Group:		Individual Submission
Pages:		17
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.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-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-6man-deprecate-atomfrag-generation-01

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 updates RFC2460 such that generation of
   IPv6 atomic fragments is deprecated, thus eliminating the
   aforementioned attack vector.  Additionally, it formally updates
   RFC6145 such that the Stateless IP/ICMP Translation Algorithm (SIIT)
   does not rely on the generation of IPv6 atomic fragments, thus
   improving the robustness of the protocol.

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

-- 
Fernando Gont
e-mail: fernando en gont.com.ar || fgont en si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

-- 
Fernando Gont
e-mail: fernando en gont.com.ar || fgont en si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1