Subject: Re: [manet] draft-ietf-manet-aodvv2-12 and draft-ietf-manet-dlep-17

From: [email-masked]
Date: Thu, 3 Dec 2015 12:37:09 +0100

Victoria,

> On Nov 19, 2015, at 17:09, Victoria Mercieca <[email-masked]> wrote:
> Hi Thomas and Christopher,
> Thank you for your comments.  If I may address just one point for starters - regeneration vs forwarding. We use the term regeneration since forwarding seems inappropriate when the message content changes at each hop.
> 
> The changes we make to the message content are:
> 
> 1) We change the metric so that each router along the path learns a route from the message, with the metric associated with the path up to that point
> 2) AckReq only applies between hops, so needs to be removed at each hop, and a new AckReq element may need to be added for the next hop.
> 3) ValidityTime could potentially be added by any intermediate router that wishes to limit the time it will forward packets on the route.
> 4) Stripping out Unreachable Addresses from RERR which did not affect our route set.
> 
> Can we really use the term "forwarding" if we are changing the metric value, adding a validity time, adding/removing AckReq or removing addresses and their associated TLVs?
> 
> Further, in reply to the comment about use of the msg-hop-count and msg-hop-limit fields, I think it does not matter that a message only travels one hop in that particular form, with that exact set of information enclosed. Hop limit and hop count are part of the message and used by the routing protocol, and so they refer to the multi-hop path that the AODVv2 message will follow, indicating when not to regenerate any further. So AODVv2 uses these fields as suggested in RFC5444 Appendix B, to limit the number of hops across which it will regenerate a packet so as to "prevent messages from endlessly circulating in a MANET”.
> 

Mmmh…based on what you describe in the above: 

	1)	a router receiving a control message may chose to respond by doing any 
		(and possibly more than one) of:

			a)	ignore the message
			b)	process the message
			c)	generate a new control message, possibly integrating the state
				acquired through b.

	2)	consequently, your protocol control messages are only ever exchanged 
		between neighboring routers

1c) is what you call “regenerate” a control message - akin to any other DV protocol, which (possibly) shares its distance vector with its neighbors after having processed a received message. 

While I’m not sure that I particularly like the word “regenerate”, I’m not too hung up on that — but, at the very least it does deserve a precise definition somewhere in the specification since, at least, I stumbled over its interpretation.

But, either way, as according to your model messages are never forwarded, but always are intended for receipt by a router which is a direct neighbor, then a <msg-hop-limit>  >1 (which applies to the message) seems inappropriate. 

Actually, according to that model, I would even say that receipt of a message with a <msg-hop-count>  >1 should be interpreted as a malfunction.

As you refer to RFC5444 appendix B, do note that Appendix B of RFC5444 (and, note the errata 4003) talks about:

      <msg-hop-limit> field, if present, contains the number of hops on
      which the message is allowed to travel before being discarded by a
      MANET router.  The <msg-hop-limit> is set by the message
      originator and is used to prevent messages from endlessly
      circulating in a MANET. 

Specifically “set by the message originator” and “number of hops on which the message is allowed to travel” — with your control messages traveling just one hop, I believe that setting <msg-hop-limit> = 1 is correct.

Best,

