Subject: [manet] Regarding the reactive protocol development - again

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 6 Mar 2014 17:48:47 +0100

All,

I have been requested to - one last time - iterate my comments to the reactive protocol, currently being discussed by the working group. 

Somebody *very* persuasive twisted my arm and convinced me to do so - but I do not write "one last time" lightly: this is the one last shot.

First, I would like to direct your attention to this posting from me, which is from 2010, and which was a review of a predecessor to the current document. 

	 http://www.ietf.org/mail-archive/web/manet/current/msg11858.html

All my comments, and issues raised, in that review (and in other reviews since then) still apply to the current document - now 4 years later. 
I have reminded the WG about this review several times, as late as in November 2013.

I shall, in the below, reiterate the key points that I have made in review quoted above, as well as (as appropriate) add new issues or update the issues that I have previously raised. I strongly encourage the WG to look at the details in the review from 2010. 

Unfortunately, given that the protocol is vastly underspecified and ridden with options (that also are underspecified), this list probably is not exhaustive, but it was what I could extract from the specification as written:

	o	I am confused by the use of square brackets around stuff: usually, [FOO] refers to
		a reference in the References section, but this is not systematically the case in this
		document (both in the prose and in the notation (cf. Table 1).

	o	I found the document rather hard to read, in part due to the terminology used.
		The Terminology section states that it uses "some terminology from [RFC5444]",
		but is not explicit as to what. RFC5444 defines terms such as packet/message,
		both of which are used in this document in (I think) manners inconsistent with
		their definitions in RFC5444. I'll point out a couple of examples of this in the
		below, but the terminology use should be cleaned up through the document
		to be consistent with RFC5444. I think that as RFC5444 and this document
		are both products of the MANET wg, and that this document uses RFC5444,
		then the terminology should be perfectly aligned with the terminology from 
		RFC5444 (I have not seen overruling reasons otherwise in the document).

	o	While we are on the terminology, "packet" appears to be used both to describe
		(i) a RFC5444 packet, (ii) a protocol data unit for this protocol, and (iii) an IP 
		datagram. 
		
	o	There is an awful lot of places where different terminology is used for the same 
		concept, e.g. "target" vs. "destination" and "source" vs. "originator" etc. Unless
		these are truly different concepts, then I would suggest consistency so as to
		make the text easier to read and less ambiguous. Some of these terms, but
		not all, are define.

	o	While we are on that, I notice that "active source" is used; I am not sure what 
		that is vs a "source" and vs a PktSource. A source is someone who generates
		data traffic, I would suspect ... so an active source is....what?  Or, is a source
		someone who can, but doesn't, generate data traffic? - if so, what is the significance
		of that wrt. routing protocol operation? And, wrt a /reactive/ routing protocol, which
		I would assume constructs routes only for active source-destination pairs?

	o	I have a very simple mind, and I like bullet-point-pseudocode over 
		"textual pseudocode". E.g something like this is more readable to me:

				Upon receiving an RREQ, a router:
					1.	Record X;
					2.	Record Y;
					3.	If z then:
							o	Do FOO;
						otherwise:
							o	Do BAR;
					4.	Retransmit the RREQ

		The way in which this document is written is very confusing: if I was to implement the processing
		of an incoming RREQ message, which section should I implement? 7.5 would seem to be the 
		place to start, and it gives and ordered list of things to do. Except it says...

		In this section (unless qualified by additional description such as
		"upstream" or "neighboring") all occurrences of the term "router"
		refer to the AODVv2 router handling the received RteMsg.

		So, off to chase what "upstream" and "neighboring" mean. Whoops, "upstream" is not defined. One
		interpretation would be that it would be "the next hop towards a gateway to..." something. But to what?
		Another interpretation would be "the next hop towards the source of the RteMsg", but as this is part
		of the route discovery process, I probably do not know what that would be. Or, is it "the best next-hop
		towards the source of the RteMsg that I know so far?" Or ...

		Section 5.2 says:

		To avoid repeated failure of Route Discovery, an AODVv2 router
		(HandlingRtr) handling a RREP message SHOULD attempt to verify
		connectivity to the next upstream router towards AODVv2 router
		originating an RREQ message.

		So for the case when an RteMsg is an RREP, then I could make a guess that "upstream" means "next hop 
		towards the source of the corresponding RREQ message". Except Section 7.5 probably also applies to
		RREQs. So off chasing if there is a rule covering that, also, and guessing what that rule might mean too.

		I've only just started to determine if I am to be processing a given RteMsg, and I am already at a loss for
		how to proceed, and have had to guess (hoping, of course, to both guess RIGHT and guess as other
		implementers, with whom I would hope to be interoperable, would guess).

		This is but one example - but, it applies for all such processes and procedures. The document is 
		vague and underspecified through and through, and not a solid basis for generating independent
		and interoperable implementations of this protocol.

		Another case of underspecification (and I am not pointing them all out, these are just examples 
		of some of the most flagrant cases): what does "relevant" mean in the below? 

		   Whenever an AODVv2 router (HandlingRtr)
		   handles an incoming RteMsg (i.e., RREQ or RREP), for every relevant
		   address (RteMsg.Address) in the RteMsg ...

		How is an implementer supposed to determine with which addresses (if any) processing is to be 
		undertaken?

		And one more:

					 Suppose Route[RteMsg.Address] uses the same metric type as the
 		   incoming routing information, and the route entry contains
		   Route.SeqNum, Route.Metric, and Route.Broken.  Suppose the incoming ...

		This is a protocol specification, "supposing" is not supposed to happen - unambiguous instructions that
		does not require the implementer to undertake guesswork is required.

		This *specification* is ripe with such instances of ambiguities and - as I have indicated in many, many, many
		previous reviews, requires a very through rework and complete rewrite. Then, and only then, can we
		start understanding if the *protocol* itself has problems.

	o	Related to the above point, an awful lot of the document is optional, as exemplified by the below:

		To avoid repeated failure of Route Discovery, an AODVv2 router
		(HandlingRtr) handling a RREP message SHOULD attempt to verify
		connectivity to the next upstream router towards AODVv2 router
		originating an RREQ message. This MAY be done by including the
		Acknowledgement Request (AckReq) message TLV (see Section 15.2) in
		the RREP.  Any unicast packet will satisfy the Acknowledgement
		Request, for example an ICMP REPLY message.  If the verification is
		not received within UNICAST_MESSAGE_SENT_TIMEOUT, HandlingRtr SHOULD
		put the upstream neighbor in the blacklist. 

		So I have a (2119-languague) "SHOULD" telling me to "attempt to verify connectivity". Then a (again,
		2119-language) "MAY" suggesting to accomplish that by sending an AckReq. 

		It's a MAY - therefore, I know (as it's 2119-language) that I do not have to do that, send that message. 
		But I still SHOULD "attempt to verify connectivity", so how do I do that?

		It's not clear what it means that any "unicast packet will satisfy the Acknowledgement Request"
		(which I decided to not send, as that was a MAY), nor is it clear how the routing process will get access
		to any such unicast packet (assuming, that is, that said unicast packet isn't destined for that process). 

		Also, I am apparently supposed to receive a "verification" before some timeout. Search as I may, I have
		not found anything indicating where that "verification" is generated, I see no messages defined to this
		effect, nor any processing allowing me to infer it.

		Again, this is an example of underspecification, that leaves each implementation to "guess and
		interpret" how to proceed - rather than provide an unambiguous process to follow to ensure
		interoperability.

		And this is only ONE from among MANY examples of such in this specification. Here's another from section 8.2:

		   AODVv2 routers SHOULD monitor connectivity to adjacent routers along
		   active routes.  This monitoring can be accomplished by one or several
		   mechanisms, including:
	
		   o  Neighborhood discovery [RFC6130]
		   o  Route timeout
		   o  Lower layer trigger that a link is broken
		   o  TCP timeouts
		   o  Promiscuous listening
		   o  Other monitoring mechanisms or heuristics

		   If a next-hop AODVv2 router has become unreachable, RERR_Gen follows
		   the procedures specified in Section 8.3.2.

		So, I will implement this protocol using RFC6130, since I happen to have an implementation of RFC6130 around. 
		My next-door-neighbor, Francois, also implements this protocol - but he doesn't have an RFC6130 implementation
		around, and therefore uses "route timeout". As Francois and I both are lazy, of course, we implement only
		one mechanism each (this is allowed, according to the text).

		As Francois' implementation doesn't generate RFC6130 HELLOs, for all intents and purposes he doesn't
		exist to my implementation, which will establish that no connectivity to him exists.

		We've both followed the specification to the letter, implemented all the SHOULD and MUST - and yet, we can't
		interoperate.

		I am *NOT* walking through the entire specification and pointing out every single such situation, and how each
		ambiguity and underspecification can lead to non-interoperable implementations that otherwise can claim to be
		implementing this specification: there simply are too many. 

		I have called upon the authors of this specification, for four years now, to walk through the document and 
		work through these to clarify and render the specification complete and unambiguous. 

	o	EVEN WORSE: I searched through the document for AckReq and Acknowledgement Request, and I
		actually do not see any instructions telling me how to implement the code for processing this. So, 
		this specification allows (MAY) me to send an AckReq - but doesn't tell me how to process it or
		how to act when receiving it.
		
		Again, this is an example of underspecification, that leaves each implementation to "guess and
		interpret" how to proceed - rather than provide an unambiguous process to follow to ensure
		interoperability.

		And this is only ONE from among MANY examples of such in this specification.

	o	It seems that the protocol does not support routers with multiple interfaces. There is this
		paragraph in the applicability statement, which indicates that it is an insurmountable problem
		for the authors to address:

		Multi-homing is difficult unless the sequence number is expanded to
		include the AODVv2 router's IP address as well as SeqNum.  Otherwise,
		comparing sequence numbers would not work to evaluate freshness.
		Even when the IP address is included, there isn't a good way to
		compare sequence numbers from different IP addresses, but at least a
		handling node can determine whether the two given sequence numbers
		are comparable.  If the route table can store multiple routes for the
		same destination, then multi-homing can work with sequence numbers
		augmented by IP addresses.

		Worse, though, after reading this paragraph in the applicability statement, I actually still do not understand
		if this protocol can - or, can not - be used on routers with multiple interfaces.

		The applicability statement, also, reads:

					AODVv2 supports routers with
		multiple interfaces, as long as each interface has its own (unicast
		routeable) IP address; the set of all network interfaces supporting
		AODVv2 is administratively configured in a list (namely,
		AODVv2_INTERFACES).

		which seems to be at odds with the previously quoted paragraph. So, I still do not know where the protocol
		applies.

		This is not unrelated to the next issue....

	o	In a great many places, it is stated "IP address of the (node, Adjacent Node, Adjacent Router) sending the message". 
		If a router has multiple interfaces, and/or if these interfaces have multiple addresses,
		which of these (any? one matching the interface over which the message is sent?)
		should be used or assumed here? The relationship node/interface/address is, at best, unclear.
	
		It seems to me that this specification is written with the assumption that each router has *exactly* one
		interface participating in the routing protocol, with *exactly* one IP address - and that that router *never*
		use anything but that IP Address for anything.

		If that is correct, then it should be written clearly in the applicability statement that multiple interfaces
		and multiple addresses are *NOT* supported, and that this protocol MUST NOT be used in deployments
		where any router can have more than one interface or more than one IP Address.

		If that's not true, then a major rework of the protocol and the specification is required.

		This is also not unrelated to the next issue....

	o	I find the use of "node" unfortunate. I would much prefer "router", as this is a
		protocol running between routers. This applies both in the text and in the 
		"terminology mnemonics". I note that the text sometimes uses "router" and 
		sometimes "node", and it is not clear that/if there is a difference, or if there
		should be a difference. The word "Router Client" is also used (albeit inconsistently capitalized)
		as is "client".

		An application running on a host has very, very specific expectations as to how the underlying
		IP link behaves. Applications "Expect an IP Link that looks like an Ethernet". I believe that it was
		Dave Thaler that once said something like "don't expect Microsoft to rewrite their IP stack..." 
		Applications expect what they expect. Even, a protocol such as NDP, which an IPv6-host
		uses to (among other things) configure its interfaces has this expectation. Therefore, unless
		the goal is to explicitly not support general applications and general IP stacks, an appropriate 
		link model must be presented to hosts.

		Yes, links between MANET routers are not "looking like an Ethernet". That's quite alright, 
		as long as the *only* application seeing these "MANET links" is the routing application. 
		Expose the weirdness of "a MANET link" to an off-the-shelf app or protocol (such as NDP, 
		mDNS, ...), and unpredictable behaviour ensures.

		The way that other MANET routing protocols have taken is, to provide an IP hop isolation
		of the hosts (which run "off the shelf applications") from the "MANET links": in other words,
		a "regular IP link" ties the "host" to the "router" and the "router" then has one or more
		interfaces towards the "MANET links".

	o	There are a lot of places, where the IP forwarding engine and the routing protocol process
		interact - and, in surprising ways.

		First, there is the whole "react to failure to deliver an IP datagram due to not having
		an entry in the routing table, and by way of flooding control traffic", which is a formidable
		vector for making every router in the network participate in a DDOS attack.

		Second, from section 5.1:
				
		The route table entry is a conceptual data structure.
		Implementations may use any internal representation so long as it
		provides access to the information specified below.

				<snip>

		The route's state determines the operations that can be performed on
		the route table entry.  During use, an Active route is maintained
		continuously by AODVv2 and is considered to remain active as long as
		it is used at least once during every ACTIVE_INTERVAL.  When a route
		is no longer Active, it becomes an Idle route.  After an idle route
		remains Idle for MAX_IDLETIME, it becomes an Expired route.  An

		So, part of the data structures, maintained by this protocol, are the "route table entry", whose state depends on
		if a route is "used at least once during ..." -- i.e., the routing process must be notified every time a data packet 
		is being forwarded? I do not know for sure, but I am not sure that that's even possible to do on commodity 
		operating systems - but, it does appear to be rather inefficient, increasing per-packet processing overhead
		for a router?

		Section 8.1:
			 	  Before using a route to forward a packet, an AODVv2 router MUST check
   		the status of the route as follows.

		Does this imply that the operating system needs to also be modified to also consult with data-structures, 
		maintained internally by this protocol?

		The point here is not (necessarily) that it is bad to do so - but, it would be required that all such assumptions
		and requirements be called out in the applicability statement: "This protocol requires that the operating system
		permits you to do XXX, YYY, ZZZ". 

	o	Section 5.4:
			In order to reduce multicast overhead,
   	   retransmitting multicast packets in MANETs SHOULD be done according
	   to methods specified in [RFC6621]

		What happens if that "SHOULD" is not done? Does it break interoperability? Also, RFC6621 is not
		std.track, so this is a downref that requires special handling. I note that SHOULD is a fairly strong
		normative statement, but the RFC6621 is cited as an informational reference. This does not appear
		appropriate.

		And finally, RFC6621 specifies a number of different algorithms and modes of operation, some of which
		require additional signalling. For interoperable implementations to result, this is insufficient.

	o	I have a general concern about how this protocol imposes constraints on RFC5444 usage,
		which precludes co-existence with other RFC5444 protocols running on the same 
		device. 

		Let me give an example hereof, from Section 5.4:

		 		When multiple messages are aggregated into a single packet according
		to RFC 5444 formatting, and the aggregation of messages is also
		authenticated (e.g., with IPsec), and the IP destination is multiple
		hops away, it becomes infeasible to delete individual messages.  In
		such cases, instead of deleting individual messages, they are
		maintained in the aggregation of messages, but simply ignored for
		further processing.  In such cases where individual messages cannot
		be deleted, in this document "disregarded" means "ignored".
		Otherwise, any such "disregarded" AODVv2 messages SHOULD be deleted
		from the aggregated messages in the RFC 5444 packet.

		An RFC5444 packet is *never* to be sent more than one hop. Never forwarded. Never. A router 
		receives an RFC5444 packet, decapsulates it, process each message (if appropriate), the owner process
		of each message identifies which messages are to be forwarded (if appropriate), hands those off to the
		appropriate "message multiplexing engine" which packs those messages up in a new RFC5444 packet, 
		and transmits that new RFC5444 packet.

		Also, in RFC5444 messages, addresses are contained in address blocks. There is no semantics
		associated with an address being in one address block, or in another (in fact, (re-)organising addresses
		into address blocks is one of the tricks to use to obtain more compact messages). Likewise, there is
		no semantics associated with an address being first, last, or in any other position in an address block:
		the ordering of addresses in an address block carries no semantics.

		Therefore, writing something like this:

			RteMsg.Address[i] denotes the [i]th address in an RFC
	   5444 AddrBlk of the RteMsg.   RteMsg.PrefixLength[i] denotes the
	   associated prefix length for RteMsg.Address[i], and RteMsg.{field}
	   denotes the corresponding value in the named AddrTLV block associated
	   with RteMsg.Address[i].

		makes no sense whatsoever (aside from the fact that I do not understand the notation RteMsg.{field} - 
		that would indicate a "field" in a message, not in an attribute associated with an address). 

		Let me give one more example, from section 9:

	   If a message with an unknown type is received, the message is
	   disregarded.

		An implementation of this specification will (according to RFC5444) "own", and therefore get 
		messages that this protocol has gotten assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK. 
		Messages of any other Message Types will not (again, according to RFC5444) be delivered to
		an implementation of this protocol.

		Therefore, this protocol has no mandate, room, nor permission to specify discarding any message 
		types other than those than it "owns".

	o	Section 10, this is incorrect, at least as described, or at best *very* incomplete.

		What happens when router "inside the MANET" but just adjacent to the IAR issues a RREQ to a 
		destination inside the MANET? The IAR (presumably configured to answer to 0::/0) would reply 
		with an RREP.

		At the very least, the IAR MUST NOT reply to any RREQs, received on interfaces towards the MANET
		and for addresses belonging to a prefix covering the MANET. This is not sufficient, of course, but it
		is a step towards rendering this correct.

	o	The whole of section 13 must be removed, with the exception of section 13.6 which is already covered
		by RFC5444. All the other optional mechanisms are either underspecified, with known problems
		in common deployment topologies, or both. Further, they are clearly indicated as "not needed" so
		why are they included?

	o	Section 14.2 "Protocol Constants" contains a semantically null sentence

			AODVv2 protocol constants typically do not require changes

		A constant is constant, therefore it doesn't change. Even for very loose definitions of constant.
		With that being said, the interesting part here is actually not that bit...but rather, what happens
		*if* these are not set to the values that are indicated? Or, if different implementations use
		different values for these? The same holds for 14.2, btw: is a network able to operate with
		different routers setting different values? Will it break? Degrade gracefully? Just work? 

	o	Security Considerations

		First, there is the whole "react to failure to deliver an IP datagram due to not having
		an entry in the routing table, and by way of flooding control traffic", which is a formidable
		vector for making every router in the network participate in a DDOS attack.

	Second:

			 This section does not mandate any specific security measures.
	   Instead, this section describes various security considerations and
	   potential avenues to secure AODVv2 routing.

		If recent dealings with the SEC-ADs are to be believed, then this is not going to pass muster. At least,
		a "Mandatory to Implement" security mechanism is going to be required.

		Third, Quoting Chris Dearlove:
			"I'm just going to note that were the security considerations section in this draft regarded 
			 as adequate by the security ADs, then they would be applying very different standards to 
			 those they have applied to OLSRv2.

			 (I think that's easy to see as a factual statement by consulting the record of what they have 
			  required, and then noting that several of these things are not present in this draft. Note that 
			  in the case of OLSRv2 that has resulted in the production of additional documents. This are not 
			  just trivial additions either.)"
	
		Fourth:
				The most important security mechanisms for AODVv2 routing are
		integrity/authentication and confidentiality.

		In situations where routing information or router identity are
		suspect, integrity and authentication techniques SHOULD be applied to
		AODVv2 messages.  In these situations, routing information that is
		distributed over multiple hops SHOULD also verify the integrity and
		identity of information based on originator of the routing
		information.

			This is really difficult to do, in case messages are mutable in-transit, which appears to be the case for
			this protocol?  I think that this issue of mutable messages deserves being called out explicitly in this 
			section, especially if there are known or recommended ways of handling this (as is the case, for example, 
			in the security considerations section of RFC5444 regarding the mutable header fields for 
			hop-count/hop-limit of messages

As I indicated in the beginning: the protocol specification is ripe with things that are underspecified, vaguely specified, and options whose interactions are not well-defined. 

The above are examples of what is wrong - but not a complete list. 

This document is *far* from being publishable in its current shape, and a considerable effort is required to make it publishable - or, even, to make it into a shape where we can start evaluating if the actual protocol is a viable candidate for standardisation. It has been four years now, that I have requested that this effort be expanded on the document, and on its predecessor, to no avail.

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Mar 2014 20:49:32 +0000

On Thursday, March 6, 2014, Thomas Heide Clausen wrote:

> The way in which this document is written is very confusing:
>

I think the way written for the specification should be similar way of RFC
3561, that is important for interoperability purposes between both
specifications of AODVv2 and RFC3561. (I remember it was said while
developing the OLSRv2 draft to be similar structure of RFC3626).

Regards
AB

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 7 Mar 2014 22:04:31 +0100

Firstly, as far as I know, AODVv2 won't be interoperable with RFC 3561. 
Secondly, I think the reason of OLSRv2 having similar style of RFC 3626 is that, such style is easy to understand, and the WG decided to take that way. It's not the case for AODVv2 here. 

best

Jiazi

On 07 Mar 2014, at 21:49 , Abdussalam Baryun <[email-masked]> wrote:

> I think the way written for the specification should be similar way of RFC 3561, that is important for interoperability purposes between both specifications of AODVv2 and RFC3561. (I remember it was said while developing the OLSRv2 draft to be similar structure of RFC3626). 
> 
> Regards
> AB
> 
>  
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet