Subject: [Int-area] Some feedback on draft-touch-intarea-ipv4-unique-id

From: Fernando Gont <[email-masked]>
Date: Sun, 07 Mar 2010 21:24:50 -0300

Hi, Joe,

Some feedback on the aforementioned I-D:

Disclaimer: I'm rushing for deadlines :-). So my apologizes if there are
typos, or my elaborations are not as detailed as they should be (if
that's the case, ask back, and I will elaborate my comments in a more
detailed way).

**** Technical****

Meta:

You mention that the IP ID should be unique within a reordering context.
Now, what happens when a fragment is lost? Wouldn't that, by itself,
bring you back to "you should enforce the IP ID uniqueness for the time
a packet can be alive in the internet"?

Another one: Thinking out loud, if you touch the IP ID uniqueness issue,
you should also affect the fragment reassembly timeout.

Finally, what specifically do you mean by "reordering context"?

Section 1:

> This document updates the specification of the IP ID field to more 
> closely reflect current practice, and to more closely match IPv6, in 
> which the field is defined only when a packet is actually fragmented 
> and in which fragmentation occurs only at the source. It also updates
>  the recommended uniqueness interval to support the impact of 
> reordering on reassembly, rather than using an arbitrary and 
> unenforceable packet lifetime.

Note that in v6, if you receive an ICMP PTB claiming a Next-Hop MTU
smaller than 1280, you need to add a Fragment Header (even when you do
*not* fragment packets). So the above statement is not 100% accurate

Section 3
> IPv4 and IPv6 fragmentation differs in a few important ways. IPv6 
> fragmentation occurs only at the source, so a DF bit is not needed to
>  prevent downstream devices from initiating fragmentation. The IPv6 
> fragment header is present only when a packet has been fragmented, so
>  the ID field is not present for non-fragmented packets, and thus is 
> meaningful only for fragments. Finally, the ID field is 32 bits, and 
> unique per source/destination address pair for IPv6, whereas for IPv4
>  it is only 16 bits and unique per source/destination/protocol
> triple.
> 
> This document focuses on the IPv4 ID field issues, because in IPv6 
> the field is larger and present only in fragments.

Same as above.

Section 5:

> Note also that 120 seconds is only an estimate on the maximum packet 
> lifetime. It is loosely based on half maximum value of the IP TTL 
> field, which is represents 0-255 seconds,

Note that some implementations set the IP ID to other values (e.g., 255)
-- notably those implementing GTSM.

Section 6.1

> Note that this excludes some current practices that use the ID field
> and the remainder of the IP header as a unique tag. This tag has been
>  suggested as a way to detect and remove duplicate packets, e.g., at
> congested routers, although this has been noted and no current
> deployments are known [RFC1122]. Some hosts use this tag to validate
> received ICMPs, in which the ICMP payload - an IP packet prefix - is
> matched against a cache of recently transmitted IP headers. This
> ensures that the received ICMP reflects a transmitted packet, though
> it does not prevent spoofing of ICMPs for attackers that can see
> those packets, and like ID reuse will cause problems at high packet
> rates.

Note that IP IDs shouldn't be used for this. If a NAT rewrites the IP ID
(as it should), then you cannot validate e.g. ICMP messages based on the
IP ID of the original packet.

Section 6.2:

> In other words, such sources can emit only non-fragmented packets
> where DF has been set. Such sources can repeat the ID field for
> atomic packets, as it is intended to be ignored.

Two comments here. If you make this a requirement, you should probably
require implementation of PMTUD.

Also, note that repeating the IP ID is a bad idea. Remember when Linux
decided set the IP ID to 0 when DF==1 -- they had to back out this change.

See the discussion in the CPNI IP security document:
http://www.cpni.gov.uk/Docs/InternetProtocol.pdf

> Sources emitting non-atomic IPv4 packets need to set the ID field
> sufficient to support reassembly, and encourages the use of stronger
> transport layer validation where possible. Uniqueness over a two
> minute interval may be excessive to support reassembly in some
> environments, and is clearly already being ignored.