Thomas
> Kind regards,
> Victoria.
> 
> 
> On Wed, Nov 18, 2015 at 8:49 AM, Christopher Dearlove <[email-masked] <mailto:[email-masked]>> wrote:
> I've not had time to look at either yet, though I hope to review DLEP very soon.
> 
> But this has made me think about the RFC 6621 reference in AODVv2. It's always been clear this has been rather a throwaway comment that needed thought, but until now I hadn't really given it any.
> 
> And it doesn't work. RFC 6621 is fundamentally unusable here. Let's consider each on turn. 
> 
> AODVv2 is in the RFC 5444 structure. As has been noted on many occasions, AOVDVv2 gets to use messages, but packets are not in its competence.
> 
> RFC 6621 is about packets. But not even RFC 5444 packets but IP packets. It's about whether or not to forward them. But RFC 5444 packets aren't just not forwarded in unchanged IP packets, they aren't even forwarded at all. They are each a single hop construct, and if a message is forwarded (which is by the routing protocol, as far as RFC 5444 is concerned, it's a new message) it will be in a new packet, with possibly new companions.
> 
> If AODVv2 wants to use a more efficient flooding process, it needs one at the message level. Now an example of that exists - the mechanism on RFC 7181. Unfortunately we didn't break that out as a separate draft (we would have liked to, but there were reasons we didn't).
> 
> And even if (by reference or other means) it were used - or some related mechanism such as a CDS - that processing/forwarding mechanism assumes you have defined MPRs (or similarly, that you have defined a CDS). And that needs a local exchange of information, such as NHDP's HELLO messages (and the rest of NHDP) augmented with RFC 7181's MPR TLV (though only the flooding bit is needed).
> 
> In other words, taking some real work to define. And also raising a question for the WG - why do we want a reactive protocol? The main attraction as I see it is the "if you're not doing anything, you're not transmitting" property. Which adding this voids. Of course maybe the WG doesn't value that. Or it is acceptable as an option. But if so it needs to be an option that all routers use, or none. And if all, compatibly. (MPR flooding allows different MPR selection algorithms - but only as long as they satisfy the fundamental MPR algorithm properties.)
> 
> In short, RFC 6621 must go. The alternative is nothing, or significant work.
> 
> --  
> Christopher Dearlove
> [email-masked] <mailto:[email-masked]> (iPhone)
> [email-masked] <mailto:[email-masked]> (home)
> 
> On 18 Nov 2015, at 01:35, Thomas Clausen <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Dear all,
>> 
>> I have started looking through the recently updated draft-ietf-manet-aodvv2-12. A lot has changed, and I regret not to have had a blow-by-bow comeback to the previous review comments  - would have made it a somewhat easier task to check if all have been addressed or not.
>> 
>> But, I will work through it and produce a detailed review - but from my first quick read-through there're a couple of issue that jumped at me as worth bringing forward on a more global level already.
>> 
>> The first relates to  how RREQs are forwarded -- or, more generally, are not.
>> 
>> The protocol currently talks about "message is regenerated" rather than "forwarded". I have understood that this means that a RREQ is actually not an "end to end" entity, but is a "hop by hop" entity. 
>> 
>> First, that is a curious design choice, is there any reason why this is so considered?
>> 
>> Second, if a RREQ message is hop-by-hop only, then I do not think that the use of the RFC5444 hop-limit/hop-count fields is appropriate.
>> 
>> Third, the statement in section 6.5 on the use of RFC6621 is incorrect in two ways: RFC6621 does specify how messages are *forwarded* (but, as discussed above, you are not forwarding messages).
>> 
>> More seriously, this paragraph is incorrect:
>> 
>>> "Implementations MAY choose to employ techniques to reduce the number of multicast messages sent. Use of [RFC6621 <https://tools.ietf.org/html/rfc6621>] in deployments is recommended. Employing [RFC6621 <https://tools.ietf.org/html/rfc6621>] in a subset of the operational AODVv2 routers in a network, or configuring different algorithms on different routers, will not cause interoperability issues, but will reduce the effectiveness of the multicast reduction scheme."
>> 
>> 
>> Different routers using different relay selection algorithms in the same network will not *just* cause loss of efficiency, but *will* cause interoperability issues.
>> 
>> For example if "router A" decides to suppress its message relaying because it estimates that "router B" provides sufficient coverage - and conversely "router B" suppresses relaying for the same reason: neither A nor B would relay, and so any routers reachable only via A and B would not be covered.
>> 
>> This is not a far-sought example: it can be as simple as A and B simply using self-selecting relay algorithms with different tie-breakers.
>> 
>> In short: I think that the whole message flooding/regeneration part requires serious work.
>> 
>> The second issue is that I also suspect that there is some issue with buffering, or rather with how it is specified; starting in section 6.6, I am not sure that leaving that as "a matter of policy at each router" is entirely right. 
>> 
>> Also on buffering, I am wondering if the "start delivering buffered packets" conditions (penultimate paragraph in 6.6, and of course through the processing sections) is sufficient; I suspect that the condition "When a valid route is installed" is not sufficient - that there are situations where a routing table entry is installed, but the complete route is not available or is not bidirectional?This obviously is related to RREP_Ack being hop-by-hop and not end-to-end....
>> 
>> Either way, the parts of the specification that relate to buffering contain a mixture of normative and non-normative verbiage (a lot of "can" but also a lot of MUST/SHOULD) which I think could do with a tightening up. 
>> 
>> But....is buffering even something that should be specified by this document? It does not impact interoperability and it interferes substantially with transport and congestion control, and I am not sure that we understand the consequences (I am not convinced that the claims in the document on benefits to TCP are substantiated or even true).
>> 
>> As I indicated, a complete review will follow, but I thought that these was a global enough topics to call out and get engineered right.
>> 
>> Thomas
>> 
>> PS: I remain convinced that the security considerations section is insufficient ; I will try to articulate my thoughts on why that is, but for starters looking at the recently raised (by somebody else, the Chris replied) AODV security questions would probably be helpful
>> 
>> On 10 Nov 2015, at 02:10, Ratliff, Stanley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Hello WG participants –
>>> 
>>>  
>>> 
>>> The above referenced drafts were posted Oct. 13 (for AODVv2), and Oct. 16 (DLEP). The co-authors and the chairs ask that you please take some time to review and comment on the new submissions.
>>> 
>>>  
>>> 
>>> Regards,
>>> 
>>> Stan
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 
>>> _____________________________________________________
>>> This electronic message and any files transmitted with it contains
>>> information from iDirect, which may be privileged, proprietary
>>> and/or confidential. It is intended solely for the use of the individual
>>> or entity to whom they are addressed. If you are not the original
>>> recipient or the person responsible for delivering the email to the
>>> intended recipient, be advised that you have received this email
>>> in error, and that any use, dissemination, forwarding, printing, or
>>> copying of this email is strictly prohibited. If you received this email
>>> in error, please delete it and immediately notify the sender.
>>> _____________________________________________________
>>> _______________________________________________
>>> manet mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>> _______________________________________________
>> manet mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> 
> _______________________________________________
> manet mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> 
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: [email-masked]
Date: Thu, 3 Dec 2015 13:21:55 +0100

