Re: [manet] SMF

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
fred.l.templin@boeing.com

> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] 
> On Behalf Of Joe Macker
> Sent: Thursday, November 17, 2011 8:59 PM
> To: Teco Boot
> Cc: manet@ietf.org IETF
> Subject: Re: [manet] SMF - overloading the ID field
> 
> On Nov 16, 2011, at 9:50 PM, Teco Boot wrote:
> 
> > 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
> > 
> > 
> > Op 16 nov. 2011, om 19:18 heeft Joe Macker het volgende geschreven:
> > 
> >> On Nov 16, 2011, at 4:49 AM, Teco Boot wrote:
> >>> 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.
> >> 
> >> 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.
> >>> 
> >>> _______________________________________________
> >>> manet mailing list
> >>> manet@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/manet
> >>> 
> >> 
> > 
> > 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> 