What do you mean by "encourages..."?

> o  >> Sources that cannot ensure safe IPv4 ID generation and that
> allow DF=0 SHOULD employ integrity checks that would detect mis-
> reassembled fragments, e.g, as in SEAL [RFC5320]. Applications SHOULD
> NOT use UDP without checksums [RFC793], and SHOULD be very careful in
> their use of UDP-Lite [RFC3828] in such environments.

I'm not sure if you can make a requirement of "SHOULD be very careful".
Yes, I've seen this sort of requirement, but... I'm not sure one can
comply or not comply with such a req...

Section 6.3

> This overlap is noted as the result of reusing IDs when
> retransmitting packets, which this document deprecates. Overlapping
> fragments are themselves a hazard [RFC4963]. As a result:
>
> o  >> Overlapping packets MUST be silently ignored during reassembly.

Overlapping may be the result of multiple paths, with different MTUs.
This requirement may thus result in interoperability problems.

Section 7.1

> o  >> The IP ID is not defined if the packet (datagram) is atomic. IP
>  packet sources MAY use any value as ID; all such values MUST BE
> ignored on examination at intermediate nodes and destinations.

For the reasons stated about (i.e., what happened with Linux), I don't
think this is a good idea.

Section 10:

>>> During the transition period, a small ID space SHOULD be used to
> assist with debugging and detection; such a space SHOULD use the
> lower bits (i.e., lower 4 bits) of the ID field and clear (i.e.,
> zero) the remaining high order bits.

Details?

Section 11:

Some security considerations are missing. See the relevant discussion in
the UK CPNI paper

**** Editorial ****

Section 5

> Wireless Internet devices are frequently connected at speeds over 54
> Mbps, and wired links of 1 Gbps have been the default for several
> years. Although many end-to-end transport paths are congestion
> limited, these devices easily achieve 100+ Mbps application-layer
> throughput over LANs (e.g., disk-to-disk file transfer rates), and
> numerous throughput demonstrations have been performed with COTS

You should expand COTS

Section 6.1

> Although at least one document suggests the ID field has other uses, 
> we assert here that the ID field is defined only for fragmentation 
> and reassembly.

Which document? (i.e., add a reference)

**** Nits ****

Section 6.3

> o  >> The IP ID MUST NOT be reused when sending a copy of an earlier 
> non-ATOMIC packet

S/ATOMIC/atomic/ ?

> RFC 1122 also suggests that fragments can overlap [RFC1122]. Such 
> overlap can occur if successive retransmissions use different 
> packetizing but the same reassembly Id.

s/Id/ID/

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Sun, 07 Mar 2010 17:28:56 -0800

Hi, Fernando,

Comments interspersed below.

It'd be useful to confirm which version of the doc you reviewed -
presumably 03?

Fernando Gont wrote:
...
> a packet can be alive in the internet"?

The idea of a reordering context is that the receiver would presumably
drop all pending fragments when that context expires, so retransmitting
the ID after that period should not affect reassembly. See below.

> you should also affect the fragment reassembly timeout.

Sure - that basically establishes the reordering context tolerated.

> Finally, what specifically do you mean by "reordering context"?

The time during which reordering is expected and tolerated. I'll include
that as an explicit definition.

> *not* fragment packets). So the above statement is not 100% accurate

That's only for IPv6 talking to IPv4 addresses, and only for
interoperation with IPv4 uses of the ID field. The text will be updated,
but the goal is obviously to emulate IPv6 operation with IPv6.

>> the field is larger and present only in fragments.

Agreed - in IPv6 not intending to be translated to IPv4.

> -- notably those implementing GTSM.

Do you mean TTL or ID?

GTSM sets the TTL to 255. That doesn't change the fact that historically
120 seconds is based on half the maximum possible TTL, where TTL is
assumed as 1 second per hop though.

