Subject: RE: [manet] Comments on draft-ietf-manet-smf-06

From: "Joe Macker" <[email-masked]>
Date: Tue, 11 Dec 2007 10:35:22 -0800

Thanks for your comments Bruce. A couple quick responses.

- Present draft can deal with randomized ids, unlike previous one. ID
sequencing has some security flaws that we now point out, flaws beyond
fingerprinting.

- I am not against another draft discussing how the approach could be
adopted in an encapsulation mode, but I am presently against adding
encapsulation to this draft (borrowing DPD and forwarding optimizations).  I
feel an EXP allows for that evolution to continue.

-Joe

-----Original Message-----
From: Bruce M Simpson [mailto:[email-masked]] 
Sent: Wednesday, November 28, 2007 4:17 PM
To: [email-masked]
Cc: [email-masked]
Subject: [manet] Comments on draft-ietf-manet-smf-06

I am a bit disappointed that the current I-D for MANET SMF has no provision
for the encapsulation of MANET SMF datagrams in IPv4.

My points:
 * ip_id is only 16 bits wide, making its usefulness limited in large MANET
topologies.
  * Both BSD and Linux may be configured to randomize the ip_id field as a
defensive measure against IP host fingerprinting.
 * Choosing ip_id as a tag for the histogram based duplicate packet
detection requires that NAT routers on the path examine ip_id, in addition
to being examined by any software multicast forwarding plane implementation.
 * Encapsulation considerably simplifies implementation within existing
software multicast forwarding planes, again, re: BSD and Linux.
 * The overhead of demux and rewrite of BSD mbufs or Linux skbufs is likely
to be the same, i.e. O(n), for ip_id versus an encapsulation header.
 * For multicast flows between PIM domains and MANET domains, the overhead
of prepending such encapsulation at the gateway is very likely to be within
acceptable performance limits.

I would therefore encourage you to consider the benefits of allowing the use
of encapsulation in SMF viz the above points.

Kind regards
BMS

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Dec 2007 07:45:13 -0800

Joe, 

> From: Joe Macker [mailto:[email-masked]] 
> Sent: Tuesday, December 11, 2007 10:35 AM
> To: 'Bruce M Simpson'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [manet] Comments on draft-ietf-manet-smf-06
> 

I know we talked about this, but I went away and thought
about it and I'm not ready to say that encapsulation
shouldn't be considered for this version. It can be very
difficult to back-fit new features once an initial draft
goes to RFC; even as experimental. And, encapsulation does
give a way for DPD to avoid or minimize hashing in IPv4
MANETs. So, I would like to see further consideration for
multicast-in-multicast encapsulation now rather than wait
for a future draft that may never come about and/or may
be difficult to back-fit even if it does.

Fred
[email-masked]

---

From: "Joe Macker" <[email-masked]>
Date: Tue, 11 Dec 2007 11:05:18 -0800

IP-in-IP brings up other issues so I believe discussing the concept in a
separate draft makes sense.
I would like to contribute as well but want more discussion to take place.

-Joe

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Tuesday, December 11, 2007 7:45 AM
To: Joe Macker; Bruce M Simpson; [email-masked]
Cc: [email-masked]
Subject: RE: [manet] Comments on draft-ietf-manet-smf-06

Joe, 

> feel an EXP allows for that evolution to continue.

I know we talked about this, but I went away and thought about it and I'm
not ready to say that encapsulation shouldn't be considered for this
version. It can be very difficult to back-fit new features once an initial
draft goes to RFC; even as experimental. And, encapsulation does give a way
for DPD to avoid or minimize hashing in IPv4 MANETs. So, I would like to see
further consideration for multicast-in-multicast encapsulation now rather
than wait for a future draft that may never come about and/or may be
difficult to back-fit even if it does.

Fred
 
> I am a bit disappointed that the current I-D for MANET SMF has no 
> provision for the encapsulation of MANET SMF datagrams in IPv4.
> 
> My points:
>  * ip_id is only 16 bits wide, making its usefulness limited in large 
> MANET topologies.
>   * Both BSD and Linux may be configured to randomize the ip_id field 
> as a defensive measure against IP host fingerprinting.
> detection requires that NAT routers on the path examine ip_id, in 
> addition to being examined by any software multicast forwarding plane 
> implementation.
>  * Encapsulation considerably simplifies implementation within 
> existing software multicast forwarding planes, again, re: BSD and 
> Linux.
>  * The overhead of demux and rewrite of BSD mbufs or Linux skbufs is 
> likely to be the same, i.e. O(n), for ip_id versus an encapsulation 
> header.
>  * For multicast flows between PIM domains and MANET domains, the 
> overhead of prepending such encapsulation at the gateway is very 
> likely to be within acceptable performance limits.
> 
> I would therefore encourage you to consider the benefits of allowing 
> the use of encapsulation in SMF viz the above points.
> 
> Kind regards
> BMS
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Dec 2007 08:11:30 -0800

