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

[Joe Touch <[e-mail]>]

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

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.

>> 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.

Joe