Subject: [manet] SMF - overloading the ID field

From: Teco Boot <[email-masked]>
Date: Wed, 16 Nov 2011 10:49:25 +0100

More thoughts on what to do with SMF IPv4 I-DPD:

If one says we shall not overload the ID field and take out all IPv4 I-DPD functions, I wonder why we keep IPv6 I-DPD. Tomorrow one could write something like:
>    o  >> IPv6 Fragment Header Identification field MUST NOT be used for purposes other than

>       fragmentation and reassembly.

Oeps, I did already...

AFAIK no one came up with real harm using the IPv4 ID field for DPD. RFC 1122 suggests so ("discard duplicate datagrams"), for slightly different reasons. But yes, there are concerns with atomic non-IPsec datagrams. We can use H-DPD for these, which will use the ID field anyway ;-)

I don't think there is a strong need to take out I-DPD for non-atomic datagrams. ID field is OK,  ipv4-id-update:
>    o  IPv4 ID uniqueness applies to only non-atomic datagrams.

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 16 Nov 2011 02:51:07 -0800

Hello folks,

I agree with Teco.  There doesn't seem to be any real
harm in the proposed use for the ip-id field in the
intended application; the suggested problem seems to
be very unlikely to happen.  If there is concern
about the ip-id field wrapping around, then some
rate-limiting language could be inserted.  Instead of
calling it "overloading" the ip-id field, we could
call it "efficient use" of the field.  The problem
seems to be a matter of initial perception as shaped
by the intarea draft, which is intended to eliminate
problems that may arise in the most general case.
If the problems do not arise in our specific case,
should we still abide by a restriction intended to
cover other situations?

Regards,
Charlie P.

On 11/16/2011 1:49 AM, Teco Boot wrote:
>>     o>>  IPv6 Fragment Header Identification field MUST NOT be used for purposes other than
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Joe Macker <[email-masked]>
Date: Wed, 16 Nov 2011 13:18:04 -0500

>>   o  IPv4 ID uniqueness applies to only non-atomic datagrams.

Agreed so its not really overloading in that non-atomic case. That is what I said in jabber last night.

However, I have already rewritten the IPv4 part to be H-DPD only and while I agree with your subtle point in non-atomic case I think a hybrid I-DPD/H-DPD state machine is more complex.

I think a need a few more days to possibly refactor the security considerations since there is a relationship and then I can pass it on.

---

From: "Cole, Robert G USA CIV (US)" <[email-masked]>
Date: Wed, 16 Nov 2011 23:29:11 +0000

Joe,

So IPv4, H-DPD only is the plan for SMF?  If so I'll also rev the SMF-MIB module to reflect.

Also as you are thinking about security issues, perhaps you and Brian can scrutinize the security section of the MIB draft. :-)
In general, I was hoping the WG could also read the security writeup and comment.  This is much simplier than reviewing the MIB module itself.

Thanks,  Bob

---

From: Teco Boot <[email-masked]>
Date: Thu, 17 Nov 2011 03:50:20 +0100

Did you remove all of I-DPD, I mean also the IPsec enhanced Tuple I-DPD Check?
Anyway, a mix of H-DPD and "complete I-DPD" works just fine, if implemented well. There is no need for standardization, the function is local to the box.

Teco

---

From: Joe Macker <[email-masked]>
Date: Thu, 17 Nov 2011 23:58:39 -0500

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 22 Nov 2011 09:54:23 -0800

About SMF and I-DPD, you might be interested to know
about SEAL encapsulation which includes a 32-bit packet
ID field that behaves the in exactly the same way as
for the IPsec AH and ESP Sequence Number:

http://www.ietf.org/id/draft-templin-intarea-seal-39.txt

SEAL is like a lightweight variation of tunnel-mode
IPsec/AH, but it also takes care of path MTU adaptation,
nested encapsulation and re-encapsulation. I haven't
written about SEAL and multicast yet, but multicast
SEAL tunnel neighbor associations would be handled
the same as for multicast IPsec security associations.

SEAL is for MANET applications, but is also broadly
applicable for numerous other use case secenarios.
It works in conjunction with VET, and supports the
IRON architectural framework:

http://www.ietf.org/id/draft-templin-intarea-vet-31.txt
http://www.ietf.org/id/draft-templin-ironbis-08.txt

Should I start a new discussion thread on the
applicability of IRON, SEAL and VET for MANET
scenarios?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Joe Macker
> Sent: Thursday, November 17, 2011 8:59 PM
> To: Teco Boot
> Cc: [email-masked] IETF
> > Anyway, a mix of H-DPD and "complete I-DPD" works just 
> fine, if implemented well. There is no need for 
> standardization, the function is local to the box.
> > 
> > Teco
> > 
> > 
> >>> If one says we shall not overload the ID field and take 
> out all IPv4 I-DPD functions, I wonder why we keep IPv6 
> I-DPD. Tomorrow one could write something like:
> >>> AFAIK no one came up with real harm using the IPv4 ID 
> field for DPD. RFC 1122 suggests so ("discard duplicate 
> datagrams"), for slightly different reasons. But yes, there 
> are concerns with atomic non-IPsec datagrams. We can use 
> H-DPD for these, which will use the ID field anyway ;-)
> >>> 
> >>> I don't think there is a strong need to take out I-DPD 
> for non-atomic datagrams. ID field is OK,  ipv4-id-update:
> >> Agreed so its not really overloading in that non-atomic 
> case. That is what I said in jabber last night.
> >> 
> >> However, I have already rewritten the IPv4 part to be 
> H-DPD only and while I agree with your subtle point in 
> non-atomic case I think a hybrid I-DPD/H-DPD state machine is 
> more complex.
> >> 
> >> I think a need a few more days to possibly refactor the 
> security considerations since there is a relationship and 
> then I can pass it on.
> >>> 
> >>> 
> >>> Teco.
> >>>