Subject: [manet] Re: New DSR Draft

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Apr 2002 13:51:39 +0300 (EEST)

On Sat, 23 Feb 2002, Pekka Savola wrote:
> I'll try to give more concrete feedback within some weeks but I'm not sure
> if that's going to help any as the basic assumptions seem to vary quite a
> bit.

Hello,

I promised I'd come back with more comments.  Some are just my thoughts I 
tried to scribble down when reading the draft.  Hope they help..

- I'm a bit unsure what happens if a packet which has a DSR header but 
also has piggybacked data is in send/maintenance queue.  Is this possible?  
These could in some cases perhaps lead to data being delivered more than 
once to the destination.

- I didn't get a good picture which DSR options can be seen in the same 
DSR header and which not.  Also, as sections in chapter 5 list what IP 
header fields would look like when there are multiple options in a packet, 
the multi-option combinations seem to be less covered than their full 
counterparts.

Some comments based on the text.

1. Introduction

[...] Each data packet sent then carries in its header the
   complete, ordered list of nodes through which the packet will pass,
   allowing packet routing to be trivially loop-free and avoiding the 
   need for up-to-date routing information in the intermediate nodes  
   through which the packet is forwarded. [...]

==> the need for up-to-date information may not necessarily be a bad 
thing.  Now the sources are in charge of that.  Moreover, the sources are 
also in charge of the whole network, as their source routes will be cached 
and used for other communications.

This is quite effective, but can be very dangerous in case of e.g.  
implementation bugs, unforeseen problems (e.g. a source getting out of
sync, and "competing with the cache" with the rest of manet nodes) and
such: one node can pretty much wreck the whole routing fabric without even
trying hard.

[...]  For
   example, DSR does not use any periodic routing advertisement, link
   status sensing, or neighbor detection packets, and does not rely on  
   these functions from any underlying protocols in the network.  This
   entirely on-demand behavior and lack of periodic activity allows
   the number of overhead packets caused by DSR to scale all the way
   down to zero, [...]

==> I see DSR header functions rather equivalent to link status sensing 
(maintenance procedures, Send Queue, etc.) and others above.

   In response to a single Route Discovery (as well as through routing
   information from other packets overheard), a node may learn and cache
   multiple routes to any destination.

==> just a trivial comment: cache management strategies will be quite 
critical.

3.1. Basic DSR Route Discovery

   Node E could instead simply reverse the sequence of hops in the route
   record that it is trying to send in the Route Reply, and use this as 
   the source route on the packet carrying the Route Reply itself.  For 
   MAC protocols such as IEEE 802.11 that require a bidirectional frame 
   exchange as part of the MAC protocol [11], the discovered source
   route MUST be reversed in this way to return the Route Reply since it
   tests the discovered route to ensure it is bidirectional before the  
   Route Discovery initiator begins using the route; this route reversal
   also avoids the overhead of a possible second Route Discovery.

==> This (and various other places in the text, e.g. Appendix A) assumes 
that the link-layer technology, at least from the point of view of 
directionality, must be the same all over the manet, or at least all manet 
nodes know the directionality of each device.

This seems a rather big aasumption.

   When initiating a Route Discovery, the sending node saves a copy of  
   the original packet (that triggered the Discovery) in a local buffer 
   called the "Send Buffer".

==> might this create extra delays in the case of Route Discoveries 
failing too (e.g. link failure, no manet nodes/AP's temporarily in range, 
...) ?

4.1. Route Cache

    -  In DSR, the route returned in each Route Reply that is received
	by the initiator of a Route Discovery (or that is learned from
	the header of overhead packets, as described in Section 6.1.4)
       represents a complete path (a sequence of links) leading to the  
 	destination node.  By caching each of these paths separately,
       a "path cache" organization for the Route Cache can be formed.   
	A path cache is very simple to implement and easily guarantees
	that all routes are loop-free, since each individual route from
       a Route Reply or Route Request or used in a packet is loop-free.
   
==> as pointed above, this puts quite much trust on the sender's cache 
data/cache being up-to-date.  A normal security procedure would be to 
verify received loop-freeness, but here normal security procedures might 
not apply...

5. DSR Header Format

   To add a DSR header to a packet, the DSR header is inserted following
   the packet's IP header, before any following header such as a
   traditional (e.g., TCP or UDP) transport layer header.  Specifically,
   the Protocol field in the IP header is used to indicate that a DSR
   header follows the IP header, and the Next Header field in the DSR
   header is used to indicate the type of protocol header (such as a
   transport layer header) following the DSR header.

==> this has strong implications if packet filtering is perfomed.  First, 
almost all packets will be discarded unless the packet filter/firewall 
supports DSR header processing and has some extra semantics on how to 
proceed past the first, DSR header.  This is similar to issues associated 
with IPv6 packet filtering..

6.2.2. Processing a Received Route Request Option

- [...]  If the node does
       not receive a Reply within some reasonable amount of time, MUST
	silently discard the Route Request packet.

==> perhaps this should be defined more precisely?

	o  If the node does not return a cached Route Reply, then this
           node SHOULD link-layer re-broadcast this copy of the packet,
           with a short jitter delay before the broadcast is sent.  The
           jitter period SHOULD be chosen as a random period, uniformly
           distributed between 0 and BroadcastJitter.

==> is it required that all possible media should support link-layer 
broadcasts?

6.3.6. Salvaging a Packet

   When an intermediate node forwarding a packet detects through Route  
   Maintenance that the next-hop link along the route for that packet is
   broken (Section 6.3), if the node has another route to the packet's  
   IP Destination Address in its Route Cache, the node SHOULD "salvage"
   the packet rather than discarding it.

==> s/discarding/discard/ ?

11. Security Considerations

==> nodes feeding wrong (out-of-date) information, acting by their best
knowledge?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

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