Subject: [RTG-DIR] RtgDir Review: draft-avula-shwmp-01

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 18:18:04 +0200

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: 		draft-avula-shwmp-01
Reviewer: 		Thomas Heide Clausen
Review Date: 		2014/03/31
IETF LC End Date: 	Unknown
Intended Status: 	Experimental

Summary:

	o	I have significant concerns about this document and recommend that the 
		Routing ADs discuss these issues further with the authors.

Comments:

	The document is actually hard to review. I happen to know HWMP and IEEE802.11s better than
	I am proud to admit in public, which helps a little - but, setting this aside, it is clear that this
	specification is written for somebody knowing at least as much about IEEE 802.11s as the authors.

	The document was briefly discussed in the MANET working group, the 
	relevant thread can be found here:

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

	The document could do with an editorial pass to clean up some language-related issues which,
	occasionally, renders the text ambiguous. I am not a native English speaker myself, so far be
	it for me to be overly critical, but I had a hard time parsing every other sentence in section 3, for 
	example.

	Finally, I am not a security expert; I am raising things that I encounter and according to my
	understanding of security, but it probably would be wise to have a careful review from
	security folks also. I do believe that the approach chosen is certainly not evolutive, and
	that - to me - is a show-stopper.

	The status of this document is "experimental" and, as such, it should encourage "experiments".
	The RTG ADs generally request a section documenting "what is the experiments that this 
	document is supposed to enable?", and I see none.

	This document relates to an IEEE developed L2 protocol, and is an independent stream submission.
	
	At the very least, given that we do not know what the interaction between this protocol, and other
	IEEE 802.11 protocol components, some text in an applicability statement should disclaim that 
	this protocol should operate only in a well-defined and confined area on the edge of the Internet.