Dear Victoria,

Responding twice to this email, intentionally as I want to address two different aspects independently….

> Can we really use the term "forwarding" if we are changing the metric value, adding a validity time, adding/removing AckReq or removing addresses and their associated TLVs?
OK, so assume that I understand regeneration as per my previous email, as meaning “generate a new message and send to my neighbors, based on what I learned when processing a received message” — just like any distance vector protocol does.

In that model, what you write makes sense: each originator of a control message (i.e., whoever generates or regenerates it) is free to include the information it desires, such as the 4 points you list above. No issues with that.

However, and this joins what I pointed out in a previous email, you write in the applicability statement:

   Providing security for a reactive routing protocol can be difficult.

While we can discuss if the nature of “reactive routing protocol” generates particular difficulties, we certainly can agree that this protocol has the same “difficulties” as a distance vector protocol: routing topology information (by definition) not being exchanged end-to-end, but between neighbors (who do calculations and generate their own announcements — regeneration, as you call it). 

This means that a specific security model of transitive trust must be assumed, no? I trust Victoria, therefore when Victoria says “Stan told me” then I trust that she actually verified that "it was indeed Stan who told her …” — and either way, I have no way of verifying?

I did not see the trust model / trust assumption discussed in the specification (specifically not in applicability and in section 13, both of where it should be called out), but I think that this is actually a crucial point to get right, in order to approach developing the MTI security mechanisms.

Anyways, that observation actually contrasts strongly with what the applicability statement then goes on to say, namely:

   AODVv2 provides for message integrity and security against replay
   attacks by using integrity check values, timestamps and sequence
   numbers, as described in Section 13 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-12#section-13>.

This is true only in as much as messages are indeed exchanged between neighbors: when you “regenerate” a message, i.e., generate a new message in response to receipt of a message, you generate brand new payload (but possibly including some of the data from the received message, of course): thus, any ICVs “from farther away than the neighbor” will be useless (or, if you zero out the parts that you change, these parts will not be protected).

The above sentence, quoted from the applicability statement, and that which transpires from section 13, seems - certainly, absent the trust model assumed - to suggest that end-to-end protection/validation is provided. But, this is not the case.

Finally to the applicability statement, a question:

   If security associations can be
   established, encryption can be used for AODVv2 messages to ensure
   that only trusted routers participate in routing operations.

What you want to say here is that “if all trusted routers have a shared secret, then we’re able to use that shared secret to ignore non-trusted routers”, right? 
While “security associations” that do not pass through a shared secret probably can be thought up, it’s not trivial and I did not find any discussion of that in the document?

Having, on the topic of security, re-read Section 13, which starts:

   This section describes various security considerations and potential
   avenues to secure AODVv2 routing.  

