Subject: [BEHAVE] CGN REQ: IP-ID

From: <[email-masked]>
Date: Tue, 15 Mar 2011 15:14:20 +0100

Re-,

As for the re-writing of the IP-ID field, a requirement reflecting what is discussed in http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02#section-9 should be added to the I-D.

Cheers,
Med

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Mar 2011 10:21:37 -0400

On 2011-03-15 10:14, [email-masked] wrote:
> As for the re-writing of the IP-ID field, a requirement reflecting what
> is discussed in
> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02#section-9 should
> be added to the I-D.

Unless the WG disagrees, I'll add a new requirement referring to that draft.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 11:08:27 -0700

> is discussed in http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-
> update-02#section-9 should be added to the I-D.

BEHAVE has documented how popular layer 4 protocols are translated on 
today's NATs -- TCP (RFC5382), UDP (RFC4787), and ICMP (RFC5508).  Those
documents provide minimal guidance, in an attempt to improve NAT 
operation.  BEHAVE has not published a document on how IP is 
translated.

That section describes how to translate IP, and requires a NAT
reassemble fragments and re-write the IPID.  The requirement is
not solely on a NAT but, rather, on any sort of address-sharing 
device (to include 4rd, IVI, and others in the "A+P family").  

Unfortunate to say, but I do not foresee NAT vendors implementing 
that requirement.  Joe, I assume there is demonstrated harm 
occurring on the Internet where IPIDs collided?

-d

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Mar 2011 11:52:54 -0700

Hi, Dan,

> occurring on the Internet where IPIDs collided?

It's difficult to show such measurements, as we don't have access to 
traffic behind NATs. The result of not rewriting the ID appropriately 
can be increased packet reassembly errors, some of which may be caught 
by TCP checksums, some may result in interrupted TLS connections, etc.

I do understand that NAT vendors can't be expected to implement *any* 
standard; that's frankly their entire focus. That doesn't mean we can't 
or shouldn't hold them to such, however. I.e., *when* there are 
problems, we can stand behind their incorrect behavior as the cause, 
rather than simply saying "kids will be kids" and expecting the rest of 
the Internet to accommodate them.

Joe

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 15 Mar 2011 14:16:08 -0500

> Unless the WG disagrees, I'll add a new requirement referring to that draft.

Capturing this as a "SHOULD" is a good idea.  However, it needs to be clear
that the goal is to avoid ID overlap for a given set of flows - the goal is
not necessarily to translate the IP ID field.  The mechanism for avoiding IP
ID overlap is is an implementation issue.

Cheers,
-Benson

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 14:25:04 -0700

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, March 15, 2011 11:53 AM
> To: Dan Wing
> Cc: [email-masked]; draft-ietf-behave-lsn-
> [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] CGN REQ: IP-ID
> 
> Hi, Dan,
> 

But a significant majority of TCP connections send their segments 
with DF=1 (FreeBSD, Linux, OSX, Windows, and iOS).  So I doubt the 
problem occurs very frequently with TCP.

I expect it could occur with UDP, especially with applications that 
rely on fragmentation (that is, send UDP packets bigger than the MTU).

> standard; that's frankly their entire focus.

Hugs all around.

> That doesn't mean we can't

-d

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Mar 2011 14:49:40 -0700

Hi, Dan,

As a preface, I just want to point out that the statements in ipv4-id 
that refer to NATs don't add new requirements; IMO, they are just 
interpretations of *existing* requirements on NATs - granted, that they 
often ignore, and that may or may not have widespread impact (it's very 
hard to measure), but I continue to think they're worth stating.

Some further notes below.

> problem occurs very frequently with TCP.

There's already ample evidence that many devices ignore DF=1 as well, 
though.

> rely on fragmentation (that is, send UDP packets bigger than the MTU).

Yes, that too - DNS may be one likely example of this.

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 15:00:49 -0700

> Sent: Tuesday, March 15, 2011 2:50 PM
> To: Dan Wing
> >>>> is discussed in http://tools.ietf.org/html/draft-ietf-intarea-
> ipv4-
> >> id-

Neither a host nor a NAPT can fix that, though, especially with the
restrictions of Section 6.1 of draft-ietf-intarea-ipv4-id-update 
which seem to prohibit the NAPT from diddling with the IPID of
atomic packets.

> Yes, that too - DNS may be one likely example of this.

Agreed, especially with EDNS0, DNSSEC, and AAAA making those packets
larger.

-d

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Mar 2011 15:25:06 -0700

> which seem to prohibit the NAPT from diddling with the IPID of

Right. We can't fix it; we're just trying to explain where the error is.

Joe

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 07:28:44 +0100

Hi Dan,

I don't think this an argument to not include it as a requirement in the CGN I-D.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 19:08
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]; 'Joe Touch'
Objet : RE: [BEHAVE] CGN REQ: IP-ID

-d

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 07:35:51 +0100

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Benson Schliesser [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 20:16
À : Simon Perreault; BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : 'behave' <([email-masked])>; [email-masked]
Objet : Re: [BEHAVE] CGN REQ: IP-ID

Capturing this as a "SHOULD" is a good idea.  However, it needs to be clear
that the goal is to avoid ID overlap for a given set of flows - the goal is
not necessarily to translate the IP ID field. 

Med: We might be then vulnerable to what is discussed in http://www.cs.columbia.edu/~smb/papers/fnat.pdf; in particular extrapolating to analyse so that it can be used to determine the address sharing ratio used by an SP? (I have the DS-Lite case in mind).

 The mechanism for avoiding IP
ID overlap is is an implementation issue.

Cheers,
-Benson