> IP ID of the original packet.

We can also note that this mechanism isn't compatible with NATs.
Virtually nothing that NATs or middleboxes do can be validated behind
the NAT, and this is known anyway.

Note that we're trying to declare this behavior invalid anyway, however.

> require implementation of PMTUD.

We say:
   o  >> Sources unable to meet the non-repeating IP ID requirement
      above MUST NOT emit non-atomic packets.

We don't care how they achieve this. PMTUD is one way, but we don't need
to require a specific mechanism.

> http://www.cpni.gov.uk/Docs/InternetProtocol.pdf

Please clarify - that example is based on the behavior of boxes that
ignore the DF bit, correct?

We already note that this change will impact devices that ignore the DF
bit. Those boxes are already potentially causing unnoticed problems,
since the ID is already wrapping for even modest-speed transfers.

Overall, the boxes in question have a bug that needs to be fixed,
regardless of what this doc recommends.

> What do you mean by "encourages..."?

The document encourages....

> comply or not comply with such a req...

They can comply by employing integrity checks, e.g., as in SEAL. That
last SHOULD is probably redundent - we can reword that as "are expected
to be".

> This requirement may thus result in interoperability problems.

A packet needs to be duplicated and the copies sent on multiple paths
for this to happen; that can be noted. The result is to reassemble only
the fragments of a single original packet - that should not affect
interoperability.

> think this is a good idea.

As noted above, what happened exposed an error in an intermediate box; I
don't see us failing to update 791 to accommodate a bug of that nature.

>> zero) the remaining high order bits.

I'm more inclined to omit this section; I'm not sure what using a
smaller ID space accomplishes in the interim, and I don't particularly
like short-term recommendations in an RFC.

Thus the questions at the front of the section. If that recommendation
stands, it's intended to be vague anyway.

> Some security considerations are missing. See the relevant discussion in

This doc is not about the security of that field as currently used.

Are there particular considerations about declaring the field invalid
when a packet isn't fragmented that are not already addressed?

>> numerous throughput demonstrations have been performed with COTS

Sure.

> Which document? (i.e., add a reference)

1122. will do.

>> o  >> The IP ID MUST NOT be reused when sending a copy of an earlier 

Yup.

>> packetizing but the same reassembly Id.

Yup.

Thanks,

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 08 Mar 2010 10:07:16 -0300

> It'd be useful to confirm which version of the doc you reviewed -

Yes, -03. -- sorry for the omission.

> the ID after that period should not affect reassembly. See below.

Ok. this is what I had referred to as "maximum jitter" (IIRC)... as even
if there's not actual reordering, you need to accommodate inter-fragment
delays...

> Sure - that basically establishes the reordering context tolerated.

Do you suggest any value?

> that as an explicit definition.

Good.

> but the goal is obviously to emulate IPv6 operation with IPv6.

Ok.

>> -- notably those implementing GTSM.

Sorry, I was referring to the TTL.

> assumed as 1 second per hop though.

Rather than "half the TTL", isn't the 120 sort of twice the recommended
TTL? (ala 2*MSL)?

> Note that we're trying to declare this behavior invalid anyway, however.

Agreed. This was just a clarification.

> to require a specific mechanism.

Some comment about this would be useful.

> ignore the DF bit, correct?

Yes.

> since the ID is already wrapping for even modest-speed transfers.

Yes. but setting the IP ID to a fixed value would make that problem
deterministic.

> regardless of what this doc recommends.

I may agree. But the world is what it is. And if we cannot be assure
that those boxes will be fixes, this is an important factor. Setting the
IP ID to a fixed value makes this problem more likely. (For instance,
what's the reason for requiring this? It aims at reducing the IP ID
frequency, or what?)

> The document encourages....