Major Issues:

	o	This document proposes a security mechanism for HWMP, the mesh-under routing protocol developed by
		the IEEE for IEEE 802.11 networks. I see several issues with this:

		-	The IETF does not, typically, design or publish L2 protocols. I wonder if 
			it is not more beneficial to bring this work to the relevant groups of the IEEE?
			I do not believe that it is the mandate of the IETF or the RFC series to
			maintain and update IEEE specifications.

		-	In case there is an explicit reason why the authors have brought this to
			the IETF, such as heavy reliance on L3 or higher mechanisms/protocols,
			this should be called out explicitly in the document. While I do not want to be
			a "pedant for formalities", I'd have expected an "applicability section" or something
			in the document, which explained this.

	o	The IEEE 802 suite of specifications already contains a sizeable amount
		of efforts on security, and IEEE 802.11s (from which HWMP originates) did work
		on security. It is actually unclear what exactly the extension to HWMP, presented
		in this specification, brings that is not already covered. In other words, it is not convincing
		in which way an IEEE 802.11s deployment with HWMP is vulnerable, but where SHWMP
		is invulnerable.

	o	Continuing on from that, "external attacks", apparently, are something that end-to-end
		encryption schemes can prevent, and this is what (according to the authors) IEEE 802.1x 
		offers (section 2.1). It is not clear what an "external attack" is...is this a matter of
		a (non-participating) device being able to intercept data traffic, or is this a matter of a
		(not-participating) device being able to inject HWMP control traffic into the network, and
		to thereby disrupt it?

	o	This document is not including the usual RFC2119-terminology disclaimer; in
		addition, it leaves many - if not most - of the used terminology undefined. To give an
		example "internal attack" vs "external attack". 

	o	Section 2 states:
			   HWMP is the basic
			   routing protocol of a WMN and this paper discusses the protection of
			   HWMP routing messages but not the data messages.

		Which is materially wrong. HWMP is the basic routing protocol in IEEE 802.11s; 
		there're many other mesh routing protocols out there, many of which are widely 
		deployed.
		Also, this is not a "paper", but a protocol specification.

	o	As with "external attacks", it is not clear either what the "internal attacks" that the authors 
		assert that SHWMP protects against are. Section 2.1:

			   The major problem that is plaguing the WMNs is the detection of
			   internal attacks. Internal attacks might involve modification of
			   contents of the HWMP frame such as hop count and air time metric.

		I am not sure that wireless mesh networks are "plagued" by this, but that aside...would that
		not imply that somehow admission to the network has been granted (cryptographic material/key
		provided) to somebody, who then turns around and then "attacks" the network? If so, then
		my initial reaction would be that if detected, the right approach would be to revoke the keys
		issued to the "badly behaving device". It is not clear how SHWMP interacts with any key 
		management and revocation functions in an IEEE 802.11 network.

	o	Continuing through section 2.1, essentially what this document is saying is:

			o	It's easy to protect protocol signals which are immutable, or to
				protect immutable fields in protocol signals, against tampering

			o	It's problematic to protect mutable fields in protocol signals, against 
				tampering

			o	....but, it's important to do so.

		While one might not take huge issues  with the first two, the third doesn't follow. 
		What is missing, IMO, is  some sort of problem statement, including a security 
		analysis. If a mutable field is tampered with, how does that hurt? Will the system
		break down? Perform a little worse? A lot worse? 

		This section ends by saying:

				   However,
				   the fields that get changed is quite important to provide link-to-
				   link based security so that every node along the journey should
				   authenticate the frame before passing it on. This ensures that the
				   contents of the frame are not modified and the frames can get dropped
				   if they are modified.

		Three things.

			1)	The language is ambiguous: "The fields that get changed [by whom? 
				intentionally or the attacker] is [should be are] quite important to provide 
				link-to-link based security [so, is the important bit that "The value of the fields 
				is what HWMP uses fir providing link-to-link based security"? Or, is the important 
				bit that these fields are not changed, and the security mechanism should prevent 
				this] [also, what is link-to-link base security]?

			2)	OK, so I understand: the goal is to provide hop-by-hop authentication of a frame.
				That implies a specific trust model of the form "I trust my neighbor to only trust 
				neighbors that I would also have trusted", which is not documented. Is that model
				valid in this type of networks?

			3)	If 3) is indeed is a valid trust model, what does the solution proposed actually
				do? If my neighbor  has the right cryptographic material to generate the
				signatures needed, then he can tamper with any and all fields, unchallenged and
				undetected. In other words, is this approach protecting against the "internal
				attacks" intended?

	o	But then I read on to section 2.2, and to my surprise see that what I had identified in 2.1 
		was not at all true - at least, it doesn't read that way. Section 2.2 is entitled "Security
		features of Secure HWMP", but reading that - after having read 2.1 - I still want to understand
		the (at least, abstract) answers to four simple questions:

			a)	What are the identified vulnerabilities of HWMP, which SHWMP patches?
			b)	What is the trust model assumed?
			c)	How does that trust model match actual deployments?
			d)	How does SHWMP integrate with IEEE 802 security mechanisms, key mgmt, ...?

	o	Section 3, I believe that before starting to discuss the extension, a presentation of
		HWMP would be in order, at least the necessary details for the reader to understand the
		rest of the document. As it is, it is understandable to those who have a pretty good idea 
		of the functioning of HWMP only. As it is, and after reading section 3, I would suggest
		that the reader is as confused as to what HWMP is, what SHWMP does, and how.

	o	Section 3, 4 I believe that the bulk of the HWMP terminology used should actually,
		be defined in the terminology section - and that the terminology section therefore
		belongs before Section 3.

	o	Section 3, and section 6.1:

			o	what does it mean that the "source node signs the non-mutable fields"?
	
		How are the signatures generated, how are mutable fields treated (Zeroed out? Removed? Something else?)

	o	Section 5 is missing definition of which byte-order, bit-order is used, as well as for 
		each field what format (unsigned integer, ...) the values are in.

	o	Section 5 is missing some discussion as to how these messages are intended to be included in the
		frame format of IEEE 802.11. Does that format already have a mechanism for protocol extensions?
		If so, does the format for these extensions "fit in"? How?
		Are there any requirements for code-point reservations with the IEEE? Have those been made?
		How will those be made? Will experimental code-points from IEEE maintained registries be used?

	o	I am not sure if the last sentence on page 10 in section 5.5 should/does not mark the start
		of a new paragraph. It seems to talk about "all the message types" and not just the GANN message type
		described immediately previously.

	o	Generally, and specifically to section 6, it might be good to provide a reference to HWMP, 
		which SHWMP is extending;
		it is not enough to simply cite the IEEE standard. If I was to implement this, I would want
		to know more, including:
			o	Which specific parts of the (voluminous) 802.11 standard need I study?
			o	Which specific processing steps need I to interface with, iow., the operations
				described in this specification are to be done before/after which steps in which
				process in which section of IEEE 802.11

		As it is, I could not implement this proposed extension to SHWMP in a fashion where I would
		be sure to (i) do it right, and (ii) do it in a way that would be interoperable with somebody elses'
		implementation.

	o	As this is a security document, I would expect a complete and strong security considerations section. 
		As indicated in the above, I believe that - at least - what is missing is:

			o	Relationship to 802.1x and other 802 security mechanisms
			o	Trust model
			o	Protections offered
			o	Specifically, protections not offered
			o	Limits of cryptographic methods recommended
			o	Ability to evolve - threats on networks tend to not be static

	o	I have a MAJOR-MAJOR issue related to the cryptological tools used. I am not enough of an 
		expert in crypto to know which exact parameters are required to be carried around for each
		algorithm, but.....for example, key indices, which parameters of a curve, or a function, are to
		be used, ..... -- all of which seems to be not specified, and perhaps should not be specified
		as it is part of some 802 security framework....but, in that case, it most certainly should be
		discussed.

		What I know, however, is that a cryptographic method that's "good" today is "worthless" 
		a few years, or even months, hence. I see no codepoints allowing identifying which
		(say) of RSA, DES, HMAC, ECDSA, AES, .... and whatever the future brings, is used? 
		Same for hash functions....not long ago md5 was used, today it's definitely not....

		At the very least, I would expect an IANA registry set up (or, references to an 802 registry)
		recording code-points for different algorithms - and the messages to contain fields for
		indicating which hash/crypto function to use.

Minor Issues:

