Subject: TSVART review of draft-ietf-6man-deprecate-atomfrag-generation

From: Joe Touch <[email-masked]>
Date: Fri, 26 Aug 2016 12:29:39 -0700

Hi, all,

I've reviewed this document as part of the Transport Area Review Team's
(TSVART) ongoing effort to review key IETF documents. These comments
were written primarily for the transport area directors, but are copied
to the document's authors for their information and to allow them to
address any issues raised. When done at the time of IETF Last Call, the
authors should consider this review together with any other last-call
comments they receive. Please always CC ​[email-masked]
<mailto:[email-masked]> if you reply to or forward this review.

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-6man-deprecate-atomfrag-generation 
Title: Generation of IPv6 Atomic Fragments Considered Harmful
Reviewer: J. Touch
Review Date: August 26, 2016
IETF Last Call Date: August 8, 2016

Summary: This draft is on the right track but has open issues, described
in the review.

The document has no issues directly applicable to transport protocols.
The impact on transports is indirect, in the ability of RFC 6145-style
IPv6/IPv4 translators to support IPv6-to-IPv4 translation and deal with
IPv4-side fragmentation.

However, there are some important non-transport issues that are noted below.

Major issues:

The impact of this change does not appear to have been explored. Section
3 ends with a claim that links where this translation issue would be a
problem are rare, but there is no evidence presented as to whether
current RFC 6145 translators would be capable of complying with the
changes in this doc, e.g., to be able to generate IPv4 IDs as needed.
I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4
ID generation MUST be supported (and used), rather than MAY.

The document concludes that the translator should create IPv4 IDs rather
than relying on atomic fragments as a source of that information (as per
RFC2460) because there is no benefit, but are two reasons why this
method is directly hazardous as well: 1) RFC 2460 does not require that
the IPv6 ID field is generated to ensure that the low 16-bits are unique
as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145
translation could result in collisions where two distinct IPv6
destinations are translated into the same IPv4 address, such that IDs
that might have been generated to be unique in the IPv6 context could
end up colliding when used in the translated IPv4 context. I.e., this
does not require ECMP as implied in Section 3.

Minor issues:

IMO, it remains unwise to continue to imply that networks should treat
packets with fragment headers as an attack. Fragmentation support is
critical to tunneling (see draft-ietf-intarea-tunnels) and we need to
find ways to support their use safely. The text should be edited to
explain that the primary motivation here is to avoid generating
erroneous IPv4 ID fields, rather than to react to the incorrect
classification of fragment headers as incompatible with the Internet.

The claim that links with IPv6 MTUs smaller than 1260 are rare needs to
be supported with evidence. I appreciate that such evidence may be
difficult to observe. In the absence of evidence, the statement should
be more clear that there is no evidence to the contrary -- which is not
the same as being able to claim that they *are* in fact rare.

--

---

From: Fernando Gont <[email-masked]>
Date: Sat, 27 Aug 2016 19:37:40 -0300

Hello, Joe,

Thanks so much for your review! -- Please find my responses in-line...

> ID generation MUST be supported (and used), rather than MAY.

RFC 6145 has been revised as RFC7915.

> does not require ECMP as implied in Section 3.

mmm.. not sure I follow. When we refer to ECMP in Section 3 we're
actually describing the only possible scenario in which relying on the
ID in the Frag Header could be of use (i.e., possibly result in lower
collision rates).

> classification of fragment headers as incompatible with the Internet.

Not sure what you mean.

We're not implying that packets employing FH are an attack. FWIW, I
don't personally think so. We do think that, when employing
fragmentation, you open the door to a number of attack vectors. See
e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt.

> the same as being able to claim that they *are* in fact rare.

I see your point. Any suggestion on how to tweak the text?

Thanks!

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

---

From: Joe Touch <[email-masked]>
Date: Sun, 28 Aug 2016 09:33:54 -0700

Hi, Fernando,

First, I'd like to note something more important about this doc - the
abstract itself argues that this change should update the core IPv6
spec. Given that is already well underway, why is this document even
needed?

That said, see below in-line...

> RFC 6145 has been revised as RFC7915.
The second sentence of this draft cites 6145. You raise a good point,
but given 7915 obsoletes 6145 (rather than updating it), all references
throughout should then refer to 7915 instead.

