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

[Julien Laganier <[e-mail]>]

Hi Joe,

On Wed, Jun 22, 2011 at 1:30 PM, Joe Touch <[e-mail]> wrote:
> Hi, all,
>
> To discuss some points below...
>
> On 6/22/2011 11:22 AM, Julien Laganier wrote:
>>
>> Joe,
>>
>> Because we' re talking about updating a venerable protocol I want to
>> make sure that we get the necessary level of review for this draft
>> before we forward it to IESG for publication as proposed standard.
>> I've asked a number of people to have a look at it, and below is the
>> first review from Erik (Thanks!)
>>
>> --julien
>>
>> ---------- Forwarded message ----------
>> From: Erik Nordmark<[e-mail]>
>> Date: Wed, Jun 22, 2011 at 8:49 AM
>> Subject: Re: IPv4 ID update draft
>> To: Julien Laganier<[e-mail]>
>>
>>
>> On 6/22/11 8:17 AM, Julien Laganier wrote:
>>>
>>> Hi Erik,
>>>
>>> Have you read this draft of Joe:
>>>
>>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02
>>>
>>> If so, do you think it is ready for publication?
>>
>> No, I haven't read it.
>> I've sat through numerous presentations around the draft in the intarea
>> WG.
>>
>> I did a quick read.
>>
>> I see text like
>>   This document attempts to address the security considerations
>>   associated with fragmentation in IPv4 [RFC4459].
>> which is confusing given that RFC 4459 talks about e.g.,
>>   router-based
>>   fragment reassembly could easily lead to (reassembly) buffer memory
>>   exhaustion
>>
>> Clearly the id-update shouldn't claim to solve reassembly buffer
>> memory exhaustion, hence I think the above text around the reference
>> to RFC 4459 should be reworded.
>
> Will do. I have to look back to find the origin of that particular
> component...

Ok.

>> On network rewrites:
>>
>> Section 6.2 says
>>   For atomic datagrams, because the IPv4 ID field is ignored on
>>   receipt, it can be possible to rewrite the field. Rewriting can be
>>   useful to prevent use of the field as a covert channel, or to enable
>>   more efficient header compression. However, the IPv4 ID field needs
>>   to remain immutable when it is validated by higher layer protocols,
>>   such as IPsec. As a result:
>>
>>   o>>  The IPv4 ID field of non-atomic datagrams, or protected atomic
>>      datagrams MUST NOT change in transit; the IPv4 ID field of
>>      unprotected atomic datagrams MAY be changed in transit.
>>
>>   Protected datagrams are defined as those whose header fields are
>>   covered by integrity validation, such as IPsec AH [RFC4302].
>>
>> Section 10 says:
>>   This document thus does not recommend whether atomic IPv4
>>   datagrams should use nonchanging or changing IDs, but rather allows
>>   those IDs to be modified in transit (as per Sec. 6.2), which can be
>>   used to accommodate more efficient compression as desired.
>>
>>
>> And section 11 says:
>>   When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams),
>>   its value becomes unconstrained; that field then can more easily be
>>   used as a covert channel. For some atomic datagrams - notably those
>>   not protected by IPsec Authentication Header (AH) [RFC4302] - it is
>>   now possible, and may be desirable, to rewrite the IPv4 ID field to
>>   avoid its use as such a channel.
>>
>> I don't see any significant benefits in allowing in-transit
>> modifications of the IP-ID (I'm not talking about the NAT case, which
>> in essence re-originates a datagram with different addresses/ports),
>> and I think we should be careful when tweaking this 20+ year old
>> protocol. Thus I don't think we should allow for in-transit
>> modifications of unprotected datagrams.
>
> There's actually a very specific reason for allowing in-transit modification
> - to avoid the assumption that this field can now be used in atomic packets
> for other E2E messaging -- as others have recently proposed, e.g., in
> draft-briscoe-intarea-ipv4-id-reuse

I don't think that goal was in-scope for this I-D.

Also, since NAT may rewrite the I-D, it seems that the I-D can't be
used for that reliably, so maybe the I-D can mention that NATs may
rewrites IDs - rather than give blanket permission to intermediaries
to rewrite the IDs in unprotected atomic packets.

> The goal is to make the ID field something the receiver must ignore, solely
> to avoid the (often ignored) requirement that the ID be unique within
> src/dst/prot tuple within 2MSL.

IMHO the proper way to make the receier ignore the ID is to say MUST
ignore, rather than allowing intermediaries to rewrite it....

> IMO, we can't "require" the field to be immutable E2E unless it's protected
> (e.g., by IPsec or encapsulation and a checksum of some kind). That's the
> point of "allowing" it to change - which also means it can change out from
> under anyone who uses it anywhere in the net, which prevents it being used
> for new mechanisms.

Not requiring the field to be immutable doesn' t mean we have to allow
it to change...

> Given that context, do you think it's still important and/or feasible to
> prohibit in-transit mods?

It' s not really about prohibiting in-transit mods, since NATs might
do that already. It is about not allowing it per this specification.
You can stil mention that NATs do rewrite it...

--julien