Nits:

	o	I believe that it would behove the document if the abstract called out where HWMP has 
		come from, especially as it is not an IETF protocol, or even a L3 protocol

	o	References are not split up in Normative and Informative references, and (FWIW) are not formatted
		in the usual fashion.

	o	Section 3, 2nd paragraph: I believe that it would be beneficial to split this up in several independent
		paragraphs or, perhaps, an enumerated list. I ended up making the latter on a piece of paper to not
		get lost in the description.

Respectfully,

Thomas

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 31 Mar 2014 17:35:49 +0100

Thanks Thomas for a thorough job.

I read your review as not saying that there is any conflict with existing IETF
Rtg Area work, or that this document would damage Internet routing per se. But I
also see a lot of substantial technical work that the authors could pay
attention to, and a strong question that I should put to the ISE about why he
would publish this instead of referring it to the IEEE.

Is that a fair summary?

Cheers,
Adrian

> -----Original Message-----
> From: Thomas Clausen [mailto:[email-masked]]
> Sent: 31 March 2014 17:18
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RtgDir Review: draft-avula-shwmp-01
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
they
> pass through IETF last call and IESG review, and sometimes on special request.
> The purpose of the review is to provide assistance to the Routing ADs. For
more
> information about the Routing Directorate, please see
> http://www.ietf.org/iesg/directorate/routing.html
> 
> Although these comments are primarily for the use of the Routing ADs, it would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion or by
> updating the draft.
> 
> 	I am proud to admit in public, which helps a little - but, setting this
aside, it
> is clear that this
> 	specification is written for somebody knowing at least as much about
IEEE
> 802.11s as the authors.
> 	it for me to be overly critical, but I had a hard time parsing every
other
> sentence in section 3, for
> 	example.
> 
> 	Finally, I am not a security expert; I am raising things that I
encounter and
> according to my
> 	understanding of security, but it probably would be wise to have a
careful
> review from
> 	security folks also. I do believe that the approach chosen is certainly
not
> evolutive, and
> 			it is not more beneficial to bring this work to the
relevant
> groups of the IEEE?
> 			I do not believe that it is the mandate of the IETF or
the
> RFC series to
> 			this should be called out explicitly in the document.
While
> I do not want to be
> 		on security. It is actually unclear what exactly the extension
to
> HWMP, presented
> 		in this specification, brings that is not already covered. In
other
> words, it is not convincing
> 		offers (section 2.1). It is not clear what an "external attack"
is...is
> this a matter of
> 		a (non-participating) device being able to intercept data
traffic, or
> is this a matter of a
> 			   routing protocol of a WMN and this paper discusses
the
> protection of
> 	o	As with "external attacks", it is not clear either what the
"internal
> attacks" that the authors
> 		my initial reaction would be that if detected, the right
approach
> would be to revoke the keys
> 	o	Continuing through section 2.1, essentially what this document
is
> saying is:
> 		While one might not take huge issues  with the first two, the
third
> doesn't follow.
> 		analysis. If a mutable field is tampered with, how does that
hurt?
> Will the system
> 				   the fields that get changed is quite
important to
> provide link-to-
> 				   link based security so that every node along
the
> journey should
> 				   contents of the frame are not modified and
the
> frames can get dropped
> 				intentionally or the attacker] is [should be
are]
> quite important to provide
> 				link-to-link based security [so, is the
important bit
> that "The value of the fields
> 				is what HWMP uses fir providing link-to-link
based
> security"? Or, is the important
> 				That implies a specific trust model of the form
"I
> trust my neighbor to only trust
> 			3)	If 3) is indeed is a valid trust model, what
does the
> solution proposed actually
> 		was not at all true - at least, it doesn't read that way.
Section 2.2 is
> entitled "Security
> 	o	Section 3, I believe that before starting to discuss the
extension, a
> presentation of
> 		rest of the document. As it is, it is understandable to those
who
> have a pretty good idea
> 		How are the signatures generated, how are mutable fields
> treated (Zeroed out? Removed? Something else?)
> 
> 	o	Section 5 is missing definition of which byte-order, bit-order
is
> used, as well as for
> 		of a new paragraph. It seems to talk about "all the message
> types" and not just the GANN message type
> 		be sure to (i) do it right, and (ii) do it in a way that would
be
> interoperable with somebody elses'
> 		implementation.
> 
> 		As indicated in the above, I believe that - at least - what is
missing
> is:
> 		algorithm, but.....for example, key indices, which parameters of
a
> curve, or a function, are to
> 		as it is part of some 802 security framework....but, in that
case, it
> most certainly should be
> 	o	I believe that it would behove the document if the abstract
called
> out where HWMP has
> 		come from, especially as it is not an IETF protocol, or even a
L3
> protocol
> 	o	Section 3, 2nd paragraph: I believe that it would be beneficial
to
> split this up in several independent

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 18:41:46 +0200

Adrian,

Your summary is fair.

Essentially, this is an extension to a L2 protocol. By definition, there's therefore no conflict with existing IETF RTG Area work. I would vividly recommend the ISE to refer the work to the IEEE.

Thomas