While this is an honest description of what follows, I remain convinced that this is not sufficient. So let me ask as precisely as I can:

	o	what is the MTI security mechanism that a conformant implementation must provide? 
		Specifically:
			-	which are the processing steps (for example in section 7.2.1 
				and section 7.2.2 for RREP - and similarly for the other message 
				types) that define that security mechanism

	o	what protection is offered by that MTI security mechanism? And what remains
		vulnerable.

If this specification targets std.track, then it should include (reasonably solid, but definitely well specified) MTI security.

Best

Thomas

> Further, in reply to the comment about use of the msg-hop-count and msg-hop-limit fields, I think it does not matter that a message only travels one hop in that particular form, with that exact set of information enclosed. Hop limit and hop count are part of the message and used by the routing protocol, and so they refer to the multi-hop path that the AODVv2 message will follow, indicating when not to regenerate any further. So AODVv2 uses these fields as suggested in RFC5444 Appendix B, to limit the number of hops across which it will regenerate a packet so as to "prevent messages from endlessly circulating in a MANET".
> 
> Kind regards,
> Victoria.
> 
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 3 Dec 2015 13:26:22 +0000

If you go down this route of assuming transitive trust, then you might as well use 7182’s packet ICV and timestamp rather than message ICV and timestamp.

There is a complication (mostly one of presentation) that the 5444 multiplexer (rather than AODVv2) needs to do this, at least for packets containing AODVv2 messages (but at which point, probably all 5444 packets). So you either, depending on your point of view, need to request it to do that, or (administratively) decline to operate except over a 5444 multiplexer that is doing this.

The advantage is one of saved space and time when packets contain more than one message. Plus slightly better protection (hop count and limit are covered) but which probably doesn’t matter here.

If messages are changed/replaced on a one-to-one basis as forwarded, then the only solutions I can see are hop by hop transitive trust (packets or messages per hop), or something complicated involving aggregation and knowledge of changes. But the latter would be a research task to develop, so let’s not try that.

