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

[Julien Laganier <[e-mail]>]

Joe,

Cutting thru a bit:

On Wed, Jun 22, 2011 at 5:08 PM, Joe Touch <[e-mail]> wrote:
>
>
> On 6/22/2011 4:40 PM, Julien Laganier wrote:
>>
>> 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.
>
> This point is mostly unchanged from its original discussion in the pre-WG
> version of the I-D, FWIW.
>
>> 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.
>
> If we don't give blanket permission to change the ID in unprotected atomic
> packets, isn't that requiring them to be immutable?
>
> I.e., we agree that we need to NOT assume that IDs of atomic packets are
> immutable; isn't that the same as allowing them to be modified in transit?
> Is there any other way to say "not immutable" than:
>
>        - an intermediate node MAY rewrite the ID of an atomic packet

It seems to me that NOT assuming that IDs of atomic packets are
immutable is adequately captured by

   o  >> All devices that examine IPv4 headers MUST ignore the IPv4 ID
      field of atomic datagrams.

no?

> NATs rewrite src or dst addresses, but also (technically) need to rewrite
> IDs to be correct w.r.t. current RFC 791 rules - but they don't. I'm not
> clear that whether a NAT can/does rewrite an ID is useful towards this
> point.
>
>>> 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...
>
> See above (I.e., I can't see how it doesn't); if you can find a way to
> express that as a requirement, I'm game.

We don' t require the field to be immutable by making the mutability
properties of the field transparent to the receiver that ignores this
field in atomic packets...

>>> 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...
>
> Well that would kill the entire discussion on header compression. That's
> fine if we want to omit that. but if we do say that "ID is not immutable in
> atomic packets", that opens the door to a very useful optimization for
> compression that ought to be included IMO.

I do not think that this draft should update a 20 years old protocol
specification with the goal of opening doors to optimization of header
compression for that same protocol. I _think_ it was also the sense of
Erik's message.

--julien