Subject: New revision of draft-gont-6man-flowlabel-security

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Jan 2012 10:22:22 -0300

Folks,

I have just posted a revision of the aforementioned I-D. It is available
at: <http://tools.ietf.org/id/draft-gont-6man-flowlabel-security-02.txt>

Any comments will be appreciated.

Thanks!

Best regards,
Fernando

-------- Original Message --------
Subject: New Version Notification for
draft-gont-6man-flowlabel-security-02.txt
Date: Fri, 13 Jan 2012 05:02:38 -0800
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A new version of I-D, draft-gont-6man-flowlabel-security-02.txt has been
successfully submitted by Fernando Gont and posted to the IETF repository.

Filename:	 draft-gont-6man-flowlabel-security
Revision:	 02
Title:		 Security Assessment of the IPv6 Flow Label
Creation date:	 2012-01-12
WG ID:		 Individual Submission
Number of pages: 20

Abstract:
   This document discusses the security implications of the IPv6 &quot;Flow
   Label&quot; header field, and analyzes possible schemes for selecting the
   Flow Label value of IPv6 packets.

The IETF Secretariat

---

From: Florian Weimer <[email-masked]>
Date: Fri, 27 Jan 2012 10:49:44 +0000

> Any comments will be appreciated.

Destination-specific counters introduce state keeping requirements and
concurrency bottlenecks.  Are those really necessary?

I would like to see actual use of the flow label field which doesn't
suffer from denial of service issues (by creating many flows with the
same label, undermining things like label-based load distribution) or
traffic parasitism.  Furthermore, RFC 6437 allows modification of the
flow label header in transit, so I really doubt that there are any such
applications.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Jan 2012 09:09:13 -0300

> concurrency bottlenecks.  Are those really necessary?

There are no "destination-specific" counters. Just a global counter, or
a set of counters (for the double-hash algorithm).

> same label, 

Well, *this* is no different from doing load-sharing based on the
five-tuple (protocop, src ip, srp port, dst ip, dst port).

> undermining things like label-based load distribution) or

There's no checksum on the Flow Label, and it's not even protected by
IPsec, so... how could RFC6437 possibly "forbid modification of the flow
label"? (other than "nodes MUST NOT modify the FL....Good *luck*, btw!")

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492