From: manet [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 December 2015 12:22
To: Victoria Mercieca
Cc: manet
Subject: Re: [manet] draft-ietf-manet-aodvv2-12 and draft-ietf-manet-dlep-17

Dear Victoria,

On Nov 19, 2015, at 17:09, Victoria Mercieca <[email-masked]<mailto:[email-masked]>> wrote:

   numbers, as described in Section 13<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-12#section-13>.

Best

Thomas

On Wed, Nov 18, 2015 at 8:49 AM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
I've not had time to look at either yet, though I hope to review DLEP very soon.

In short, RFC 6621 must go. The alternative is nothing, or significant work.
--
Christopher Dearlove
[email-masked]<mailto:[email-masked]> (iPhone)
[email-masked]<mailto:[email-masked]> (home)

On 18 Nov 2015, at 01:35, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

"Implementations MAY choose to employ techniques to reduce the number of multicast messages sent. Use of [RFC6621<https://tools.ietf.org/html/rfc6621>] in deployments is recommended. Employing [RFC6621<https://tools.ietf.org/html/rfc6621>] in a subset of the operational AODVv2 routers in a network, or configuring different algorithms on different routers, will not cause interoperability issues, but will reduce the effectiveness of the multicast reduction scheme."

Thomas

On 10 Nov 2015, at 02:10, Ratliff, Stanley <[email-masked]<mailto:[email-masked]>> wrote:
Hello WG participants –

Regards,
Stan

[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 3 Dec 2015 14:53:32 +0100

That is exactly the thing -  the trust model assumed (& the protocol mechanics) need to be understood before designing the necessary MTI security, and before deciding which bits (if any) from 7182 to use...

Thomas

> On 3 déc. 2015, at 14:26, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
>    numbers, as described in Section 13.
> 
> On Wed, Nov 18, 2015 at 8:49 AM, Christopher Dearlove <[email-masked]> wrote:
> [email-masked] (iPhone)
> [email-masked] (home)
> 
> On 18 Nov 2015, at 01:35, Thomas Clausen <[email-masked]> wrote:
> 
> Dear all,
>  
> "Implementations MAY choose to employ techniques to reduce the number of multicast messages sent. Use of [RFC6621] in deployments is recommended. Employing [RFC6621] in a subset of the operational AODVv2 routers in a network, or configuring different algorithms on different routers, will not cause interoperability issues, but will reduce the effectiveness of the multicast reduction scheme."
>  
> On 10 Nov 2015, at 02:10, Ratliff, Stanley <[email-masked]> wrote:
> 
> Hello WG participants –
>

---

From: Jiazi YI <[email-masked]>
Date: Thu, 3 Dec 2015 22:42:43 +0100

I agree with Chris and Thomas on their concerns on the hop-by-hop security
issue.

This is very different from classical DV protocol, in which the vector
information is designed to be exchanged between neighbours.
In AODVv2, the RREQ/RREP/RERR are to be forwarded through multiple hops. A
router can sign a message that isn't actually initialised by itself -- this
is, at least, against intuition.

This can be an issue if we have compromised routers in the network. Of
course, a compromised router is a problem for every protocol, like OLSRv2.
But in OLSRv2, a compromised router can only speak on behalf of itself --
however, in AODVv2, a compromised/mis-configured router can pretend to be
any other router (for example, generate RREQ messages using another address
as OrigAddr).  The consequence will be much more serious if that happens.

best

Jiazi

On Thu, Dec 3, 2015 at 2:53 PM, Thomas Heide Clausen <[email-masked]
> wrote:

> That is exactly the thing -  the trust model assumed (& the protocol
> mechanics) need to be understood before designing the necessary MTI
> security, and before deciding which bits (if any) from 7182 to use...
>
> Thomas
>
> If you go down this route of assuming transitive trust, then you might as
> well use 7182’s packet ICV and timestamp rather than message ICV and
> timestamp.
>
>
>
> There is a complication (mostly one of presentation) that the 5444
> multiplexer (rather than AODVv2) needs to do this, at least for packets
> containing AODVv2 messages (but at which point, probably all 5444 packets).
> So you either, depending on your point of view, need to request it to do
> that, or (administratively) decline to operate except over a 5444
> multiplexer that is doing this.
>
>
>
> The advantage is one of saved space and time when packets contain more
> than one message. Plus slightly better protection (hop count and limit are
> covered) but which probably doesn’t matter here.
>
>
>
> If messages are changed/replaced on a one-to-one basis as forwarded, then
> the only solutions I can see are hop by hop transitive trust (packets or
> messages per hop), or something complicated involving aggregation and
> knowledge of changes. But the latter would be a research task to develop,
> so let’s not try that.
>
>
>
>
>
> *From:* manet [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> *Sent:* 03 December 2015 12:22
> *To:* Victoria Mercieca
> *Cc:* manet
> *Subject:* Re: [manet] draft-ietf-manet-aodvv2-12 and
> draft-ietf-manet-dlep-17
>
>
>
> Dear Victoria,
>
>
>
> Thank you for your comments.  If I may address just one point for starters
> - regeneration vs forwarding. We use the term regeneration since forwarding
> seems inappropriate when the message content changes at each hop.
>
> 1) We change the metric so that each router along the path learns a route
> from the message, with the metric associated with the path up to that point
> 2) AckReq only applies between hops, so needs to be removed at each hop,
> and a new AckReq element may need to be added for the next hop.
> 3) ValidityTime could potentially be added by any intermediate router that
> wishes to limit the time it will forward packets on the route.
> Can we really use the term "forwarding" if we are changing the metric
> value, adding a validity time, adding/removing AckReq or removing addresses
> and their associated TLVs?
>
> OK, so assume that I understand regeneration as per my previous email, as
> meaning “generate a new message and send to my neighbors, based on what I
> learned when processing a received message” — just like any distance vector
> protocol does.
>
>
>
> In that model, what you write makes sense: each originator of a control
> message (i.e., whoever generates or regenerates it) is free to include the
> information it desires, such as the 4 points you list above. No issues with
> that.
>
>
>
> The above sentence, quoted from the applicability statement, and that which transpires from section 13, seems - certainly, absent the trust model assumed - to suggest that end-to-end protection/validation is provided. But, this is *not* the case.
>
>
> What you want to say here is that “if all trusted routers have a shared
> secret, then we’re able to use that shared secret to ignore non-trusted
> routers”, right?
>
> While “security associations” that do not pass through a shared secret
> probably can be thought up, it’s not trivial and I did not find any
> discussion of that in the document?
>
>
>
> While this is an honest description of what follows, I remain convinced
> that this is not sufficient. So let me ask as precisely as I can:
>
>
>
>                                                 and section 7.2.2 for
> RREP - and similarly for the other message
>
>                                                 types) that define that
> security mechanism
>
>
>
> If this specification targets std.track, then it should include
> (reasonably solid, but definitely well specified) MTI security.
>
>
>
> Best
>
>
>
> Thomas
>
>
>
> Further, in reply to the comment about use of the msg-hop-count and
> msg-hop-limit fields, I think it does not matter that a message only
> travels one hop in that particular form, with that exact set of information
> enclosed. Hop limit and hop count are part of the message and used by the
> routing protocol, and so they refer to the multi-hop path that the AODVv2
> message will follow, indicating when not to regenerate any further. So
> AODVv2 uses these fields as suggested in RFC5444 Appendix B, to limit the
> number of hops across which it will regenerate a packet so as to "prevent
> messages from endlessly circulating in a MANET".
>
> Kind regards,
> Victoria.
>
>
>
> But this has made me think about the RFC 6621 reference in AODVv2. It's
> always been clear this has been rather a throwaway comment that needed
> thought, but until now I hadn't really given it any.
>
>
>
> AODVv2 is in the RFC 5444 structure. As has been noted on many occasions,
> AOVDVv2 gets to use messages, but packets are not in its competence.
>
>
>
> RFC 6621 is about packets. But not even RFC 5444 packets but IP packets.
> It's about whether or not to forward them. But RFC 5444 packets aren't just
> not forwarded in unchanged IP packets, they aren't even forwarded at all.
> They are each a single hop construct, and if a message is forwarded (which
> is by the routing protocol, as far as RFC 5444 is concerned, it's a new
> message) it will be in a new packet, with possibly new companions.
>
>
>
> If AODVv2 wants to use a more efficient flooding process, it needs one at
> the message level. Now an example of that exists - the mechanism on RFC
> 7181. Unfortunately we didn't break that out as a separate draft (we would
> have liked to, but there were reasons we didn't).
>
>
>
> And even if (by reference or other means) it were used - or some related
> mechanism such as a CDS - that processing/forwarding mechanism assumes you
> have defined MPRs (or similarly, that you have defined a CDS). And that
> needs a local exchange of information, such as NHDP's HELLO messages (and
> the rest of NHDP) augmented with RFC 7181's MPR TLV (though only the
> flooding bit is needed).
>
>
>
> In other words, taking some real work to define. And also raising a
> question for the WG - why do we want a reactive protocol? The main
> attraction as I see it is the "if you're not doing anything, you're not
> transmitting" property. Which adding this voids. Of course maybe the WG
> doesn't value that. Or it is acceptable as an option. But if so it needs to
> be an option that all routers use, or none. And if all, compatibly. (MPR
> flooding allows different MPR selection algorithms - but only as long as
> they satisfy the fundamental MPR algorithm properties.)
>
>
>
> I have started looking through the recently
> updated draft-ietf-manet-aodvv2-12. A lot has changed, and I regret not to
> have had a blow-by-bow comeback to the previous review comments  - would
> have made it a somewhat easier task to check if all have been addressed or
> not.
>
>
>
> But, I will work through it and produce a detailed review - but from my
> first quick read-through there're a couple of issue that jumped at me as
> worth bringing forward on a more global level already.
>
>
>
> The protocol currently talks about "message is regenerated" rather than
> "forwarded". I have understood that this means that a RREQ is actually not
> an "end to end" entity, but is a "hop by hop" entity.
>
>
>
> Second, if a RREQ message is hop-by-hop only, then I do not think that the
> use of the RFC5444 hop-limit/hop-count fields is appropriate.
>
>
>
> Third, the statement in section 6.5 on the use of RFC6621 is incorrect in
> two ways: RFC6621 does specify how messages are *forwarded* (but, as
> discussed above, you are not forwarding messages).
>
>
>
> Different routers using different relay selection algorithms in the same
> network will not *just* cause loss of efficiency, but *will* cause
> interoperability issues.
>
>
>
> For example if "router A" decides to suppress its message relaying because
> it estimates that "router B" provides sufficient coverage - and conversely
> "router B" suppresses relaying for the same reason: neither A nor B would
> relay, and so any routers reachable only via A and B would not be covered.
>
>
>
> This is not a far-sought example: it can be as simple as A and B simply
> using self-selecting relay algorithms with different tie-breakers.
>
>
>
> The second issue is that I also suspect that there is some issue with
> buffering, or rather with how it is specified; starting in section 6.6, I
> am not sure that leaving that as "a matter of policy at each router" is
> entirely right.
>
>
>
> Also on buffering, I am wondering if the "start delivering buffered
> packets" conditions (penultimate paragraph in 6.6, and of course through
> the processing sections) is sufficient; I suspect that the condition "When
> a valid route is installed" is not sufficient - that there are situations
> where a routing table entry is installed, but the complete route is not
> available or is not bidirectional?This obviously is related to RREP_Ack
> being hop-by-hop and not end-to-end....
>
>
>
> Either way, the parts of the specification that relate to buffering
> contain a mixture of normative and non-normative verbiage (a lot of "can"
> but also a lot of MUST/SHOULD) which I think could do with a tightening up.
>
>
>
> But....is buffering even something that should be specified by this
> document? It does not impact interoperability and it interferes
> substantially with transport and congestion control, and I am not sure that
> we understand the consequences (I am not convinced that the claims in the
> document on benefits to TCP are substantiated or even true).
>
>
>
> As I indicated, a complete review will follow, but I thought that these
> was a global enough topics to call out and get engineered right.
>
>
>
> Thomas
>
>
>
> PS: I remain convinced that the security considerations section is
> insufficient ; I will try to articulate my thoughts on why that is, but for
> starters looking at the recently raised (by somebody else, the Chris
> replied) AODV security questions would probably be helpful
>
>
> The above referenced drafts were posted Oct. 13 (for AODVv2), and Oct. 16
> (DLEP). The co-authors and the chairs ask that you please take some time to
> review and comment on the new submissions.
>
>
>
> Regards,
>
> Stan
>
>
>
>
>
>

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Dec 2015 21:53:53 +0000

