Subject: Re: [Int-area] IPv4 ID update draft

From: Joe Touch <[email-masked]>
Date: Wed, 14 Sep 2011 14:51:24 -0700

Hi, Mike,

First, sorry for taking so long to respond; since I was not coming to 
Quebec and the INTAREA did not meet, this ended up low in my queue.

I've responded to your comments below. A new version of the ID will be 
issued very shortly to address the issues as described.

Joe

On 6/27/2011 9:00 PM, C. M. Heard wrote:
>>>>>> On Wed, 22 Jun 2011, Julien Laganier wrote:
> Julien>  Because we' re talking about updating a venerable protocol I
> Julien>  want to make sure that we get the necessary level of review
> Julien>  for this draft before we forward it to IESG for publication
> Julien>  as proposed standard. I've asked a number of people to have
> Julien>  a look at it, and below is the first review from Erik
> Julien>  (Thanks!)
>
> Here is an unsolicited review of the draft in question
> (draft-ietf-intarea-ipv4-id-update-02) from an outsider.
>
> I agree with the specification changes made in Section 6.1, which
> disallow the use of the IPv4 ID field for purposes other than
> fragmentation and reassembly.  I agree that these changes will have
> little, if any, impact on fielded implementations, and may indeed
> help to mitigate actual operational problems documented in RFC 4963,
> "IPv4 Reassembly Errors at High Data Rates."
>
> However, I do NOT agree with Section 6.2, and I believe that the
> changes proposed in that section should be dropped, or at the very
> least, better justification needs to be provided for making these
> non-backward compatible to a nearly 30 year old protocol.  In
> particular:
>
> - The proposed ban on overlapping IPv4 fragments is ill-motivated.
>    Section 6.2 cites RFC 4963 to support the assertion that
>    overlapping fragments are a security hazard, but I was not able to
>    find any discussion of overlapping fragments in that RFC.

That reference appears in a few places it should not; I'm not sure why, 
but this will be corrected where needed. This one was intended to refer 
to RFC 1858 and RFC 3128 as you note below, FWIW.

>    This
>    subject _is_ discussed in RFC 1858 and RFC 3128, but the hazards
>    discussed those RFCs result in middlebox packet filtering failures
>    and can be addressed by localized changes to the middleboxes,
>    without making a global change to IPv4.  If there is any
>    literature that documents a security hazard from overlapping
>    fragments in a properly implemented system that defers header
>    processing until a complete IP datagram is fully reassembled, I
>    have not been able to find it.  Indeed, it should be noted that
>    overlapping fragments are in principle legitimately possible if a
>    non-atomic datagram is duplicated within the network and the
>    duplicates are then fragmented in different ways.

I agree that this may not be required by the goals of this draft, and 
fully agree that paring the draft down may be more useful. The original 
motivation for this is the deprecation of deliberate source-issued 
duplicate IDs during retransmission; unfortunately, there are other 
potential sources of datagram duplication that need to be considered.

Unless others can suggest why overlapping fragments should be 
prohibited, I'll drop this recommendation.

> - The proposed ban on reusing the same ID when retransmitting an
>    identical datagram is ill-motivated because in this case
>    repetition does not lead to the type of reassembly errors
>    documented in RFC 4963.  The errors discussed in RFC 4963 arise
>    when different non-atomic datagrams have the same ID.

Although the discussion should be updated, I don't feel it's appropriate 
to relax this constraint.

It is already recommended in RFC 1122, and there is no relation to RFC 
4963 or reassembly errors.

> - The proposed change to allow the ID field of non-atomic datagrams
>    to be changed in transit is ill-motivated.  Erik Nordmark's review
>    (and the dubsequent discussion) has already dealt with this point
>    at length.

The conclusion of that discussion was:

- we will omit the explicit "ATOMIC ID MAY be rewritten" advice

- we will add a note that NATs already rewrite IDs

- the doc will be updated on the header compression issue

> Recently (albeit another context) Brian E Carpenter wrote:
> Brian>  We shouldn't be spending any effort on polishing the IPv4
> Brian>  heirloom, except for vital security or operational fixes.
>
> I agree with the changes proposed in Section 6.1 because they
> provide fixes for a documented operational issue.  I disagree with
> the changes in Section 6.2 because they amount to unnecessary (and
> probably even harmful) polishing of the IPv4 heirloom.

The remaining component of that section is then repeating the 
recommendation from 1122 in 2119-language to avoid packet replication. I 
will augment the discussion to provide additional reasons why (e.g., it 
interferes with the expectation of fragment lifetime).

> Thanks and regards,
>
> Mike Heard
>
> P.S. One nit: the next-to-last paragraph of Section 4 states: "The
> IPv4 ID field can also be used to validate payloads of ICMP
> responses as matching the originally transmitted datagram at a host
> [RFC4963]."  I was not able to find any such discussion in RFC 4963,
> and I think the reference should either be corrected or dropped.

That should be RFC 5927.

---

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 15 Sep 2011 21:58:55 -0700 (PDT)

On Wed, 14 Sep 2011, Joe Touch wrote:
> First, sorry for taking so long to respond; since I was not coming to Quebec
> and the INTAREA did not meet, this ended up low in my queue.
> 
> I've responded to your comments below. A new version of the ID will be issued
> very shortly to address the issues as described.

Joe,

Many for the reply and for posting draft-ietf-intarea-ipv4-id-update-03.  The 
following comments address one editorial issue that remains in -03 and some 
other things.

> That reference appears in a few places it should not; I'm not sure why, but
> this will be corrected where needed. This one was intended to refer to RFC
> 1858 and RFC 3128 as you note below, FWIW.
> 
> >    This
> I agree that this may not be required by the goals of this draft, and fully
> agree that paring the draft down may be more useful. The original motivation
> for this is the deprecation of deliberate source-issued duplicate IDs during
> retransmission; unfortunately, there are other potential sources of datagram
> duplication that need to be considered.
> 
> Unless others can suggest why overlapping fragments should be prohibited, I'll
> drop this recommendation.

I'm happy with the text in draft-ietf-intarea-ipv4-id-update-03, except that the 
last sentence in Section 8.2, Updates to RFC 1122, needs to be removed.  I'm 
referring specifically to the bullet stating that IPv4 datagram fragments no 
longer are permitted to overlap.

> Although the discussion should be updated, I don't feel it's appropriate to
> relax this constraint.
> 
> It is already recommended in RFC 1122, and there is no relation to RFC 4963 or
> reassembly errors.

Well, I guess we just have to agree to disagree on this point.  
Although I agree with the statement in RFC 1122 that this behaviour 
is "not useful", I don't think the case is made for outlawing it.  
On the other hand, it seems unlikely that this behaviour is present 
in deployed implementations to any significant degree, so I'm not 
inclined to further contest the point.

> > and I think the reference should either be corrected or dropped.

I could not find anything about that in RFC 5927, but the text in
-03 is now self-contained, and I'm happy with it, so no matter.

Thanks and regards,

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Sep 2011 08:42:41 -0700

> longer are permitted to overlap.

Yes - that oversight is fixed in 04, which I'll issue shortly for review. 

Joe