Subject: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items

From: [email-masked]
Date: Thu, 17 Mar 2016 17:00:18 +0100

Dear all,

Apologies for not having gotten this done sooner - day-job leaving few spare cycles.

I’ve previously offered reviews and comments, and some of those have been addressed in the latest I-D — others have not, but should be. I recall that there was some mail attempting to rebut parts of the review, and I will dig it out and reply to that.

With that being said, I have reviewed the latest version of the document, and full details will be forthcoming. There’re a couple of big-ticket/architectural items that I want to address up front, as I believe that before we have those hammered out, it will be useless to go into details. Note, I do not claim that this is an exhaustive list of “big ticket items”, but that’s as far as I have gotten in thinking this through.

I also bring these up as they are items that have been brought up repeatedly over the past years, but not resolved nor discussed.

Loops
Just to bring this out: I share Chris’ worry about conflicting and concurrent statements from the authors on “There are no loops possible” and “We need to fix two situations where loops can occur” and “we are still investigating some loop conditions”

I particularly worry that this is not a discussion had in public, but apparently in some other forum…

Intermediate Route Replies, and all of section 10
Section 10 contains a set of “vaguely specified extensions”, which is incoherent with the intended status indicated for this document. 

Specifically, and this is not unrelated to the point about loops above, intermediate RREPs (section 10.3) are a potential source for loops.

Expanding Ring Multicast (section 10.1) is not documented in a way that can be implemented (and also, see “Forwarding-vs-regeneration” below, it is in the present form of this protocol impossible), etc.

Forwarding-vs-regeneration
Recent exchanges on the list made me understand that protocol control messages are *not* forwarded, but are consumed at each hop, then a new message with (almost-but-not-quite) the same content is generated and transmitted.

I have thought some more on this (& read some of the exchanges on the list on this topic by Chris, Ulrich, and others), and I am convinced that this is not the right way to go, at least for the following reasons:

	o	It renders the hop-limit/hop-count fields in the RFC5444 message header useless.
		This would not be bad if the functionality offered by those fields was not useful
		— sadly, it is. For example, for scope limited flooding (expanding ring search, and 
		such) which may be of interest, and which require hop-limit. 
		A hop-count field may also provide a “cheap” (in terms of overhead) additional piece
		of information to use conjunctively with a “real” metric.

		The only practical solution would be to re-introduce these functions by way of inserting a
		MessageTLV — which (i) is not specified in this document, and (ii) which would just
		serve to render messages bigger than strictly needed.

		Scope limited flooding  does seem to be a necessary requirement, if for no
		other reason than to prevent information from “circulating forever in the network”.

	o	It makes end-to-end authentication unnecessarily hard.
		I think Chris called this out already, but it bears repeating: S generates a message 
		(say, a RREQ), and includes an ICV calculated over the content of the message.
		For any recipient to be able to validate the ICV, the message has to be exactly
		the same — not just in content, but in structure — as what was generated.

		“Regenerating” rather than “forwarding” messages means, that the intermediate
		router “regenerating” the RREQ may chose a different structure (e.g., include TLVs
		in a different order).

		The proposal from https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 <https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00>
		is to add constraints on (i) the set of elements to include in a signature and (ii) the
		order of these elements.

		One problem with that approach is (i): if an extension adds a message TLV, or an 
		Address TLV, to a message, then that will not be “covered” by the proposed e2esec TLV.
		Rather for *each* extension developed, an “updates e2esec” clause needs to be done.

		I’d say that this approach would be prone to errors — and add entropy to the process
		of designing protocol extensions. The alternative, a message being generated by the
		source and *forwarded* (as we do in OLSRv2, for example) would allow ICV TLVs 
		(even, allow reuse of those specified for OLSRv2) for covering a message and 
		extensions.

		“But what about the metrics value which will change on each hop”, you may say?
		Fortunately, that is relatively easy to handle: simply zero out the value of that TLV when
		generating or verifying the ICV MessageTLV. And use Packet-TLVs for hop-by-hop 
		authentication, if needed (but, see below).

	o	It prevents the use of more clever/advanced signature schemes/ICVs
		Aggregate signature algorithms ( https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf <https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf>)
		exist, and an interesting use-case can be found in also reactive protocols, allowing verifying
		not “just” the end points, but also the intermediaries (again, with the appropriate “zero out”
		discussed above, or something smarter).
		Regeneration of messages, rather than forwarding, renders that impossible (or, if used,
		updating to  https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 <https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00>)

There are other reasons, but the above are those that jump at me as immediate show-stoppers.