Check the para. I cannot parse it. ("Sources emitting..., and
encourages...")

> last SHOULD is probably redundent - we can reword that as "are expected

No, I was refering to "SHOULD be very careful of their use". You may say
"applications SHOULD NOT use UDP-lite blah blah", or whatever. But being
careful is vague, IMO. (Yes, there are RFCs with this type of req, but...)

> the fragments of a single original packet - that should not affect

There might be corner cases. e.g., failing to reassemble because you
discarded the overlapping fragments. FWIW, there was a paper with data.
(I think I had included a ref in the CPNI IP doc).

> don't see us failing to update 791 to accommodate a bug of that nature.

The bug may be horrible, but if the mod introduces interoperability
problems, that's not good, either. -- not that it makes me happy.

> smaller ID space accomplishes in the interim, 

That was my point.

> This doc is not about the security of that field as currently used.

Some issues are still the same. e.g., potential for DoS attacks. A
discussion of how this change affects NIDS-evasion attacks would be
worthwhile, too (i.e., in your proposal, overlapping fragments are not
allowed). Also, if you require unique IP IDs, then depending on how you
set the IP ID there may be security implications. Trashing the IP ID
space applies both to your doc and to RFC 791, but in this case there's
a small change (e.g., overlapping fragments are discarded, and thus a
malicious fragment may remain in the reassembly buffer for a longer
period of time), etc.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Mar 2010 07:37:53 -0800

Wrapping up this thread:

Fernando Gont wrote:
...
> Do you suggest any value?

It's highly dependent on the context, so there isn't an appropriate
single default.

IMO, it's like recommending a TTL for sources.

...
...
> Rather than "half the TTL", isn't the 120 sort of twice the recommended

The original text expresses the intent - 120 is half the maximum of the
field, when (rather than which - to be fixed) it represents 0-255 seconds.

Where is a TTL of 60 recommended?

...
>> ignore the DF bit, correct?

That's a bug, then. It would be infeasible to document the impact of
this change on every bug.

> Yes. but setting the IP ID to a fixed value would make that problem

It makes the bug visible, yes. That's definitely a problem for devices
that exhibit this bug.

> what's the reason for requiring this? It aims at reducing the IP ID

The reason is to recognize existing practice of increasing speeds that
exceed the ability of the ID to be unique as required.

In this case, we have three groups of devices:

	- those that are already wrapping the ID due to speed
	- those that are already setting ID to a fixed value (typ. 0)
	  but set DF=1
	- those that ignore the DF

Of these three, it's fairly clear that the third group is not only the
smallest (by a long shot), but that the last one clearly has a bug that
interferes with opher aspects of networking (PMTU, e.g.).

Time to declare that a bug and move on, IMO. All bug declarations admit
that those bugs will continue to cause problems, FWIW. We can't be
afraid to step for fear of such bugs.

> Check the para. I cannot parse it. ("Sources emitting..., and

I meant I'll fix it so it means that "the document encourages"

> careful is vague, IMO. (Yes, there are RFCs with this type of req, but...)

I said the last SHOULD - i.e.:

"and are expected to be very careful...

That removes the compliance language from the vague phrase, and the
expectation is already setup by the previous SHOULDs (allow DF=0 SHOULD
employ integrity checs, SHOULD NOT use UDP with checksums).

Being very careful about UDP-lite is exactly because its checksum
doesn't cover the body and can't detect reassembly errors at all.

> (I think I had included a ref in the CPNI IP doc).

That's not a corner case - that's the case we're declaring should drop
the packet, and we cite an RFC as to why.

> problems, that's not good, either. -- not that it makes me happy.

The mod doesn't introduce interoperability problems - it exposes
existing ones. We can't run away from all deployed devices simply
because someone wants to deploy them.

>> smaller ID space accomplishes in the interim, 

We'll be discussing this at the meeting. I think the point, overall, is
to more 'gently' break the boxes we're talking about above, i.e., so
throughput would go down but not be cutoff all at once.

> allowed). 

Can you be more specific? What we're saying is that supporting
overlapping segments is already known to be a hazard, which is already
sufficiently documented in an RFC. As a result, we're treating it as an
error and silently dropping it. We're following the Postel Principle
here - the data is unexpected, but since it could be non-malicious we're
not treating it as such.

> Also, if you require unique IP IDs, then depending on how you
> set the IP ID there may be security implications.

We already discuss this.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 08 Mar 2010 18:01:08 -0300

Hi, Joe,

> because someone wants to deploy them.

Agreed. But you cannot ignore the deployed base. If you're proposing
something that may lead to interoperability problems (as a result of
widely-deployed bugs, if you want), then that's still not good. Whether
you lieke it or not, you probably need to workaround those potential
problems, IMO. -- If not, this would be kinda "ok... this doesn't work
as expected... but if the Internet didn't have this buggy boxes, it would!"

> here - the data is unexpected, but since it could be non-malicious we're

I don't follow. There are legitimate cases for receiving overlapping
fragments. -- and those fragments have been considered "legal" so far.
You're know declaring that they should be ignored, so... where's the "be
liberal in what you accept from others"?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Mar 2010 13:23:21 -0800

Fernando Gont wrote:
> widely-deployed bugs, if you want), then that's still not good.

