Subject: 6MAN Minutes, Actions, and Document Status

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Apr 2012 13:57:21 -0700

The minutes are available at:

  http://www.ietf.org/proceedings/83/minutes/minutes-83-6man.txt

At the end of the 6MAN session at the Paris IETF the chairs believe the following actions are forthcoming: 

 Ready for Working Group Last Call:

	draft-ietf-6man-rfc3484bis

	draft-ietf-6man-lineid

        draft-ietf-6man-dad-proxy

	draft-ietf-6man-udpchecksum

	draft-ietf-6man-udpzero

	draft-ietf-6man-ipv6-atomic-fragments
	
 Ready for Working Group call for adoption as a w.g. document

	draft-gont-6man-stable-privacy-addresses

	draft-gont-6man-nd-extension-headers

Given the number of actions, we think it would be inappropriate to send them all at once. We plan to send them out in small batches.  Once we see the discussion slow down, we will start the next batch.  This should strike a reasonable balance at getting them done, not overwhelming the working group, and giving each document a reasonable review.

Other w.g. documents that are not ready for any actions are listed below.

Please let us know if we missed anything.

Bob and Ole

---------------

draft-ietf-6man-addr-select-considerations
	On hold; pending 3484bis
draft-ietf-6man-addr-select-opt
	On hold; pending 3484bis
draft-ietf-6man-rfc3484-revise
	On hold; pending 3484bis

draft-ietf-6man-uri-zoneid
	Passed WGLC (2012-03-19).

draft-ietf-6man-6lobac
	On hold; pending other SDO work

draft-ietf-6man-impatient-nud
	Awaiting new revision

draft-ietf-6man-enhanced-dad
	Recently published as w.g. draft

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Apr 2012 07:38:30 +0200

Hi, Bob,

Some comments inline...

>   http://www.ietf.org/proceedings/83/minutes/minutes-83-6man.txt

Some errata for the minutes:

The current text says:
---- cut here ----
Ole asked about how this was different from an unknown L4 header?

<No answer>
---- cut here ----

There was an answer, so "<no answer>" should probably be replaced with
something along the lines of "Fernando notes that having an unknown
extension header means that you have enough information to apply a
filtering policy, whereas if the full IPv6 header chain is missing, you
don't have the necessary information to do it".

> draft-gont-6man-nd-extension-headers

I think that draft-gont-6man-predictable-fragment-id is also ready for
wg call for adoption as wg document -- I've rev'ed the document since
IETF 83 in response to the feedback received during my presentation
(i.e., just require the Frag ID to be unpredictable, without mandating
any particular algorithm).

draft-gont-6man-oversized-header-chain is probably ready for wg call for
adoption: I've rev the document in response to feedback during my
presentation at IETF 83 -- but I will check with Dave Thaler and Eric if
they think the updated text is fine, or whether it needs some further
tweaking.

Thanks!

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

---

From: Ole Trøan <[email-masked]>
Date: Thu, 26 Apr 2012 13:50:55 +0200

Fernando,

[...]

> don't have the necessary information to do it".

thank you, I have updated the minutes.

[...]

> any particular algorithm).

the chairs have an action item on taking this to the mailing list.
there was an issue that I believe Bob raised, if we were going to have publish RFCs on every field in TCP/IP protocols that should have unpredictable values, or if we should have a generic recommendation applying to protocol design in general.

> they think the updated text is fine, or whether it needs some further

please do.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Apr 2012 17:53:28 -0300

Hi, Ole,

On 04/26/2012 08:50 AM, Ole Trøan wrote:
>> I think that draft-gont-6man-predictable-fragment-id is also ready 
>> for wg call for adoption as wg document -- I've rev'ed the
>> document since IETF 83 in response to the feedback received during
>> my presentation (i.e., just require the Frag ID to be
>> unpredictable, without mandating any particular algorithm).
> 
> there was an issue that I believe Bob raised, if we were going to 
> have publish RFCs on every field in TCP/IP protocols that should
> have unpredictable values, or if we should have a generic
> recommendation applying to protocol design in general.

I believe that a generic document about protocol design that discusses
this issue would be valuable, such that *new* protocols and protocol
implementations do not incur into this problem. However, in this
particular case (Fragment ID), the IPv6 standard itself is suggesting
to use a counter, and hence the spec should be fixed.

That aside, different fields have different requirements. For example,
the constraints for randomizing the transport protocol ports are
different from those of producing unpredictable IDs, and different from
those of say, randomizing the TCP sequence numbers, or randomizing the
IPv6 Flow Label. The consequences of the particular approach that you
follow vary quite a bit in each case.

Thanks,

---

From: Ole Trøan <[email-masked]>
Date: Fri, 27 Apr 2012 10:21:47 +0200

working group,

[changed subject]

in the context of http://tools.ietf.org/html/draft-gont-6man-predictable-fragment-id-02
any opinion on how to proceed?

- document covering predictable values in IETF protocols in general
- document predictable IP ID fields in both IPv4 and IPv6
- fix the predictable fragment ID problem in IPv6
- do nothing?

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Apr 2012 00:20:05 -0300

Hi, Ole,

> - document covering predictable values in IETF protocols in general

I don't think such a document could formally update in protocol that
should be using unpredictable IDs, since the contraints are different
for each protocol.

> - document predictable IP ID fields in both IPv4 and IPv6

This one *could* make sense, however, the constraints are somewhat
different, and procedurally-wise, it may be simpler to work on this I-D
here, than having an I-D that spans 6man and intarea wg(?).

> - fix the predictable fragment ID problem in IPv6

I'd obviously go with this one.

> - do nothing?

Hopefully not -- if we don't fix this, who would do it? -- Even vendors
have been responsive to this I-D, so one would expect that we do
something about it.

Thanks!

Best regards,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 28 Apr 2012 16:28:31 -0400

It seems to me that the proposed document is a partial fix to a marginal 
problem.
Yes, I take it as given that if I followed the references I wind find 
descriptions of the attacks.  I do see how one could force fragmented 
packets if one knew that A was talking to B at the current moment.

However, it seems to me that in the vast majority of cases, if the 
attacker knows that A is talking to B, he can probably observe the 
packets between A and B (and it must be a conversation of many round 
trips to allow for observation, triggered behavior, and useful attack.) 
  As such, none of the specified solutions would seem to help much.

Hence, I am left concluding that the right answer is not to publish any 
recommendations in this space.

Yours,
Joel

On 4/27/2012 4:21 AM, Ole Trøan wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Apr 2012 17:49:46 -0300

> packets if one knew that A was talking to B at the current moment.

Just send an ICMPv6 PTB claiming an MTU smaller than 1280 bytes, and
you're done.

Now think about you favourite application running on two known systems.
It just takes you one ICMPv6 PTB to trigger fragmentation, one ping6 to
sample the Frag ID, and further (rather low-rate) fragments that will
cause collisions, leading to DoS -- and it si very easy to maintaint
that DoS state.

Dumb/idle scans have also been well-known since the IPv4 era, and
trivial to exploit (for instance, nmap implements this vector).

We produced tools to test these things, and have been trying to help
vendors. Most vendors cared
(http://www.ietf.org/proceedings/83/slides/slides-83-6man-10.pdf), as
they did at the time for IPv4 case.

So IMO it would be weird for us to not be willing to do our part
(maintain our specs), when others have done theirs (fix their
implementations).

Just my two cents.

Best regards,