I do honestly not see what possible benefit there is from “regeneration” — but I see very clear inconveniences, and security is not the least of these. Insisting on “regeneration” requires development of “non-general workarounds” as pointed out above.

Security Considerations
This is an always thorny subject. When OLSRv2 was going through the process we got a thorough education in how little we knew about security from the SEC-ADs, and had to spend about a year or so developing RFC7183. The bottom line is, that this protocol needs its “RFC7183  equivalent”, either as part of the main document, or as an independent document. currently, that is not the case.

A minima, looking at BCP72 and BCP107 — taking inspiration from RFC7183 might be aw good idea, as that was the most recent that went through the SEC AD. Regardless of how, however, a “mandatory to implement” security mechanism most be specified (I think the right term was “MUST implement, SHOULD use”), in sufficient detail to ensure interoperable implementations.

As an example, both [RFC6130] and [RFC7181] set out that that:

      On receiving a ... message, a router MUST first check if the
      message is invalid for processing by this router

and then proceed to give a number of conditions that, each, will lead to a rejection of the message as "badly formed and therefore invalid for processing” — a list which RFC7183 then amended. That gave a “hook” for RFC7183 for inserting “rejection”. Idem for message generation.

If I was to do RFC7181/RFC6130 today, I would include that directly into the protocol specifications. It turned out to be more overhead (and slow down publication anyways) to do it as separate documents.

Secondly, we need to be a lot more rigid in terms of what ICVs, Timestamps, etc. are added/removed, and what that brings.

For example (with the assumption that messages are *forwarded* and *not* regenerated), this could be one option:

		o	When a RREQ, RREP message is generated, add an ICV Message TLV, which is calculated <this way>
			 …(take inspiration from RFC7183 here)

		o	When a RREQ, RREP message is transmitted  (by the source, or forwarded by an intermediary)
			in an RFC5444 packet, an ICV Packet TLV is added to the packet, which is calculated <this way> …

		o	When an RFC5444 packet is received, validate the ICV Packet TLV <this way> and if the ICV doesn’t validate,
			discard the contained messages.

		o	When receiving a RREQ/RREP (either as destination, or as an intermediary), validate the ICV Message TLV 
			<this way> and if the ICV doesn’t validate, discard the message, do not process, do not forward.

This is a different (and more flexible?) model than “just” transitive trust and “just” end-to-end trust discussed previously, and is enabled by the “forwarding” bit described previously.

Metrics
I have asked this numerous times, but have not gotten any answer so I am escalating this again. Why is this document having a normative reference to RFC6551?

   [RFC6551 <>]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551 <https://tools.ietf.org/html/rfc6551>, DOI 10.17487/
              RFC6551 <https://tools.ietf.org/html/rfc6551>, March 2012,
              <http://www.rfc-editor.org/info/rfc6551 <http://www.rfc-editor.org/info/rfc6551>>.

Unless I am mistaken, this is not the ROLL WG. And the abstract to RFC6551 explicitly reads:

   Low-Power and Lossy Networks (LLNs) have unique characteristics
   compared with traditional wired and ad hoc networks that require the
   specification of new routing metrics and constraints.  
Which explicitly is disclaiming that these metrics are not applicable in ad hoc networks — and, I am wondering, what has changed since the publication of RFC6551 to suddenly make these applicable?

 I am also wondering if looking at (and, perhaps, using?) the same metric type TLV type as in OLSRv2 is not a possibility?

Either way, referencing RFC6551 here is wrong.

RFC6621 (SMF) usage
As late as earlier this month, RFC6621 reared its head again on the mailing list. I understand that the authors are set on using flooding reduction as part of RREQ distribution. If that is the case, then this protocol MUST specify that flooding reduction. 

Saying “Use RFC6621” won’t work, for reasons Chris point out in an email earlier to the list:
> The network does not and fundamentally cannot offer multicast suppression to AODVv2. This isn't a hard concept, but seems to keep having to be said. AODVv2 messages are carried in 5444 packets, and those only travel one hop. That doesn't allow for suppression. Furthermore AODVv2 is creating new messages each hop. That needs AODVv2 specific handling.

And quoting an email from myself:
> If protocol X relies on using a flooding operation, then it certainly is protocol X's responsibility to  specify the flooding operation (or, at least, the requirements to the flooding operation ) for correct functioning of protocol X.

I’ve previously pointed out that RFC6621 requires some degree of configuration (can’t just, for example, pick two different relay set selection algorithms, as that may produce a disconnected flooding domain).

In other words, what the authors propose in https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00 <https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00> is insufficient.