> ID in the Frag Header could be of use (i.e., possibly result in lower

I'm not speaking of when the ID in the Frag Header can be useful. I'm
speaking of other more likely cases where using the low 16 bits of the
IPv6 ID field can generate IPv4 collisions.

> e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt.
Some of the attacks described are based on the widespread dropping of a
valid IPv6 packet with valid IPv6 extension headers.

IMO, it is important to be clear that this makes users of a legitimate
IPv6 capability vulnerable because of incorrect behavior of routers. It
seems important to remind readers that the real issue here is the
non-compliant routers. If that information isn't present, it implies
that it is the use of the EHs that is incorrect and should be avoided in
general. That's impossible for fragmentation - it is a critical
capability without which tunneling cannot exist.

> I see your point. Any suggestion on how to tweak the text?

It depends on what you know. AFAICT, we have no information on this
issue. If that's the case, then the text should just state the impact on
such links and say that "there is no evidence yet as to the prevalence
of their use".

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Aug 2016 19:05:41 -0300

> spec. Given that is already well underway, why is this document even

The document says it clearly: "documenting the
   motivation for removing this functionality in the revision of the
   core IPv6 protocol specification."

You just don't remove a feature from a spec silently, without a
rationale. And the place to include the rationale wasn't rfc2460bis --
hence this dcument.

> throughout should then refer to 7915 instead.

Not really. We're documenting why this feature is being removed -- hence
there's a place for referencing RFC6145 ("state of affairs before any
updates") and RFC7915.

All references to RFC6145 are of the form "legacy translators", or
"RFC6145 was...".

> IPv6 ID field can generate IPv4 collisions.

So you argue in favor of adding an extra bullet noting that RFC2460 does
not require the lower 16 bits to be unique? (just double-checking). If
so, fine with me.

> IPv6 capability vulnerable because of incorrect behavior of routers. 

1) The attack I referenced is just one possible attack. If you employ
fragmentation, an atacker could just send forged packets meant to cause
collisions of frag IDs such that your packets are dropped -- clearly
employing an extra feature (as in this case), creates an attack vector.

2) The bahavior in routers is a policy. We may not like it. BUt it's a
policy, not incorrect behavior.

> It

Fragmentation has been considered harmful for ages. And yes, we're
saying that if you *do not need it*, you shouldn't use it.

> such links and say that "there is no evidence yet as to the prevalence

I'll talk to my co-authors about this one.

Thanks!

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Aug 2016 15:14:56 -0700

Hi, Fernando,

> rationale. And the place to include the rationale wasn't rfc2460bis --

I don't agree. RFC2460bis should not need a roadmap to explain all of
the associated changes and their rationales. That should be in 2460bis.

Otherwise, changes need to be made incrementally - that's a lot of extra
load on the IETF and a lot of complexity to figure out why things are
the way the end up.

> All references to RFC6145 are of the form "legacy translators", or

I don't think it's useful to refer in this doc to a spec that is already
obsoleted.

This is further reason why it's not useful to issue separate change
docs. It gets confusing as to what you're arguing and why.

> not require the lower 16 bits to be unique? (just double-checking). If

Yes - specifically, 2460 does not require that the lower 16 bits of the
ID are generated in a way that would comply with the expectations of
using just those bits for IPv4.

> employing an extra feature (as in this case), creates an attack vector.
There are many possible attacks but you focus on the one where routers
drop packets because they have frag EHs.

> policy, not incorrect behavior.
EHs are not optional in RFC2460. Dropping because you see them is not
policy - it forces the router to fail to support a required feature of IPv6.

> Fragmentation has been considered harmful for ages.

And is finally being understood as fundamentally necessary for tunneling.

>  And yes, we're
Yes, if you don't need tunnels, you shouldn't use them either, but that
doesn't mean tunnels shouldn't be used in general.

> I'll talk to my co-authors about this one.

AOK.

Thanks,
Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Aug 2016 10:50:01 +1200

> the associated changes and their rationales. That should be in 2460bis.

2460bis has pointers in such cases (and should include a pointer
to deprecate-atomfrag when it becomes an RFC). I don't think it is
helpful to readers of 2460bis to burden it with all the rationales.

> load on the IETF and a lot of complexity to figure out why things are

I don't think 2460bis will be the end of history, any more than 791 was
the end of IPv4 history. Incremental change will continue.

Regards
     Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Aug 2016 19:51:24 -0300

Hi, Joe,

> the associated changes and their rationales. That should be in 2460bis.

I don't think RFC2460bis is the place to add six pages about this. All
other changes are similarly discussed in the respective updating
documents. RFC7915 also references this doc for the rationale for
deviating from the behavior in RFC6145.

> docs. It gets confusing as to what you're arguing and why.

We just disagree here. This document explains why RFC7915 does not rely
on atomic fragments anymore, and why the corresponding functionality is
being removed from the spec. I don't see any complexity here.

> using just those bits for IPv4.

Agreed. Will do.

> policy - it forces the router to fail to support a required feature of IPv6.

The same you could say about a device dropping packets because they are
destined (or are not destined to) a specific port.

The router does support EHs. The network just has a policy that don't
want them.

In any case, there' no need to argue a lot on this specific attack
vector since, as noted, there are others.

> And is finally being understood as fundamentally necessary for tunneling.

And is necessary for UDP, too. Nobody is arguing against that. But the
case in which we were producing atomic fragments wasn't a case in which
you were really needed fragmentation: you were just using the FH as a
signaling mechanism.   -- for instance, an atomic fragment, hasn't
really fragmented anything.

> doesn't mean tunnels shouldn't be used in general.

Where in the texxt do we say "you shouldn't use fragmentation in general"?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Aug 2016 15:56:22 -0700

> Where in the texxt do we say "you shouldn't use fragmentation in general"?

It's the implication that follows from justifying this change based on
whether frag EHs are dropped.

IMO, that's simply irrelevant. The broader problem is using
IPv6-generated IDs, which are not generated to be compliant in their
bottom 16 bits with IPv4.

That alone is more than sufficient rationale for not using this mechanism.

Joe