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

[Joe Touch <[e-mail]>]

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

> 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

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.

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.

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

Joe


>
>    Erik