Multiple interfaces configured with the same address(es) - & RFC6621
I think that it has been established that the ability to use the same address on multiple interfaces is a requirement. It’s not clear to me that a single way of doing so has been proposed, nor that the “operating conditions” are called out (for example, will it work  if router A and router B both have two interfaces, and that all 4 interfaces use the same IP address?)

This is not entirely unrelated to flooding reduction and RFC6621. One of the complexities is to get that just right: OLSRv2 - for example - calculates Flooding-MPRs per interface, and RFC6130 is careful in how it detects bidirectionality of links. 

I have not worked out all the details of how this impacts this protocol — but, it requires attention. Especially when wanting to be able to say “…use RFC6621”, then the interface configuration constraints when faced with multiple interfaces must be worked out.

Prefixes & Gateways
A question to my mind, and I am not sure I know how to answer that from reading the draft since it is not discussed in section 9 (at least), is: “What happens if I send a RREQ to a prefix” (i.e., a /<128 in IPv6)?

	o	If the whole prefix is part of the attached network set of a single router, 
		then I expect to get a single RREP back, is that the case?

	o	If "half the prefix"  is part of the attached network set of a single router, 
		and the other half is part of the attached network set of another  single router, 
		then I expect two RREPs, is that the case?

	o	More generally, will I get a tree build through the network here?

Section 9 (or, the whole spec) is also not explicit enough about multiple  "default gateways" — i.e., the external network being “the rest of the Internet”, and there being multiple gateways to the Internet. I understand how the RREQ gets to the gateway, and how the gateway determines if it should respond (the destination is not part of “the MANET prefix, with which it is configured”).

But, if A is close to GW1, and B is close to GW2, but A and B being far far apart (according to the metric used) within the MANET, then it would be preferential for the route from A to B to go via GW1-“the-Internet”-GW2? 

