Subject: [Int-area] SMF and intarea-ipv4-id-update

From: Teco Boot <[email-masked]>
Date: Wed, 30 Mar 2011 13:29:25 +0200

Sorry for x-posting. But there is a conflict in:
http://tools.ietf.org/html/draft-ietf-manet-smf
http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update

SMF has a duplicate packet detection function based on the IPv4 
ID field. So text in ietf-intarea-ipv4-id-update section 4
is not correct, in that there would be no deployments for such.
That said, SMF deployment with IPv4 DPD on IP-ID would be limited.

What to do?

Teco

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Mar 2011 04:46:03 -0700

Hi, Teco,

> is not correct, in that there would be no deployments for such.

SMF is experimental. When we talk about deployments of duplicate 
detection, we're focused on standards-based systems.

Note that ipv4-id-update is standards-track.

> That said, SMF deployment with IPv4 DPD on IP-ID would be limited.

IMO, recommend H-DPD and change the discussion to explain why the ID 
shouldn't be used for DPD (the text is basically already there - it 
mentions the idea, but then explains that it's not likely to work anyway).

Use of the IP ID for this purpose is problematic for a variety of 
reasons, which is why ipv4-id-update deprecates use of that field for 
that purpose.

Joe

---

From: Teco Boot <[email-masked]>
Date: Wed, 30 Mar 2011 14:01:54 +0200

Hi Joe,

The current text in intarea-ipv4-id-update is "no current deployments 
are known". I read this as a statement in general. Then, it is not correct.
I am fine with discouragement of usage of systems that use IP_ID for DPD,
but such systems are around.

Teco

Op 30 mrt 2011, om 13:46 heeft Joe Touch het volgende geschreven:

> SMF is experimental. When we talk about deployments of duplicate detection, we're focused on standards-based systems.
> 
> IMO, recommend H-DPD and change the discussion to explain why the ID shouldn't be used for DPD (the text is basically already there - it mentions the idea, but then explains that it's not likely to work anyway).
> 
> Use of the IP ID for this purpose is problematic for a variety of reasons, which is why ipv4-id-update deprecates use of that field for that purpose.
> 
> Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Mar 2011 05:06:47 -0700

> are known". I read this as a statement in general. Then, it is not correct.

Experiments are not supposed to be deployed in the public Internet. So 
unless the doc markings are incorrect, SMF should really not be 
deployed. ;-)

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Mar 2011 05:16:02 -0700

Clarification...

> Experiments are not supposed to be deployed in the public Internet. So
                                     ^ widely                        ^
						    without monitoring
> unless the doc markings are incorrect, SMF should really not be

Back to your original point, yes, we should note that this is happening. 
How widely deployed is this, and what would the impact be of updating 
the 'experiment' to use H-DPD for IPv4?

Joe

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 30 Mar 2011 05:21:23 -0700

Hello Teco,

Is it possible that the SMF usage is not vulnerable to
the pitfalls noted in the intarea draft?  Usually we
don't picture NAT boxes in the MANET routing paths...

Regards,
Charlie P.

On 3/30/2011 5:01 AM, Teco Boot wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Teco Boot <[email-masked]>
Date: Wed, 30 Mar 2011 14:27:46 +0200

OK, it is good to hear that we can continue to do experiments and learn 
from that. 

I am aware of (non-SMF) data transport over small bandwidth
satcom links, using IP-ID DPD. It is experimental / prototype. 
For SMF, I let authors respond.
 
I think it is acceptable to update such experiments to H-DPD.

Teco

Op 30 mrt 2011, om 14:16 heeft Joe Touch het volgende geschreven:

> Back to your original point, yes, we should note that this is happening. How widely deployed is this, and what would the impact be of updating the 'experiment' to use H-DPD for IPv4?
> 
> Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Mar 2011 05:27:29 -0700

The pitfalls include:

- false positives (dropping unique packets) due to ID wrap before 2MSL

- false positives due to ID being deliberately repeated (e.g., from 
cellphones using ID=0 all the time)

- false positives due to colliding use by different sources behind a NAT 
that fails to rewrite the ID

Note that only the last example is NAT related. The others are not.

Joe

---

From: Teco Boot <[email-masked]>
Date: Wed, 30 Mar 2011 14:34:40 +0200

There are other ideas around, that could be applicable in MANETs.
You could check draft-briscoe-intarea-ipv4-id-reuse

Teco

---

From: Scott Brim <[email-masked]>
Date: Wed, 30 Mar 2011 14:40:59 +0200

> You could check draft-briscoe-intarea-ipv4-id-reuse

Bob's draft assumes Joe's draft.  It may collide with other
undocumented uses of the "reserved" flag.  I never make assumptions
about what middleboxes might do when nobody is looking.

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Mar 2011 05:50:41 -0700

FWIW, Briscoe's doc won't help here. It is intended to find other ways 
to use the ID field for atomic packets (as defined in ipv4-id-update), 
but those bits would be as flags, not as a whole space that could be 
used for a given purpose.

Joe

---

From: "Justin Dean" <[email-masked]>
Date: Wed, 30 Mar 2011 08:23:11 -0400

"Deprecating the use of the IPv4 ID field for non-reassembly uses
   should have little - if any - impact."

That statement wasn't true for very long was it...
Well section 9 may provide a way out.

"Network address translators (NATs) and address/port translators
   (NAPTs) rewrite IP fields, and tunnel ingresses (using IPv4
   encapsulation) copy and modify some IPv4 fields, so all are
   considered sources, as do any devices that rewrite any portion of the
   source address, destination address, protocol, and ID tuple for non-
   atomic datagrams [RFC3022]. As a result, they are subject to all the
   requirements of any source, as has been noted."

With the current draft incoming packets can have their id fields modified by
the SMF gateway before being forwarded in the MANET.  I would say this makes
the gateway a source.  Then we just need to fragment everything!  I can see
the reason for banning the behavior in high bandwidth wired links where
duplicates only occur with routing loops and the id wraps so fast it is
useless.  But the way this is written it bans ALL use of the IPv4 ID field
for duplicate detection.

"The IPv4 ID field is no longer permitted for duplicate detection." 

Does this mean we can't even hash this field for duplicate detection?!

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Teco Boot
> Sent: Wednesday, March 30, 2011 7:29 AM
> To: [email-masked]; MANET IETF
> Subject: [manet] SMF and intarea-ipv4-id-update
>

---

From: Joe Macker <[email-masked]>
Date: Wed, 30 Mar 2011 16:10:08 +0200

Yes this is an optional duplicate detection scheme and is an example of use in practice.

Also As Teco mentioned this intended for limited use in edge network multicast systems.

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Mar 2011 19:10:55 +0200

> That statement wasn't true for very long was it...

Technically even if your devices rely on it it wouldn't be long before they started dropping valid packets, IMO.

> Does this mean we can't even hash this field for duplicate detection?!

The field and the other parts of the header are not ensured unique for fragments right now - many hosts break the rules. A packet as a whole isn't either. 

It is much safer to expect the higher layers to drop such duplicates. You can drop but you need more requirements - e.g., that the higher layer won't send valid dups (TCP seqnos accomplish this), and you check/hash the whole packet.

The header *isn't* enough right now, unless you ensure rate limiting.

Joe

> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area