In OLSRv2 a compromised router can only speak for itself if ICVs are linked to specific routers. Use a shared secret key (as RFC 7183) then a compromised router can impersonate any router. draft-ietf-manet-ibs is however an example where it can't.

> On 3 Dec 2015, at 21:42, Jiazi YI <[email-masked]> wrote:
> 
> I agree with Chris and Thomas on their concerns on the hop-by-hop security issue. 
> 
> This is very different from classical DV protocol, in which the vector information is designed to be exchanged between neighbours. 
> In AODVv2, the RREQ/RREP/RERR are to be forwarded through multiple hops. A router can sign a message that isn't actually initialised by itself -- this is, at least, against intuition. 
> 
> This can be an issue if we have compromised routers in the network. Of course, a compromised router is a problem for every protocol, like OLSRv2. But in OLSRv2, a compromised router can only speak on behalf of itself -- however, in AODVv2, a compromised/mis-configured router can pretend to be any other router (for example, generate RREQ messages using another address as OrigAddr).  The consequence will be much more serious if that happens. 
> 
> best
> 
> Jiazi
> 
> 
>> On Thu, Dec 3, 2015 at 2:53 PM, Thomas Heide Clausen <[email-masked]> wrote:

---

From: Jiazi YI <[email-masked]>
Date: Thu, 3 Dec 2015 23:10:39 +0100

Sure. thanks for making it more precise :)

Jiazi

On Thu, Dec 3, 2015 at 10:53 PM, Christopher Dearlove <
[email-masked]> wrote:

> In OLSRv2 a compromised router can only speak for itself if ICVs are
> linked to specific routers. Use a shared secret key (as RFC 7183) then a
> compromised router can impersonate any router. draft-ietf-manet-ibs is
> however an example where it can't.
>
> --
> Christopher Dearlove
>> Thank you for your comments.  If I may address just one point for
>> starters - regeneration vs forwarding. We use the term regeneration since
>> forwarding seems inappropriate when the message content changes at each hop.
>>
>> 3) ValidityTime could potentially be added by any intermediate router
>> that wishes to limit the time it will forward packets on the route.
>> Second, if a RREQ message is hop-by-hop only, then I do not think that
>> the use of the RFC5444 hop-limit/hop-count fields is appropriate.
>>
>>
>>
>> For example if "router A" decides to suppress its message relaying
>> because it estimates that "router B" provides sufficient coverage - and
>> conversely "router B" suppresses relaying for the same reason: neither A
>> nor B would relay, and so any routers reachable only via A and B would not
>> be covered.
>>
>>
>>