Is this a supported configuration? 
	o	If yes, how is it (seq# wise, I would expect some complications) handled? 
	o	If not, where is it stated that this configuration is not possible with this protocol?

The applicability statement says:

   AODVv2 is designed for stub or disconnected mobile ad hoc networks,
   i.e., non-transit networks or those not connected to the internet.
   AODVv2 can, however, be configured to perform gateway functions when
   attached to external networks, as discussed in Section 9 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-9>.

I believe that the scenario I describe is indeed a stub network (and not a transit network)?

— — — 

As I indicated, these are the big-picture issues that I have gotten around to thinking about enough to write up. I’m not through working through the document, but those were the ones that came to mind, and which seem imperative to resolve.

Best,

Thomas

---

From: Lotte Steenbrink <[email-masked]>
Date: Thu, 17 Mar 2016 17:25:06 +0100

Hi Thomas, 

> Am 17.03.2016 um 17:00 schrieb [email-masked]:
> 
> Dear all,
> 

Just one thing until I can go through your entire review: the conflict was between „There are no loops possible“ and „There were two loops possible and we’ve fixed them.“. I’ve written down the fixes for said loops under the description how they can occur.

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

---

From: [email-masked]
Date: Thu, 17 Mar 2016 18:15:30 +0100

> On 17 Mar 2016, at 17:25, Lotte Steenbrink <[email-masked]> wrote:
> 
> Hi Thomas, 
> 
>> Am 17.03.2016 um 17:00 schrieb [email-masked] <mailto:[email-masked]>:
>> 
>> Dear all,
>> 

On March 1, Perkins wrote:
> Other discussion about routing loops has not identified routing loop problems in the existing specification.  Use of unconfirmed or invalid routes for routing might lead to errors, but that doesn't carry over to produce loops in the route table.

On March 2, Chris wrote:
> My concerns have been that your co-authors have continued to discuss whether looping could occur since you published to the list saying all was well. (An issue to do with multiple unconfirmed routes.) Maybe that’s a problem, maybe it isn’t. But it lacks transparency, because it hasn’t been discussed here.

Which yesterday, March 16, you replied to by saying:
> The loop possibility you’re referring to was a different one than the one discussed by Charlie. We’ve been contacted by researchers who are model checking MANET protocols to see if they permit any unwanted behaviour. They’ve used AODVv2 as a case study for the framework they’ve implemented to do this, and they’ve found the following loop:

Of course, not being privy to non-mane-list-discussions,  all I can go by is public record. Which is that Perkins clearly affirmed (on the list) that there had been looping discussions, but no loop possibilities identified, on March 1, and you wrote March 16 that apparently there was another loop possibility discussed, brought t you by some researchers …

---

From: Lotte Steenbrink <[email-masked]>
Date: Sat, 19 Mar 2016 12:34:39 +0100

Hi Thomas,

> I’ve previously offered reviews and comments, and some of those have been addressed in the latest I-D — others have not, but should be. I recall that there was some mail attempting to rebut parts o…

That wold be great.

> Recent exchanges on the list made me understand that protocol control messages are *not* forwarded, but are consumed at each hop, then a new message with (almost-but-not-quite) the same content is…

That’s what we’ve been trying to say all along! I’m really glad we’re having this conversation.

> 		of information to use conjunctively with a “real” metric.

I agree on the usefulness, which is why we were puzzled when we were told we weren’t allowed to use those fields (or, rather, that we were using them wrong, but that the right way to use them doesn’t work for AODvv2). I believe Vicky has written about this in more detail in previous discussions, and we were/are looking forward to reading your answers...

> 		serve to render messages bigger than strictly needed.

Exactly; we’d really like to avoid this as well.

> 		other reason than to prevent information from “circulating forever in the network”.

AODVv2’s duplicated detection hopefully should take care of that. Iirc, We interpreted your earlier E-Mails to (implicitly) mean that you think we should rely on that, since you said we can’t use the hop-limit/hop-count fields.

> I do honestly not see what possible benefit there is from “regeneration” — but I see very clear inconveniences, and security is not the least of these. Insisting on “regeneration” requires developm…

The possible benefit is that we need to accumulate & transport metric values somehow, and we can’t do that without regenerating at least parts of the message.
If we’re missing a solution here, please share it with us.

> Security Considerations

Just for context’s sake, did you review the security considerations in draft-ietf-manet-aodvv2-13 or the ones proposed in the thread „AODVv2: Security considerations update“?

> 	o	More generally, will I get a tree build through the network here?

AODVv2 currently doesn’t support RREQs for prefixes. I’ve already added „If RteMsg is a RREQ, RteMsg.TargPrefixLen SHOULD equal address length.“ to RteMsg.TargPrefixLen in section 4.6 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-4.6>. Multicast Route Message Table in response to Justin’s comments, but I’ll go through the draft again and see where we need to state this more clearly.

Best regards,
Lotte Steenbrink

---

From: Jiazi YI <[email-masked]>
Date: Sun, 20 Mar 2016 23:53:47 +0100

>
> *Intermediate Route Replies, and all of section 10*
> Section 10 contains a set of “vaguely specified extensions”, which is
> incoherent with the intended status indicated for this document.
>
> Specifically, and this is not unrelated to the point about loops above,
> intermediate RREPs (section 10.3) are a potential source for loops.
>
> Expanding Ring Multicast (section 10.1) is not documented in a way that
> can be implemented (and also, see “Forwarding-vs-regeneration” below, it is
> in the present form of this protocol impossible), etc.
>

On those optional features, from the point of view of an engineer, I would
like to see:

   - how the features should be implemented. i.e., they should be clearly
specified.

   - What's the "benefit" of those features, as well as the "cost" -- for
example, message overhead, processing delay, complexity, etc., so that I
can decide if I need/should implement those features or not. If the
feature(s) has no cost but only benefit, it should go to the core
specification directly.

   - The interoperability with the implementations without the optional
features.

   - If the feature brings additional security threats. If yes, what's them
and how to mitigate them.

best

Jiazi

---

From: Justin Dean <[email-masked]>
Date: Tue, 22 Mar 2016 16:22:37 -0400

A few comments from me inline.

*Loops*
> Just to bring this out: I share Chris’ worry about conflicting and
> concurrent statements from the authors on “There are no loops possible” and
> “We need to fix two situations where loops can occur” and “we are still
> investigating some loop conditions”
>
> Discussions on list are key.  This needs to happen more.

> I'm all for removal of vaguely specified extensions.  The use of reduced
relay sets is one of those that should be cut at this time.  Expanding Ring
Multicast could be kept IMO.  It's not much different than the way OLSR
specifies that MPR selectors can be chosen in different ways but must cover
all the 2 hop neighbors.  Something as simple as.  If limited scope RREQ
are sent each successive RREQ for the same address MUST at least double the
hop count.

>
> *Forwarding-vs-regeneration*
> Recent exchanges on the list made me understand that protocol control
> messages are *not* forwarded, but are consumed at each hop, then a new
> message with (almost-but-not-quite) the same content is generated and
> transmitted.
>
> I have thought some more on this (& read some of the exchanges on the list
> on this topic by Chris, Ulrich, and others), and I am convinced that this
> is not the right way to go, *at least* for the following reasons:
>
>
> o *It renders the hop-limit/hop-count fields in the RFC5444 message
> header useless.*
> JWD: I partly disagree that it can't be used for this purpose.  RFC5444
specifies:
 <msg-hop-limit> is omitted if the mhashoplimit flag is cleared

      '0'); otherwise, is an 8-bit unsigned integer field that can
      contain the maximum number of hops that the message should be
      further transmitted.

