Re: NAT behavior for IP ID field

Fernando Gont <fernando@gont.com.ar> Fri, 10 September 2010 20:59 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=bqWMC7h/11TbsoI53XrR3OvgDjPk4c9yJr0q1Po6lwx+6+FfhfSJbXo8+6zeKB5T2N LBS7o5V2R9lTLkeNyueA8ssTovtIPD4GqYtzGO9I7Y+5F5QlVB0V5mwUZ8mYeAk+cmZk 4Ff00mcjpVKs3/QH6thJTloFmm/Rswl3qf6IY=
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4C8A962A.6080202@gont.com.ar>
Date: Fri, 10 Sep 2010 17:33:46 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "t.petch" <daedulus@btconnect.com>
Subject: Re: NAT behavior for IP ID field
References: <20100831150444.22bd579e@t61p> <D0D68D38-84CD-4773-BB7E-328E1A31898A@muada.com> <00c601cb4a75$e428cfa0$4001a8c0@gateway.2wire.net>
In-Reply-To: <00c601cb4a75$e428cfa0$4001a8c0@gateway.2wire.net>
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, ietf@ietf.org
Precedence: list

Hi,

>>> I'm trying to locate an RFC that spells out the behavioral
>>> requirements, expectations or guidelines for NAT handling of the IP ID
>>> field, particularly for UDP messages.
>>> If this is not written down anywhere, do NATs generally rewrite the ID
>>> field with or without the MF bit set?
>> I don't know.
>>
>> We had a discussion about this in the BEHAVE working group while working on
> stateful IPv6-to-IPv4 translation. Unless I missed something, the ID field needs
> uniqueness for any combination of source, destination IP addresses and protocol.
> Assuming the source address doesn't change, this means an ID counter should be
> maintained per destination address + protocol pair, so the maximum number of
> packets can be transmitted for each such pair before an ID value is reused. This
> would be the optimal host behavior, and NATs should act like hosts in this
> regard. Reusing the ID field from the original packet has a much higher chance
> of seeing the same ID field for outstanding fragments of a different flow, which
> can cause undetected data corruption in 1 in 65535 cases when the TCP/UDP
> checksum doesn't catch this.

The same applies to other TCP and IP header fields.
draft-gont-behave-nat-security contains some discussion of this.



> Curious; RFC2402 says
> "      Flags -- This field is excluded since an intermediate router might
>              set the DF bit, even if the source did not select it."
> which is a licence to set the bit but I had not thought to reset the bit.
> RFC791,  RFC1122 and RFC1812 would appear to be silent on this.

I'm curious abut RFC 2402, then. Firstly, the host might not implement
PMTUD, and hence setting the DF bit on its behalf could possibly cause
interoperability problems. Secondly, some hosts clear the DF bit if the
advertised MTU in an ICMP "frag needed" is below some specified
threshols. This RFC2402-behavior could cause problems in this scenario, too.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

NAT behavior for IP ID field John Kristoff
Re: NAT behavior for IP ID field Iljitsch van Beijnum
Re: NAT behavior for IP ID field t.petch
Re: NAT behavior for IP ID field Iljitsch van Beijnum
Re: NAT behavior for IP ID field Fernando Gont
Re: NAT behavior for IP ID field Stephen Kent
Re: NAT behavior for IP ID field Joe Touch