Subject: Re: NAT behavior for IP ID field

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Sep 2010 11:53:15 +0200

On 31 aug 2010, at 22:04, John Kristoff wrote:

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

Note that DF=1 doesn't save you from all of this, as RFC 2402 says:

   Mutable (zeroed prior to ICV calculation)
             Type of Service (TOS)
             Flags

So it is legal to rewrite the DF bit from 1 to 0. I also know that this happens in the wild because I used to do this at one time.

---

From: "t.petch" <[email-masked]>
Date: Thu, 2 Sep 2010 10:04:52 +0200

----- Original Message -----
From: "Iljitsch van Beijnum" <[email-masked]>
To: "John Kristoff" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 01, 2010 11:53 AM

> 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.
> So it is legal to rewrite the DF bit from 1 to 0. I also know that this
happens in the wild because I used to do this at one time.

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.

Tom Petch

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 2 Sep 2010 11:20:13 +0200

> RFC791,  RFC1122 and RFC1812 would appear to be silent on this.

Ah, I did't read that far. Not sure why a router would set the DF bit, though, that creates a PMTUD black hole.

I agree that there is no explicit permission to modify the DF bit in transit, but RFC 2402 certainly recognizes that this may happen in practice. It's a pretty effective way of getting rid of PMTUD black holes that you run into when there is an MTU smaller than 1500 in the middle of the network. Most people just rewrite the MSS option in TCP SYNs (which are certainly NOT defined as mutable in transit), though.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Sep 2010 17:33:46 -0300

Hi,

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

> 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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Sep 2010 06:00:58 -0400

>...

We made the decision ton exclude the DF bit from the ICV computation 
in 2402, based on what we believed was happening in the net, 
irrespective of what should have been happening ;-). We retained this 
behavior in RFC 4202, for the same reason.

Steve