which in retrospect was a mistake as 5444 was meant to be a format and not
a protocol specification as we mentioned many times.  No other  protocol
message is going to forward these messages as AODVv2 "owns" the message
type so I don't see an issue with bending the terms in 5444 to allow this
forwarding of "information"  The way multiplexers work messages can get
torn apart and sent back out in a different way.  My OLSRv2 with another
version will likely do just that.

o *It makes end-to-end authentication unnecessarily hard.*
> The proposal from
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
> o *It prevents the use of more clever/advanced signature schemes/ICVs*
> Aggregate signature algorithms (
> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
> updating to
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>
> JWD: this is IMO the big issue.

> I do honestly not see what possible benefit there is from “regeneration” —
> but I see very clear inconveniences, and security is not the least of
> these. Insisting on “regeneration” requires development of “non-general
> workarounds” as pointed out above.
>
> *Security Considerations*
> This is an always thorny subject. When OLSRv2 was going through the
> process we got a thorough education in how little we knew about security
> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
> The bottom line is, that this protocol needs its “RFC7183  equivalent”,
> either as part of the main document, or as an independent document.
> currently, that is not the case.
>
> A minima, looking at BCP72 and BCP107 — taking inspiration from RFC7183
> might be aw good idea, as that was the most recent that went through the
> SEC AD. Regardless of how, however, a “mandatory to implement” security
> mechanism most be specified (I think the right term was “MUST implement,
> SHOULD use”), in sufficient detail to ensure interoperable implementations.
>
> and then proceed to give a number of conditions that, each, will lead to a
> rejection of the message as "badly formed and therefore invalid for
> processing” — a list which RFC7183 then amended. That gave a “hook” for
> RFC7183 for inserting “rejection”. Idem for message generation.
>
> If I was to do RFC7181/RFC6130 today, I would include that directly into
> the protocol specifications. It turned out to be more overhead (and slow
> down publication anyways) to do it as separate documents.
>
> Secondly, we need to be a lot more rigid in terms of what ICVs,
> Timestamps, etc. are added/removed, and what that brings.
>
> o When receiving a RREQ/RREP (either as destination, or as an
> intermediary), validate the ICV Message TLV
> This is a different (and more flexible?) model than “just” transitive
> trust and “just” end-to-end trust discussed previously, and is enabled by
> the “forwarding” bit described previously.
>
> *Metrics*
> I have asked this numerous times, but have not gotten any answer so I am
> escalating this again. Why is this document having a normative reference to
> RFC6551?
>
>    [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
>               <http://www.rfc-editor.org/info/rfc6551>.
>
>
>
> Which explicitly is disclaiming that these metrics are* not applicable in
> ad hoc networks* — and, I am wondering, what has changed since the
> publication of RFC6551 to suddenly make these applicable?
>
>  I am also wondering if looking at (and, perhaps, using?) the same metric
> type TLV type as in OLSRv2 is not a possibility?
>
> *RFC6621 (SMF) usage*
> As late as earlier this month, RFC6621 reared its head again on the
> mailing list. I understand that the authors are set on using flooding
> reduction as part of RREQ distribution. If that is the case, then this
> protocol MUST specify that flooding reduction.
>
> The network does not and fundamentally cannot offer multicast suppression
> to AODVv2. This isn't a hard concept, but seems to keep having to be said.
> AODVv2 messages are carried in 5444 packets, and those only travel one hop.
> That doesn't allow for suppression. Furthermore AODVv2 is creating new
> messages each hop. That needs AODVv2 specific handling.
>
>
> If protocol X relies on using a flooding operation, then it certainly is
> protocol X's responsibility to  specify the flooding operation (or, at
> least, the requirements to the flooding operation ) for correct functioning
> of protocol X.
>
>
> I’ve previously pointed out that RFC6621 requires some degree of
> configuration (can’t just, for example, pick two different relay set
> selection algorithms, as that may produce a disconnected flooding domain).
>
> In other words, what the authors propose in
> https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00 is
> insufficient.
>
> JWD: I agree references to RFC6621 should be removed and use of reduced
relay sets should be work for an extension draft.  All that's is needed to
to allow AODVv2 routers to not regenerate RREQ which is already the case.

> *Multiple interfaces configured with the same address(es) - & RFC6621*
> I think that it has been established that the ability to use the same
> address on multiple interfaces is a requirement. It’s not clear to me that
> a single way of doing so has been proposed, nor that the “operating
> conditions” are called out (for example, will it work  if router A and
> router B both have two interfaces, and that all 4 interfaces use the same
> IP address?)
>
> This is not entirely unrelated to flooding reduction and RFC6621. One of
> the complexities is to get that just right: OLSRv2 - for example -
> calculates Flooding-MPRs per interface, and RFC6130 is careful in how it
> detects bidirectionality of links.
>
> I have not worked out all the details of how this impacts this protocol —
> but, it requires attention. Especially when wanting to be able to say “…use
> RFC6621”, then the interface configuration constraints when faced with
> multiple interfaces must be worked out.
>
> JWD: The super simple dumb way of doing this is to mandate that any
interface which shares an address with another much be bridged.  Then you
really only have a single interface again. Or just say it's not allowed.
Other more complex methods may be possible but we are honestly past time
for that and as Thomas points out there are corner cases that we will
likely miss and its past time for that.

> *Prefixes & Gateways*
> A question to my mind, and I am not sure I know how to answer that from
> reading the draft since it is not discussed in section 9 (at least), is:
> “What happens if I send a RREQ to a prefix” (i.e., a /<128 in IPv6)?
>
> JWD: I believe Lotte answered this in that it's not allowed.  Simple fix.

> Section 9 (or, the whole spec) is also not explicit enough about multiple
>  "default gateways" — i.e., the external network being “the rest of the
> Internet”, and there being multiple gateways to the Internet. I understand
> how the RREQ gets to the gateway, and how the gateway determines if it
> should respond (the destination is not part of “the MANET prefix, with
> which it is configured”).
>
> But, if A is close to GW1, and B is close to GW2, but A and B being far
> far apart (according to the metric used) within the MANET, then it would be
> preferential for the route from A to B to go via GW1-“the-Internet”-GW2?
>
> JWD: I'd change it to be configured to perform limited gateway functions
when attached to external networks.

> — — —
>
> As I indicated, these are the big-picture issues that I have gotten around
> to thinking about enough to write up. I’m not through working through the
> document, but those were the ones that came to mind, and which seem
> imperative to resolve.
>
> Best,
>
> Thomas
>
>
>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Mar 2016 21:36:41 +0100

I will get to the rest of your mail some other time, but one point...

> JWD: The super simple dumb way of doing this is to mandate that any interface which shares an address with another much be bridged.  Then you really only have a single interface again. Or just say it's not allowed.  Other more complex methods may be possible but we are honestly past time for that and as Thomas points out there are corner cases that we will likely miss and its past time for that.

You do simply not get to say that it is "past time" for this, given that I have been pointing the need for this to be resolved out, on the list, repeatedly and for ages -- only to have the authors ignore it.

To declare that "it is past time for that" when the issue in question has been raised in public and for a long time is, I believe, grounds for a process appeal.

Thomas

>>    attached to external networks, as discussed in Section 9.
>> 
> JWD: I'd change it to be configured to perform limited gateway functions when attached to external networks. 
>> — — — 
>>

---

From: Justin Dean <[email-masked]>
Date: Tue, 22 Mar 2016 20:51:25 +0000

I think you're misunderstanding my point. It's my opinion that it's past
time to come up with some elegant and complex solution to fix this issue.
Simple and safe solutions should be preferred as we'd likely miss
something. This is regardless of when the outstanding problem was first
raised.

Justin

On Tue, Mar 22, 2016, 4:36 PM Thomas Heide Clausen <[email-masked]>
wrote:

> You do simply not get to say that it is "past time" for this, given that I
> have been pointing the need for this to be resolved out, on the list,
> repeatedly and for ages -- only to have the authors ignore it.
>
> To declare that "it is past time for that" when the issue in question has
> been raised in public and for a long time is, I believe, grounds for a
> process appeal.
>
> Thomas
>
>
>
>> *Prefixes & Gateways*
>> As I indicated, these are the big-picture issues that I have gotten
>> around to thinking about enough to write up. I’m not through working
>> through the document, but those were the ones that came to mind, and which
>> seem imperative to resolve.
>>
>> Best,
>>
>> Thomas
>>
>>
>>
>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Mar 2016 22:04:36 +0100

> On 22 Mar 2016, at 21:51, Justin Dean <[email-masked]> wrote:
> 
> I think you're misunderstanding my point. It's my opinion that it's past time to come up with some elegant and complex solution to fix this issue. Simple and safe solutions should be preferred as we'd likely miss something. This is regardless of when the outstanding problem was first raised.
> 

My point is that it is an issue that must be addressed: the requirements that multiple interfaces can be sharing the same address is old, I have raised it multiple times over the years. OLSRv2 was built to support it. Henning reported an additional use case.

The WG chair suggesting to disallow it, or to "bridge it", is *not* solving the issue raised. It is the WG chair ignoring legitimate requirements from the WG, which does not strike me as aligned with proper process.

The WG chair saying "it is past time to solve" a long raised (and ignored) issue does not strike me as being aligned with proper process either.

Thomas

> Justin
> 
> 
>> On Tue, Mar 22, 2016, 4:36 PM Thomas Heide Clausen <[email-masked]> wrote:

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 23 Mar 2016 12:29:23 +0000

I’ve put the MANET list back on distribution.

As Thomas has pointed out to me, RFC 7182 is mandatory to implement as specified in RFC 7181. Thus “without ICVs” is not an option, and anything that breaks 7182 breaks compliance with 7181. And changing a message breaks 7181, in addition to it being directly indicated that messages are forwarded unchanged (hop count/limit aside).

Or in other words, OLSRv2 MUST NOT do this, and 5444 multiplexer MUST NOT change messages (as visible from protocol). I have an updated 5444 usage draft that makes this clearer for the multiplexer, waiting on co-authors to review.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: Justin Dean [mailto:[email-masked]]
Sent: 23 March 2016 12:23
To: Dearlove, Christopher (UK)
Subject: Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
CMD> I think this comes under the heading of “not prohibited but undesirable” but also that all options I can see involve something undesirable, or worse, so this may be the least undesirable
JWD: check.

JWD> The way multiplexers work messages can get torn apart and sent back out in a different way.  My OLSRv2 with another version will likely do just that.

CMD> Absolutely not, that is a violation of OLSRv2 rules and unacceptable, because OLSRv2 specifies forwarding messages unchanged. That completely breaks use of RFC 7182 message ICVs - which might be applied by the multiplexer. Please do not even consider this.
JWD: you are correct.  ICVs disallow this behavior.  In my own code the messages are not changed because I generated them in the first place.  Without ICVs though it's quite natural.  I've personally seen three different packetbb parsers (one my own) which by default will rearrange a message if processed and regenerated  (actually caused some headache when trying to debug and getting different generated message outputs).  If there are no ICVs and it doesn't matter, but that's throwing all of end to end security out the window.  End to end security is an issue.
********************************************************************
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: Justin Dean <[email-masked]>
Date: Wed, 23 Mar 2016 08:40:25 -0400

RFC 7182 is mandatory to RFC 7181.  In violent agreement.  OLSRv2 MUST NOT
do that.  5444 doesn't generate/forward messages though 7181 does.  Clearly
there should be a way for a process sitting on the multiplexer to tell it
that a message is immutable.  But in other cases a message does get
change/added to (e.g. 6121 (SMF) tlvs attached to 6130 (NHDP) hello
messages).  In the end we all seem to agree end-to-end security is a
problem currently for AODVv2.

Justin

On Wed, Mar 23, 2016 at 8:29 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> As Thomas has pointed out to me, RFC 7182 is mandatory to implement as
> specified in RFC 7181. Thus “without ICVs” is not an option, and anything
> that breaks 7182 breaks compliance with 7181. And changing a message breaks
> 7181, in addition to it being directly indicated that messages are
> forwarded unchanged (hop count/limit aside).
>
>
>
> Or in other words, OLSRv2 MUST NOT do this, and 5444 multiplexer MUST NOT
> change messages (as visible from protocol). I have an updated 5444 usage
> draft that makes this clearer for the multiplexer, waiting on co-authors to
> review.
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> www.baesystems.com/ai
> *From:* Justin Dean [mailto:[email-masked]]
> *Sent:* 23 March 2016 12:23
> *To:* Dearlove, Christopher (UK)
> *Subject:* Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of
> big ticket Items
>
>
>
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> * Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding **Red Flags** that you
> can look out for in emails you receive, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> CMD> I think this comes under the heading of “not prohibited but
> undesirable” but also that all options I can see involve something
> undesirable, or worse, so this may be the least undesirable
>
> JWD: check.
>
>
>
> JWD> The way multiplexers work messages can get torn apart and sent back
> out in a different way.  My OLSRv2 with another version will likely do just
> that.
>
> CMD> Absolutely not, that is a violation of OLSRv2 rules and unacceptable,
> because OLSRv2 specifies forwarding messages unchanged. That completely
> breaks use of RFC 7182 message ICVs - which might be applied by the
> multiplexer. Please do not even consider this.
>
> JWD: you are correct.  ICVs disallow this behavior.  In my own code the
> messages are not changed because I generated them in the first place.
> Without ICVs though it's quite natural.  I've personally seen three
> different packetbb parsers (one my own) which by default will rearrange a
> message if processed and regenerated  (actually caused some headache when
> trying to debug and getting different generated message outputs).  If there
> are no ICVs and it doesn't matter, but that's throwing all of end to end
> security out the window.  End to end security is an issue.
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 23 Mar 2016 10:35:45 +0000

JWD: I partly disagree that it can't be used for this purpose.  RFC5444 specifies:
      <msg-hop-limit> is omitted if the mhashoplimit flag is cleared
      '0'); otherwise, is an 8-bit unsigned integer field that can
      contain the maximum number of hops that the message should be
      further transmitted.