"widely" is hard to assess. There was no pointer to the source of the
claim in your doc as to the Linux issue, so it's hard to determine.

Do you have anything other than the assertion in your doc as a reference?

> Whether

The "workaround" to a box that ignores the DF is to treat all packets as
if DF=0, and that isn't productive.

The idea of a quickly-changing ID field is already documented as an
interim in Section 10 - that would allow these boxes to "fail more
often" but not fail completely.

That's fine as a workaround when problems are seen; using a workaround
in all cases just hides the bug longer and lets buggy equipment impede
fixing the spec.

(then the question becomes 'how long do we use this workaround')?

Do you have something else in mind?

> liberal in what you accept from others"?

Note that dropping overlaps doesn't prevent non-overlaps from working.
There's no reason that a path would generate overlaps without generating
non-overlaps.

Liberal = don't interpret overlaps as malicious.

IMO, reassembling them in ways that create undetectable corrupted
packets is actively bad, and clearly not necessary.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 08 Mar 2010 22:01:34 -0300

Hi, Joe,

Coments inline (more responses in other e-mails)...

> There's no reason that a path would generate overlaps without generating

Agreed. But they may get lost. i.e., the reassembly prrocess might fail
because of discarding the overlaps.

> Liberal = don't interpret overlaps as malicious.

It's not about the interpretation. It's about what you accept. And this
scheme is less liberal than the one specified in RFC 791.

(I'm not judgding the technical merits of your proposal... I'm just
arguing that IMO it does not follow Postel's Principle)

> packets is actively bad, and clearly not necessary.

Well, you have argued many times in favor of accepting error messages
(ICMP hard errors) that could be stale, be generated by corrupted
datagrams (e.g., by firewalls), etc. So what?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Mar 2010 07:12:32 -0800

Hi, Fernando,

I updated the subject line, and will cut down the detail so others can
follow this.

From the ID:

--

---

This requirement change is being made primarily for the purposes of
including recommendations made in RFC4963.

It removes a capability described in RFC1122 that is related to the
retransmission of an IP datagram with the same ID. This document already
 deprecates that behavior when fragmentation is permitted or done at the
source. I.e., the behavior is being deprecated because it is no longer
consistent with the use of the ID as described in this document.

Note that this is already explicitly explained as rationale in the doc
(see inclusion above).

My view is that the need to reassemble overlapping fragments represents
a capability (support for multipath reassembly) that was never needed on
a persistent basis to support IP communication. Such overlap can occur
as a transient during path changes (with loss on both paths), but should
not need to persist, *even assuming it happens under benign circumstances*.

This change is, however, *independent* of the general issue of updating
the ID number. If there is contention on this issue, it can be easily
omitted.

Joe