Subject: [secdir] review of Updated Specification of the IPv4 ID Field

From: Stephen Kent <[email-masked]>
Date: Sun, 1 Jul 2012 12:56:01 -0400

I reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document, "Updated Specification of the IPv4 ID Field" is a 
update of RFCs 791, 1122 and 2003. The primary motivation for the 
update is a recognition that the uniqueness requirement imposed on 
the field values (on a per host pair and protocol basis) would limit 
"connections" to about 6.4 Mb/s (for typical 1500 byte packets), an 
unrealistically low data rate today. This document updates the cited 
RFCs to reflect current practice and to more closely match IPv6. 
Specifically, the field value is defined only when a datagram is 
fragmented.

The Security Considerations section is very brief, only three 
paragraphs.  It notes that removing the prior constraints on ID field 
generation (MSL uniqueness) make it easier to use this field as a 
covert channel. It suggests that rewriting the field is a possible 
countermeasure. This advice is presented with the context of 
datagrams not protected using AH. Because AH is no longer a mandatory 
to implement element of the IPsec suite, I suggested an edit to avoid 
suggesting that AH use if common.

The text goes on to discuss how removing the MSL uniqueness 
requirement reduces the entropy associated with the IPv4 header. It 
fails to explain why this might be significant. There is no 
indication that modern encryption algorithms used IETF security 
protocols are harmed by this reduction in entropy. Thus the paragraph 
devoted to this issue seems extraneous, possibly confusing to 
implementers.

The final paragraph in this section notes that the proposed ID field 
conventions may make it more difficult to count the number of 
distinct devices behind a NAT or similar device. I agree with the 
author's observation that this side effect of the current ID field 
requirements is not a security feature per se and thus not a concern.

Earlier sections of this document do a good job explaining how this 
change may impact various forms of middleboxes. The author should 
note in the SCC whether the change proposed in this document may 
adversely affect availability, if these devices are not updated to 
account for this change.

---

From: Steven Bellovin <[email-masked]>
Date: Sun, 1 Jul 2012 14:39:30 -0400

I would add that there have been other security-relevant uses of IPid.  Hal Burch's dissertation (sorry, I don't have the precise citation handy), and I think his papers with Bill Cheswick used it to see if two different IP addresses corresponded to the same node.  The Rocketfuel paper (Spring et al., SIGCOMM 2002) did the same thing.  I seen to recall various hacks that relied on it, including to detect idle hosts.