which in retrospect was a mistake as 5444 was meant to be a format and not a protocol specification as we mentioned many times. No other  protocol message is going to forward these messages as AODVv2 "owns" the message type so I don't see an issue with bending the terms in 5444 to allow this forwarding of "information"

CMD> I think this comes under the heading of “not prohibited but undesirable” but also that all options I can see involve something undesirable, or worse, so this may be the least undesirable.

---

From: Justin Dean <[email-masked]>
Date: Wed, 23 Mar 2016 08:59:22 -0400

On Tue, Mar 22, 2016 at 5:04 PM, Thomas Heide Clausen <
[email-masked]> wrote:

> My point is that it is an issue that must be addressed: the requirements
> that multiple interfaces can be sharing the same address is old, I have
> raised it multiple times over the years. OLSRv2 was built to support it.
> Henning reported an additional use case.
>
> The WG chair suggesting to disallow it, or to "bridge it", is *not*
> solving the issue raised. It is the WG chair ignoring legitimate
> requirements from the WG, which does not strike me as aligned with proper
> process.
>
> The WG chair saying "it is past time to solve" a long raised (and ignored)
> issue does not strike me as being aligned with proper process either.
>
> Thomas
>
> Since you seem quite passionate about this issue let's work on fixing it
then.  I looked back over NHDP to see how we "solved" this issue (vaguely
remembering something about limiting the address assignment when two
interfaces on a node could reach the same medium but was unable to find
that).  It works because we tag neighboring addresses with either link or
neighbor status based on the incoming interface on which we received hello
messages. It seems to me that if AODVv2 limited RREP messages to the
interface on which the RREQ came in on (multicast or otherwise) that this
would fix the issue.