Joe, 

> Sent: Tuesday, December 11, 2007 11:05 AM
> To: Templin, Fred L; 'Bruce M Simpson'; [email-masked]
> Cc: [email-masked]

I'm not sure what you mean about the other issues; are
you talking about MTU, for example? The MTU for multicast
is simply 20 bytes less than whatever the raw linkMTU is,
and I don't see a problem with that.

Fred
 
> about it and I'm

---

From: "Joe Macker" <[email-masked]>
Date: Tue, 11 Dec 2007 11:30:31 -0800

Architecture considerations, iana, security, kernel implementation, etc. 

I don't see major problems just want it discussed in a separate document.

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Tuesday, December 11, 2007 8:12 AM
To: Joe Macker; Bruce M Simpson; [email-masked]
Cc: [email-masked]
Subject: RE: [manet] Comments on draft-ietf-manet-smf-06

Joe, 

> I would like to contribute as well but want more discussion to take
place.

I'm not sure what you mean about the other issues; are you talking about
MTU, for example? The MTU for multicast is simply 20 bytes less than
whatever the raw linkMTU is, and I don't see a problem with that.

Fred
 
> I know we talked about this, but I went away and thought about it and 
> I'm not ready to say that encapsulation shouldn't be considered for 
> this version. It can be very difficult to back-fit new features once 
> an initial draft goes to RFC; even as experimental. And, encapsulation 
> does give a way for DPD to avoid or minimize hashing in IPv4 MANETs. 
> So, I would like to see further consideration for 
> multicast-in-multicast encapsulation now rather than wait for a future 
> draft that may never come about and/or may be difficult to back-fit 
> even if it does.
> 
> Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Dec 2007 08:36:01 -0800

Joe, 

> Sent: Tuesday, December 11, 2007 11:31 AM

Not sure what you mean be architecture and security
considerations, but IANA should just fall out of whatever
gets specified in this document and, with mechanisms
like tuntap, I don't believe implementation is limited
to kernel.
 
> I don't see major problems just want it discussed in a 

Again, not tackling this now is going to make it difficult
if not impossible to tackle it later.

Fred

> > IP-in-IP brings up other issues so I believe discussing the 
> concept in
> a
> about it and 
> for a future

---

From: "Joe Macker" <[email-masked]>
Date: Tue, 11 Dec 2007 12:41:17 -0800

Fred:

At present there are experimental deployments with non-SMF receive nodes 
consuming SMF traffic without a required detunneling point. 
Understand tuntap...I meant in sense of above.

I may have little time in next few days to post more (in case I am quiet)..

For clarity (my thoughts):

(1) would like to see a pers ID for discussion
(2) could be short well-aligned with SMF CDS/DPD
(3) don't think (2) is difficult
(4) would be willing to help with (1)

-Joe

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Tuesday, December 11, 2007 8:36 AM
To: Joe Macker; Bruce M Simpson; [email-masked]
Cc: [email-masked]
Subject: RE: [manet] Comments on draft-ietf-manet-smf-06

Joe, 

> Architecture considerations, iana, security, kernel implementation, 

Not sure what you mean be architecture and security considerations, but IANA
should just fall out of whatever gets specified in this document and, with
mechanisms like tuntap, I don't believe implementation is limited to kernel.
 
> I don't see major problems just want it discussed in a separate 

Again, not tackling this now is going to make it difficult if not impossible
to tackle it later.

Fred

> I'm not sure what you mean about the other issues; are you talking 
> about MTU, for example? The MTU for multicast is simply 20 bytes less 
> than whatever the raw linkMTU is, and I don't see a problem with that.
> 
> Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Dec 2007 09:55:33 -0800

Joe,

Your suggestion seems very pragmatic, so I tend to
think we should give it serious consideration and I
make be able to help with it. Let's talk further on
this when time permits.

Thanks - Fred

> Sent: Tuesday, December 11, 2007 12:41 PM
> considerations, but IANA
> > > I would like to contribute as well but want more 
> discussion to take
> > place.
> >