To do this the Neighbor Table (section 6.3) would have to be updated to
include the local interface on which this neighbor is associated with.
When attempting to check bidirectionality messages would only be sent out
on the listed interface.  This would be similar to the link table in NHDP
and link tlv types.

Justin

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 23 Mar 2016 14:02:26 +0000

Still strongly disagree with some of what you say. The multiplexer MUST NOT modify messages as far as the protocol can tell, no flag as to whether it may, that’s just absolutely horrible. But there is a get out of gaol free card - it could modify a message (e.g. add a TLV, such as an ICV) then revert it (remove the TLV) before the protocol sees it. The next 5444 usage draft will say this.

A protocol in general SHOULD NOT, but MAY, modify messages. OLSRv2 MUST NOT modify messages.

From: Justin Dean [mailto:[email-masked]]
Sent: 23 March 2016 12:40
To: Dearlove, Christopher (UK)
Cc: [email-masked]; Thomas Heide Clausen ([email-masked])
Subject: Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items

*** WARNING ***
RFC 7182 is mandatory to RFC 7181.  In violent agreement.  OLSRv2 MUST NOT do that.  5444 doesn't generate/forward messages though 7181 does.  Clearly there should be a way for a process sitting on the multiplexer to tell it that a message is immutable.  But in other cases a message does get change/added to (e.g. 6121 (SMF) tlvs attached to 6130 (NHDP) hello messages).  In the end we all seem to agree end-to-end security is a problem currently for AODVv2.
Justin

On Wed, Mar 23, 2016 at 8:29 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
I’ve put the MANET list back on distribution.

T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>

From: Justin Dean [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 23 March 2016 12:23
To: Dearlove, Christopher (UK)
Subject: Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items

*** WARNING ***