Subject: Re: [manet] AODVv2 responses to recent comments

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

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.

--
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: Charlie Perkins [mailto:[email-masked]]
Sent: 01 March 2016 01:08
To: Dearlove, Christopher (UK); manet
Subject: Re: [manet] AODVv2 responses to recent comments

*** 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>.
Hello Chris,
On 1/19/2016 5:37 AM, Dearlove, Christopher (UK) wrote:
And outside those 31, that we’re at this position with a suggestion there’s possible looping (about which I have no idea) isn’t that comforting.

I hope your concerns have been resolved on this matter.  The paper mentioned on the mailing list pointed out various ambiguities in RFC 3561 described how the ambiguities might be construed to install self-routes and, combined with possible inconsistent choices for sequence number, loops could result.  But the email to the list several weeks ago indicated that these ambiguities do not exist in AODVv2.  The authors of that paper have expressed interest in doing a similar analysis on AODVv2.

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.

I'm looking for any other open issues outside of the Security Considerations which is being reworked according to recent comments but should be submitted soon.

Regards,
Charlie P.

There’s also a lot of document to review. Which of course I haven’t done at this time. But my attention did alight on the IANA considerations section, and I noted there that:
- Not sure why the jump to 10 for message types, though I’m not opposed.
- The PATH_METRIC TLV can’t be type 10, that’s already taken. See IANA register.
- We previously pointed out that CONT_SEQ_NUM (COMPLETE) already exists and does the job that SEQ_NUM is doing, so why allocate another TLV? (You could avoid the necessity of repeating (COMPLETE) by simply commenting once and thereafter omitting.)
- Why the suggested skipping of types 12 to 14?

--
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: manet [mailto:[email-masked]] On Behalf Of Victoria Mercieca
Sent: 18 January 2016 21:45
To: manet
Subject: [manet] AODVv2 responses to recent comments

*** 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>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Hi all,
We have just released the newest AODVv2 draft. The major update is the separation of the AODVv2 route set from the RIB.

Here are also responses to the comments received before Christmas. This should include all the points from Thomas Clausen regarding versions 11 and 12, and also a couple of other points which have been brought up since. Apologies for the huge email. For issues that need further discussion, I have tried to include the main points of the discussion so far. Please feel free to create a separate thread for any further discussion.

We are still looking into the loop conditions recently reported for AODV, also still working on the text about security, and use of msg-hop-limit.
Kind regards,
Victoria.

1. End-to-end / hop-by-hop acks - issue when a route is marked as confirmed and valid when the link to the next hop is confirmed as bidirectional (but the links downstream have not yet been verified as bidirectional).

AODVv2: The authors believe this is an issue which would not occur frequently, and would right itself.

This only occurs for the route to OrigAddr. What needs to happen for this to occur is that an intermediate node that takes part in the route discovery between OrigAddr and TargAddr coincidentally has packets to send to OrigAddr in the time between confirming the link to its own next hop toward OrigAddr is bidirectional, and the time taken for all other routers on the path to confirm their next hops too. If the route is used to forward packets before every other link in the path is confirmed as bidirectional, and the data packets are forwarded faster than the RREP and any RREP_Acks, then yes they could be delivered to a router without a valid route to OrigAddr. Alternatively if one of the links turns out to be unidirectional then the data packets will also arrive at a router without a valid route. In these cases, RERR messages will be generated toward the source of the traffic, the route to OrigAddr will be deleted at routers back toward TargAddr, but if data packets are still flowing from any source to OrigAddr, the route will be re-requested by the router responsible for discovering routes for the source of the data.

The changes required to make acknowledgements end-to-end would require a lot more control traffic and be necessary for every route discovery and in almost all cases would be unnecessary.

Text has been added to the draft in “Local Route State Changes” to describe this.

2. Buffering
Thomas:
“It would seem that buffering, as specified, does not accomplish what
it states that it accomplishes: packets are (as you describe) still being
sent while no route is available, and therefore will be dropped later.
=> Consequently, it seems that buffering is a futile exercise?”

AODVv2: Packets are buffered before a route exists. A router only begins sending them when it deems the route to be valid. In general, buffering is not futile.

True, there is this case outlined above where the router could deem the route valid before the bidirectionality check has happened for each and every hop. If the links chosen for the route are not all bidirectional, then yes, any data packets forwarded along this route will end up being dropped at some point on that path.
This case is caused by the RREP_Ack being hop-by-hop, and not caused by buffering.

Thomas: 
“Buffers have huge impacts on TCP performance, and I doubt if the issues on e.g. TCP are well enough understood by this WG (Bufferbloat was an example of where people got it wrong, despite having extensive experience).”

AODVv2: Packets will only be buffered while a route is requested. The TCP packets buffered will be packets for session initialisation. The authors believe that buffering these will have a positive effect. Some references have been suggested, listed here, the first of which has been included in the draft:
http://www.ieee802.org/21/archived_docs/2003-09_incoming/ccr-200109-koodli.pdf
Mobile Internetworking with IPv6: Concepts, Principles and Practices {Koodli, Perkins}
disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt<http://disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt>
Analysis of TCP performance over mobile ad hoc networks http://dl.acm.org/citation.cfm?id=313540
Alternatively, we could remove the mention of TCP, and instead state that buffering MAY be used for packets awaiting a route, but that implementation and implications of this are out of scope for AODVv2.

3. Use of msg-hop-limit and msg-hop-count:
Thomas:
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.

AODVv2: Discussion is still needed here. We wonder if these fields are necessary at all for AODVv2. We were using them to limit the number of regenerations of a RREQ. However, the hop limit value needs to be large enough to allow a RREQ from one side of the network to another. It might be the case that using the hop limit, almost every router in the network would receive that RREQ anyway, and by using the redundancy check, we already stop RREQs from circulating endlessly.

4. Abstract
Thomas:
“I made the following comment, which still applies:
“This is a little over-stating the applicability: these statements may be true in some scenarios (for example, when there are few concurrent traffic flows, and therefore few routes to repair, and therefore few flooding operations to contend for channel access). As a general statement, this last sentence is incorrect””

AODVv2: The text has been removed and the abstract now states: “ The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks.  AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion.”

5,9,12,13,20. Router Client
Thomas:
“I made a comment previously that “Router client” is a poorly chosen term, and have proposed alternatives. I’ve seen some attempts on the list at rather than change the term, explain it — some of which is in this document. The “Overview” still talks about “a router…one of its clients” - which is no less confusing than last time Iw went through it.
I reiterate, why not use “Local Attached Network Set”, which is the term used by other documents from this WG?”

AODVv2: We already answered this suggestion on the MANET list and asked for comments and suggestions, and no responses were received. We have defined what we mean by Router Client, and the terminology has so far not changed. However, some alternatives have been suggested, so if you feel any of these are more effective, please let us know:
•    Advertised IP Address: puts the emphasis on advertisement rather than topological connection
•    Accessible IP Address: puts the emphasis on accessibility through the particular router – not bad
•    Reduced Function Device [RFD]: doesn’t roll off the tongue, but this is terminology used for L2R in IEEE 802 Wireless for a similar situation
•    Accessible Device Address: adds some emphasis for the device as well as the address
•    Stably Connected IP Address: nothing is permanent, of course, but the router client set is thought to be relatively stable
•    Topologically Connected IP address: ... suggests that a "topological connection" is stable compared to wireless
•    Administratively Assigned IP address: ... somehow does not connote the "otherness" of the router client devices.

6. Overview - adjacency
Thomas:
The term “confirming adjacency” is gone, and is now replaced by “confirming bidirectionality” - which, alas, still sounds like there is some active monitoring (HELLO message exchange) going on. Unless that is the case, then please be more specific here.
I note that the term adjacency is used through and through the document, btw.

AODVv2: The text has been updated to avoid the word adjacency. We do not believe the text implies active monitoring through HELLO messages.

7. Overview - forwarding plane
Thomas: I suggested in my last review: The overview must also include a paragraph on the intersections between this protocol and the forwarding plane — this, as it is different (and more invasive) from that which is typically seen in routing protocols.
Specifically, as a reactive protocol, it is required (at least) that the forwarding plane is modified :
1) A “miss” when looking up a next hop for a data packet to be forwarded, is signalled to the AODVv2 process so as to permit that route discovery be launched;
2) A “miss” when attempting to deliver a data packet to a next hop, which was recorded in the routing table, is signalled to the AODVv2 process so as to permit that a route repair be initiated and/or a Route Error be generated.
3) A “hit” when looking up a next hop for a data packet to be forwarded to a destination is signalled to the AODVv2 process so as to permit maintenance of “active route” Route State, timers and such.
Note that these things are necessary to call out in the “overview” and in the “applicability statement”, both: it is not that they are negatives per se, but that they are important factors governing the applicability of this protocol: will a given platform permit such access to the forwarding plane, for example? Important to understand if for that platform this protocol is apple
I see that this was not addressed in the overview, nor in the applicability other than by a forward reference to section 6.4. While it is positive that there is a section 6.4, this does not exonerate the overview and the applicability statement for being honest about the requirements (notably to the platform/os) that this protocol has for being applicable

AODVv2: The Overview and the Applicability Statement now refer to these basic requirements for the interaction with the forwarding plane. The Applicability Statement also contains the reference to the later section which describes this in more detail.

8. 7182 and security

Thomas: I suggested in my last review: It is important to do more than this: 7182 does only provide “containers” for ICVs and timestamps, and does not specify how to use them to obtain specific security properties. RFC7182 may be a tool that can be used, but how* that tool is used is what determines the security properties.
Therefore, saying that “security is dealt with by using RFC7182” is either an incomplete statement, or is indicative of insufficient security considerations.”
The actual sentence in the I-D has been changed, now it explicitly names the two TLVs from 7182 that it uses. That is, alas, still not sufficient.
Making the aside that was discussed recently on the list, that (i) control messages are not forwarded, and that (ii) they are modified in transit, the security/trust model is somewhat different from that of 7181 and consequently for what 7182 was initially written for. I think that  calling out the trust model, and how 7182 actually is used here, might be what is called for.
Continuing with the aside, this *especially* as the applicability statement says: "Providing security for a reactive routing protocol can be difficult”

Thomas:
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.
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.

Chris Dearlove:
There are two potential choices:

- RREQ has an integrity check value to indicate that someone trusted created it, if not necessarily the destination. That someone might be identifiable or not.
- RREQ has a signature that indicates that the destination created it.

Unfortunately, an RREQ that changes as it is forwarded (aggregating data of any sort) makes the second option tricky, unless there’s some sort of aggregating signature as it is forwarded. But I’m not an expert on the latter.

The most trivial case of the former is simply that everyone trusted has a single shared key. That has obvious issues – although it was good enough that embodied as RFC 7183 we could get 7181 through the system (as a “must implement, do not need to use” minimal case). Alternatively something identity-based (e.g. draft-ietf-manet-ibs) could be used, so you know who created the message you received, but you are relying on a chain of trust, hop by hop. At which point you might as well just sign packets (see RFC 7182).

But in even the weakest case (the single shared key used hop by hop) there has to be a failure for things to go wrong - either loss of key (in which case all bets are off) or suborning one router (who can do quite a lot of damage).

I haven't read the latest AODVv2 draft yet, but this sort of thing should be described in its security considerations - the previous draft though didn't discuss this as far as I recall.

Chris Dearlove:
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.

Jiazi Yi:
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.

AODVv2: This is not yet addressed.

9. Terminology - host, routers, router clients:

Thomas: My last review suggested:
“This has been brought up on the list several times in the past, without having been addressed.
There are “hosts” and there are “routers” — whose roles are well defined. Node” not so much — which is clear from looking at the definition here: “either AODVv2 routers or router clients” (with “router clients” being defined as “an AODVv2 router is also its own router client”).

This is very much related to the use of “Router Client”, and both that term, and “node” indicative that some clarity is needed here.

All a router cares about is “an address”. If that address is of a network, or a router, or an interface (and, if said interface is installed in a router or a host) doesn’t matter.

So, “an address” is something that the routing protocol should care about finding paths to. Which means that each address that should be made reachable by the routing protocol should be advertised by (at least) one router in the network.

One way of doing that would be to simply talk about “Attached Networks” as is done in RFC7181, wherein an address included in the “Attached Network Set” is advertised by an OLSRv2 router....in this case, the equivalent would be “for each address in the Attached Network Set of an AODVv2 router the router MUST respond authoritatively to a RREQ, and MUST maintain the corresponding sequence number”.
The text, as it currently is, is really hard to read, and a re-edit along these lines would go a long way.”

I note that the terms “Node” and “Router Client” are still used, in their original form, and that other than some slight wordsmithing this comment has not been addressed in the document.

I reiterate that the need to use router, host, node, and router client in and by itself should be an indicator that tightening up of terminology is required.

AODVv2: See 5. The use of “node” has been addressed.

10. Terminology and elsewhere - address
Thomas: I made the following comment to Routable Unicast IP Address:
“Are there any technical reason why not simply *any* address could be considered by the routing protocol?
My understanding, but correct me if I am wrong, is that all that is required is that all interfaces in a given AODVv2 routing domain has an unique address.
That some of these addresses (by an IP addressing architecture document) has special semantics associated (such as are link locals, or are for private use, or are for example use only, or are for multicast) is out of scope here?
I see nothing has changed on the above, so let me be more explicit: the routing protocol itself probably) should not care about what kind of addresses are filled into it. Is an 192.16./16 address appropriate? Not across the internet, but it may be in somebody’s private deployments. Should the routing protocol be “address police” and is implementation of a “I refuse to route these addresses…” a requirement for claiming conformance? Suggest simply stating what the requirements are under which the routing protocol will work — and leave “address assignment politics” aside.

AODVv2: We ask for clarification on this issue. We use the phrase “routable and unicast” in the draft with respect to OrigAddr and TargAddr. We dont mean to exclude addresses from the private address ranges. But we dont want to request routes for multicast, indeterminate, link-local, or loopback addresses. This is not about router interface addresses which are used for AODVv2.

11. Multiple interfaces with the same IP address, 6621 implications

Thomas: I also continued:
Now, with that being said also, the WG wanted that RFC7181 supports not just multiple interfaces, but also the same address used on multiple interfaces of the same router. There were good reasons for that, and while it was not trivial to implement, it turned out to be the right thing to support. If there are technical reasons why this is not supported in AODVv2 (for example, if this cannot be made work because of <reason>) then that should be called out in the applicability statement also?
Conversely, if it is possible in AODVv2, then I do not believe that it is clearly specified how (at least, in the “naive” on paper examples I drew up, something ended up not working). So either the protocol as-is does not support it (but could be made to?) or it is supported (but just need to be spelled out), or is not possible (and need to be disclaimed in the applicability statement).
Stan Ratliff was a driving force in holding the WG’s collective feet to the fire in getting this support included in RFC7181, and would likely be the right person to consult on this matter?
I actually have not seen changes, or comments, on this. In OLSRv2, the WG was making it a strong requirement that it should be possible to use the same IP address on different interfaces of a router. It was somewhat tedious to design around, but it was worked out, and the conditions under which that was possible were defined and documented.
I would like to see the same done for this protocol.
I also note that this is not unrelated to RFC6621-discussions. For example, when selecting S-MPRs on a multi-interface and multi-address-per-interface router, care must be taken least things won’t work. So, if (and this links back to previous mails) RFC6621 is a requirement or desire for this protocol, then there are some considerations required here.

AODVv2: We have removed references to RFC 6621.
Initial thoughts on this topic of multiple interfaces using the same IP address, is that this wouldn’t cause a problem, if the router has only one sequence number. However, this is up for further discussion.

12. Interfaces configured as router clients

Thomas: I see that the definition of “Router Client” has changed to be
“An address or address range…the AODVv2 router’s interface addresses are also configured as router clients”
Better than before, but still missing the target. The term “Router Client” is, as I indicated numerous times before, odd.
But the second part of the sentence, does that mean (what it says) that the interfaces must be configured specially, so as to be able to be “router clients”? That can’t be true.
What you likely mean is:
An AODVv2 router is configured so as to consider its own interfaces as part of the locally attached network set” ?
You configure the router, right? No special “interface configuration properties” are required for an interface to be announcable by  an AODVv2 router? (And, getting rid of node would actually make the definition shorter and nicer)

AODVv2: The wording we use says: "The IP Addresses of the router's interfaces will appear in the Router Client Table." and in the Terminology: "The AODVv2 router's interface addresses are also configured as Router Clients." Both statements say that ‘interface addresses are configured as router clients’ ...we are not sure why this is misunderstood. We have a router client list, and the AODVv2 router’s interface addresses are included in this list. The interface itself doesn’t have special “interface configuration properties”.

13 - more on router clients
Thomas: Now, snipping out from the applicability statement:
"Multi-homing of an IP address is not supported by AODVv2, and therefore a Router Client, i.e. an IP Address,  … "
…evidence to there being some redundant terminology here to weed away.

AODVv2: That was there as a reminder that a router client is based on IP address, even though the device with that IP address may have other IP addresses too. It’s the IP address that is the router client, not the device as a whole with its entire collection of configured IP addresses. One IP address of that device might be configured as a router client on one router, and a different IP address of that device could be configured as a router client on another router. The IP addresses would seem to AODVv2 to be on different devices.

14. data elements

Thomas: The below is a little bit of a meta-comment, I am not quite sure what I think here. The definitions for Target Node and such were confusing before. They still are, somewhat.
I think that it may be because the definitions now used are simply copy-pasted out from the tables in the previous version, for example:
   “An AODVv2 Data Element containing the destination address of the IP packet triggering route discovery.”
OK, I can trace back and see that a Data Element is something that exists inside a protocol message. To me, however, that’s not really general terminology as such, but part of the specification of a packet format - or rather, it is the notation that you use when describing an algorithm. By the way, why are some notations in CamelCase whereas others have a space in them, e.g. “Target Node” and “TargMetric”, both of which are Data Elements? Would be good with a consistent approach here.
I *think* that it would be better to take all those “Data Element” bits and move to a separate section (or subsection) to the terminology, and then keep all the “other stuff” (Neighbor, …) in its own section.

AODVv2: Your comment from draft 11 where we already had data elements in a separate table, says:
"Also suggest abolishing this table and folding the definitions in with the other definitions in the terminology section."
We have updated to not refer so heavily to the term Data Element. All the terms are described in the Terminology section. Those in CamelCase are used as message fields.

15. Route “to a specific address”
Thomas:
I made a comment: Second, should “valid route” not be qualified by “to a specific address”?”
Which was not addressed.

AODVv2: Every route is to a specific address...the address is specified by Route.Address and Route.PrefixLength.
Do you mean that routes are to the address TargAddr or OrigAddr and therefore to a specific host address rather than to a network prefix? This is not the case. Prefix Length is included in AODVv2 messages so that the route learned from the message represents the prefix which OrigAddr or TargAddr resides on (if the router client entry corresponding to OrigAddr at RREQ_Gen or TargAddr at RREP_Gen is configured with a prefix length). e.g. OrigAddr is 10.0.0.1 but the corresponding router client entry at RREQ_Gen could be 10.0.0.0/8<http://10.0.0.0/8>. So when constructing the RREQ you include a prefix length of 8, and when receiving the RREQ and learning the route to OrigAddr, you can install a route to 10.0.0.0/8<http://10.0.0.0/8>.  Text has been updated to make this more obvious.

16. unreachable address

Thomas: I also made a comment on "Unreachable Address” - I am glad I did, because I apparently had a different understanding than what was intended. I now see that an Unreachable Address by definition is an address listed in a RERR message, and not the same as an address to which no route has yet  been discovered? If yes, then please use a different term, such as FormerlyReachableAddress” or something of the sort?

AODVv2: "Formerly reachable" is inaccurate... we send a RERR if another router forwards a packet via us, and we dont have a route, not just when we lose a route. We might never have had a route, or might never have had a valid route, so the address may not have been "formerly reachable". Also, I think "FormerlyReachableAddress" is a really ugly term. Unreachable means "we don’t have a route and we aren’t going to request one" or "we lost this route" (depending on why the RERR is being sent). It doesn’t mean "we didn’t request one yet", and it would be wrong to class an address as unreachable because we hadn’t requested a route for it yet, that is, assuming it’s configured as a router client.

If a better term is suggested we could consider changing but at the moment we have kept “Unreachable Address”.

17. Applicability - multiple interfaces same address, 6621 again

Thomas: Applicability statement: First, I would like to recognize the efforts made to improve this since last review. Thanks
Second, the document states: "AODVv2 supports routers with multiple interfaces, as long as each interface configured for AODVv2 has a unicast IP address.  A router may use the same IP address on multiple interfaces.  Address assignment procedures are out of scope for AODVv2.”
Is that true? Granted, I have not worked this through in detail, but I can present a counter-example: the use of RFC6621 means that there certainly are some constraints that must be respected least various flooding optimizations may not work.
Secondly, if the multiple-interfaces-with-same-address are on the same L2, and this is what I have not worked through, are there any situations that will not work?
The immediately previous version of this specification read:
"AODVv2 supports routers with multiple interfaces, as long as each interface configured for AODVv2 has its own unicast routable IP address"
So what changed that means that each interface no longer needs its *own* unicast address?

AODVv2: Well, based on previous questions on this, we talked it through and decided there shouldn’t be an issue if different interfaces of a router used the same IP address. Note that we changed AODVv2 so that there is one sequence number per router. No longer can a router use different sequence numbers on different interfaces. If an RREQ went out of two interfaces using the same address, we worked it through and decided the request would be processed correctly.
Also, text referring to RFC 6621 has been removed.

18. Applicability and appendix - multihoming

Thomas: I pointed out to the Applicability Statement:
I think that appendix B needs to be removed. Essentially, it makes claims that it is possible to do multi-homing — but neither specifies how it is done, nor gives pointers to documents that justify the claim.
AODVv2 does not support multi-homing — that’s clear, and it is fine that it is called out here. Thank you for that.
Now, with that being said, I am torn between being satisfied that it is called out on one hand, and wanting to have “multi homing” on the other hand. RFC7181 supports multi-homing, FWIW.
I believe that this also would merit some explicit discussion by the WG, in order to understand if this design decision is acceptable?
I see that Appendix B still is in the document, and I do not recall having seen this discussed on the mailing list. Simply removing the reference from the Applicability Statement to Appendix B does not address the issue that I raised in my previous review.

AODVv2: Appendix has been removed and may appear in a future informational document.

19. interfaces list - use of “SHOULD”

Thomas: To 4.1, I made the following comment:
"Is this a should, or a SHOULD? If the latter, should it be a MUST?
In general, there are a lot of such “maybe normative language” through the document, and I would much like to see an editorial pass — essentially all may/should/ must and friends carefully evaluated as if they should become 2119-terms, and ... more importantly (it has been called out before, fwiw) quite a bit of should/SHOULD which ought to be transformed into MUST.
Generally, aiming for a very a low number of SHOULD is a good design metric for a document”
Aside from the general comment on 2119-language, why is this a SHOULD?

AODVv2: We changed this instance to a MUST and will be checking for “maybe normative language”.

20. Router client - Local Attached Network Set

Thomas: To 4.2, I made the following comment:
As indicated earlier, I believe that the term “Router Client” is ill chosen. I believe that it is more appropriately an “Attached Network Set” since — as indicated previously — the term “Router Client” is ambiguous. I am pleased to see, though, that this “Router Client List” in reality is an “Attached Network Set” and so that change should be (relatively) easy.
The above comment still is applicable to this revision,

AODVv2: See 5,9,12,13.

21. Subnet
Thomas: To 4.2, I made the following comment:
Also, I recommend to not say “subnet” — how about rephrasing to “If a prefix is included in the attached network set of an AODVv2 router, then that AODVv2 router MUST provide connectivity for, i.e. answer to RREQs and maintain sequence numbers for, all addresses from within that prefix.”
I note that while the term has been removed from section 4, there’re 4 lingering instances of this term in the document, that could easily be removed.

AODVv2: All mentions of "subnet" were in the ENAR section. They have been updated to say network, or "networks attached to the routers"

22. relocating router client

Thomas: I Also made a comment about Appendix B in my previous review, which is referenced here. That comment still applies.

AODVv2: Moved into main draft.

23. Neighbor Monitoring

Thomas: To Section 4.3, I noticed:
Does section 6.2 describe how to monitor an established adjacency only, or how to discover neighbouring AODVv2 routers? Looking in 6.2, I see
“Not every pair of neighboring routers will necessarily form an adjacency,” — so it likely isn’t 6.2 that tells me how to maintain this table?
In short, “A neighbour table MUST be maintained” — where can I find information on how to do this?
Section 6.2 states:
“The default approach for monitoring bidirectional connectivity to the next hop toward OrigAddr is to request acknowledgement of Route Reply messages.”
That certainly will tell me if a link over which an RREP is sent is bi-directional, but will not maintain a “neighbor table”.
So how is this done? Or, is the “Neighbor Table” not supposed to contain the complete set of neighbours? What information “...MUST be maintained” then, in this table?
This is very unclear, I would not know how to implement a mechanism that populates this “Neighbor Table” with the needed information here.
I see no (relevant) changes to 6.2 nor to 4.3 so I assume that this comment has not been addressed

AODVv2: A new section was added to show how to update the neighbour table. There have also been updates to this entire section since version 12.

24.     pseudo-code

Thomas:
I am throwing this in here, as I am sure that I commented on that in the previous review, but I do not see that addressed: is Appendix C normative, or not? It represents “ a second specification of the protocol, in a different language” from the main part of the specification. I have not walked through and made 200% sure that both are perfectly aligned and that there are no ambiguities, but having two different specifications of a protocol is a recipe for disaster.  Please either make 2000% sure that they are specifying the same thing without ambiguities, or remove one.

AODVv2: Removed - maybe to include in an informational document in future.

25. seqnum as 16 bit unsigned integer

Thomas: To section 4.4, I wrote:
"would like to nit-pick that: the router can maintain this sequence number in whatever format it pleases — but, when it includes it in control messages, it must be representable in a specified format, respecting certain rules.”
I see that there were no changes following this comment.

AODVv2: Why store it as anything other than what it needs to be when it goes into a message? However, we now state "MUST report its own sequence number as a 16 bit....whenever it creates a RREQ or RREP message".

26. multiple seqnums?

Thomas:
To section 4.4 I asked for clarification as to if sequence numbers were per interface or per router, as the specification was unclear on that. The words has changed, but it still is unclear: how many sequence numbers does a router maintain? One? One per interface?

AODVv2: We tried to start discussion on that point, and in the meantime we reverted to having 1 seqnum per router. We think the text is clear... we refer to "the routers sequence number" or "its sequence number" - never hinting that there could be multiple seqnums per router (as far as I'm aware).

27. sets/lists/tables

Thomas:
In my previous review, I expressed that it would be preferential to use “a notation of Sets” rather than tables. I see that this has not changed.

AODVv2: You preferred sets rather than lists in your previous review...and explained our reasoning for this in responses to the MANET list, and we did not receive further comments.

28. use of “node”

Thomas:
I made a comment on node and address, let me pick this up again. The following:
RteMsg.OrigAddr
An IP address of the node which requires the route, i.e., the source address of the IP packet triggering the route request.
would be more compact and clear if getting rid of the term “node” and said:
RteMsg.OrigAddr
The source address of the IP packet triggering the route request.

AODVv2: Change made as suggested.

29. route table/rib/routing set

Thomas: To section 4.6, and I (and others) have commented on this before:
All AODVv2 routers MUST maintain a route table.  The route table entry is a conceptual data structure.  Implementations MAY use any internal representation but MUST contain the following information:
In order to avoid confusion, rename this to “Routing Information Base” or “Routing Set” — a Routing Table is an operating system construct, whereon operations directly influence packet forwarding. What you are defining here is a RIB/an RS.

AODVv2: Done in version 13.

30. rreq for prefix, use of “ip address” and “address"

Thomas:
The confusion that I pointed out in my previous review on “IP address” and “Address” being used a bit haphazardly persists, fwiw. It makes me think, can a router send an RREQ for a prefix?

AODVv2: See also #15. RREQ_Gen can include the prefix associated with OrigAddr by adding a prefix length to the message, the prefix length associated with the router client entry corresponding to OrigAddr. So all routers which receive it can learn a route to the prefix on which OrigAddr resides. But for TargAddr... the RREQ only has one target IP address - the destination IP address of the packet requiring the route... so what prefix length would it use? The RREQ requests a route to a single IP address. However, when the RREP is created, RREP_Gen should include the prefix length associated with the router client entry for TargAddr. So all routers which receive this RREP learn a route to the prefix TargAddr is part of (if the router client entry is configured with a prefix length). The text has been updated to make this more obvious.

31. next hop ip address wording

Thomas:
I also called this out in my previous review as incorrect, and despite wordsmithing it still is:

        Route.NextHop
              The source IP address of the message advertising the route to
              Route.Address, i.e. an IP address of the AODVv2 router used for
              the next hop on the path toward Route.Address.

If that “message” is an RFC5444 entity, then it does to have a “source IP Address” — the encapsulating IP datagram containing the packet containing the message does. And the message MAY have an Originator Address

AODVv2: Updated to say “the source IP address of the IP packet containing the message advertising...”

********************************************************************
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.
********************************************************************

_______________________________________________

manet mailing list

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

https://www.ietf.org/mailman/listinfo/manet

---

From: Lotte Steenbrink <[email-masked]>
Date: Wed, 16 Mar 2016 18:12:49 +0100

Hi Christopher,

> Am 02.03.2016 um 11:36 schrieb Dearlove, Christopher (UK) <[email-masked]>:
> 

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:

1. n2 initiates a route discovery procedure for destination n3 by broadcasting a “rreq” message.
2. n1 and n4 upon receiving the “rreq” message, add a route to their routing tables towards n2 and store n2 as their next hop. Since it is the first time that these nodes have received a message from n2, the neighbor state of n2 is set to unconfirmed. Therefore, the route state is unconfirmed.
3. As n1 and n4 are not the intended destination of the route request, they rebroadcast the “rreq” message.
4. n1 receives the “rreq” message sent by n4 and since the route to n2 is unconfirmed it adds n4 as new next hop to n2.
5. n4 also adds n1 as the new next hop towards n2 after processing the “rreq” sent by node1. At this point a loop is formed between n1 and n4 but not used yet.
6. n3 receives the “rreq” message sent by n1 and since it is the destination, it sends a “rrep” message towards n1.
7. n2 moves out of n1 and n4 communication range.
8. n1 receives the “rrep” message sent by n3 and as the route state towards n2 is unconfirmed it multicasts the “rrep” message to the existing next hops, n2 and n4. Since n4 is adjacent to n1, it receives the message and then sends an ack to n1. Therefore, n1 sets the neighbor state of n4 to confirm and subsequently the route state towards n2 to valid. Then expunge the next hop n2 which has not received an ack from.
9. n4 by receiving the “rrep” message from n1 multicasts it to its next hops towards n1 and n2,
and similar to n1 it updates its routing table by validating n1 as its next hop to n2. At this point, a loop between n1 and n4 becomes valid.

In response to these findings, we've changed 6.7.1.  Evaluating Route Information in -13, so that LoopFree() is *always* considered before adding a new route, even if all known routes to date are Unconfirmed.

Following up, they’ve found another loop in -13:

At first nodes are connected to each other as shown in Fig1.a.
n0 initiates a route discovery procedure for destination n3 by multicasting a “rreq” message to n2 with sq=2.
n2 after updating its routing table, multicast the “rreq” to its neighbors, n1 and n3.
n1 upon receiving the “rreq” message sent by n2 updates its routing table and adds a route with hop-count=2, sq=2 and next-hope=2
Consider that topology changes at this point and n1 moves into communication range of n0, gets connected to n0, and n2 leaves n0 communication range, gets disconnected from n0, which leads to network topology shown in Fig1.b.
n0, which hasn’t received an “rrep” yet, resend the “rreq” message after increasing its sequence number to 3.
n1 receives the new “rreq” message, with sq=3, next-hop=0 and hop-count=1, since it’s a better route it would be added to the routing table. Then n1 multicast the “rreq” message to its neighbors, n2 and n3.
n2 evaluate the received message sent by n1 and adds a new route to its routing table with sq=3, next-hop=1 and hop-count=2 since the sequence number of the received message is greater than the stored one.
At this point a loop has been formed between nodes n1 and n2.

Since we’ve moved to disallowing multiple Unconfirmed routes (in -14, which isn’t published yet), this one is resolved already as well.

The reason we didn’t discuss this earlier on [manet] was that the authors hadn’t submitted their paper yet (and I didn’t want to leak their work). They’ve done so now, and will send us a link to their paper once it’s available. I’m guessing it’ll take a while to be published properly, but it should be enough for for our purposes for the paper to appear on arxiv.org for now…

Best regards,
Lotte

> T:  +44 (0)1245 242194  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: Charlie Perkins [mailto:[email-masked] <mailto:[email-masked]>] 
> 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>.
> 
> Hello Chris,
> 
> T:  +44 (0)1245 242194  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Victoria Mercieca
> 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>.
> *** WARNING ***
> http://www.ieee802.org/21/archived_docs/2003-09_incoming/ccr-200109-koodli.pdf <http://www.ieee802.org/21/archived_docs/2003-09_incoming/ccr-200109-koodli.pdf>
> disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt <http://disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt>
> Analysis of TCP performance over mobile ad hoc networks http://dl.acm.org/citation.cfm?id=313540 <http://dl.acm.org/citation.cfm?id=313540>
> Do you mean that routes are to the address TargAddr or OrigAddr and therefore to a specific host address rather than to a network prefix? This is not the case. Prefix Length is included in AODVv2 messages so that the route learned from the message represents the prefix which OrigAddr or TargAddr resides on (if the router client entry corresponding to OrigAddr at RREQ_Gen or TargAddr at RREP_Gen is configured with a prefix length). e.g. OrigAddr is 10.0.0.1 but the corresponding router client entry at RREQ_Gen could be 10.0.0.0/8 <http://10.0.0.0/8>. So when constructing the RREQ you include a prefix length of 8, and when receiving the RREQ and learning the route to OrigAddr, you can install a route to 10.0.0.0/8 <http://10.0.0.0/8>.  Text has been updated to make this more obvious.
> 
> 16. unreachable address
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>  
> [email-masked]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 16 Mar 2016 17:22:32 +0000

I haven’t followed the example (I hope to find time - but that’s true of too many things, with DLEP ahead of AODVv2 on this list).

But we have a loop, a pretty fundamental problem in a routing algorithm, being discussed by the authors off-list, while in parallel assuring the list that “Other discussion about routing loops has not identified routing loop problems in the existing specification.” (see email chain below).

I think we have a real problem with what’s wanting to advance to Proposed Standard soon, in terms of process and confidence.

(I still haven’t managed to even write up comments on the perhaps one third of the draft I have read through yet.)

From: Lotte Steenbrink [mailto:[email-masked]]
Sent: 16 March 2016 17:13
To: Dearlove, Christopher (UK)
Cc: Charlie Perkins; manet
Subject: Re: [manet] AODVv2 responses to recent comments

*** WARNING ***

Am 02.03.2016 um 11:36 schrieb Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>>:

  1.  At first nodes are connected to each other as shown in Fig1.a.
  2.  n0 initiates a route discovery procedure for destination n3 by multicasting a “rreq” message to n2 with sq=2.
  3.  n2 after updating its routing table, multicast the “rreq” to its neighbors, n1 and n3.
  4.  n1 upon receiving the “rreq” message sent by n2 updates its routing table and adds a route with hop-count=2, sq=2 and next-hope=2
  5.  Consider that topology changes at this point and n1 moves into communication range of n0, gets connected to n0, and n2 leaves n0 communication range, gets disconnected from n0, which leads to network topology shown in Fig1.b.
  6.  n0, which hasn’t received an “rrep” yet, resend the “rreq” message after increasing its sequence number to 3.
  7.  n1 receives the new “rreq” message, with sq=3, next-hop=0 and hop-count=1, since it’s a better route it would be added to the routing table. Then n1 multicast the “rreq” message to its neighbors, n2 and n3.
  8.  n2 evaluate the received message sent by n1 and adds a new route to its routing table with sq=3, next-hop=1 and hop-count=2 since the sequence number of the received message is greater than the stored one.
At this point a loop has been formed between nodes n1 and n2.

The reason we didn’t discuss this earlier on [manet] was that the authors hadn’t submitted their paper yet (and I didn’t want to leak their work). They’ve done so now, and will send us a link to their paper once it’s available. I’m guessing it’ll take a while to be published properly, but it should be enough for for our purposes for the paper to appear on arxiv.org<http://arxiv.org> for now…

Best regards,
Lotte

*** WARNING ***

Regards,
Charlie P.

*** WARNING ***

Hi all,

2. Buffering
Thomas:

Thomas: 

4. Abstract
Thomas:

6. Overview - adjacency
Thomas:

8. 7182 and security

Thomas:

Chris Dearlove:

Chris Dearlove:

Jiazi Yi:

14. data elements

16. unreachable address

AODVv2: See 5,9,12,13.

21. Subnet

23. Neighbor Monitoring

24.     pseudo-code

Thomas:

26. multiple seqnums?

Thomas:

27. sets/lists/tables

Thomas:

28. use of “node”

Thomas:

Thomas:

Thomas:

        Route.NextHop

manet mailing list

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 16 Mar 2016 17:38:35 +0000

Lotte, Christopher,

I’ve had to approve the last two postings because the email size exceeds the allowed max. Let’s please find a way to limit the email – This is an important discussion, but I’d hate to have to approve each and every response.

Please?

Regards,
Stan

From: manet [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: Wednesday, March 16, 2016 1:23 PM
To: Lotte Steenbrink <[email-masked]>
Cc: Charlie Perkins <[email-masked]>; manet <[email-masked]>
Subject: Re: [manet] AODVv2 responses to recent comments

_____________________________________________________
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.
_____________________________________________________

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 16 Mar 2016 17:48:30 +0000

Sorry about that, I assume it was the picture, which I didn't think to remove. But we've all got the picture now. (Actually my work firewall tried blocking it.)

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 16 Mar 2016, at 17:38, Ratliff, Stanley <[email-masked]> wrote:
> 
> Lotte, Christopher,
>  
>  
> T:  +44 (0)1245 242194  |  E: [email-masked]
> 
> www.baesystems.com/ai

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 16 Mar 2016 17:59:09 +0000

Chris,

No worries. I figure you guys wouldn’t know if I didn’t sing out.

Regards,
Stan

From: Christopher Dearlove [mailto:[email-masked]]
Sent: Wednesday, March 16, 2016 1:49 PM
To: Ratliff, Stanley <[email-masked]>
Cc: Dearlove, Christopher (UK) <[email-masked]>; Lotte Steenbrink <[email-masked]>; Charlie Perkins <[email-masked]>; manet <[email-masked]>
Subject: Re: [manet] AODVv2 responses to recent comments

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]> (iPhone)
[email-masked]<mailto:[email-masked]> (home)

On 16 Mar 2016, at 17:38, Ratliff, Stanley <[email-masked]<mailto:[email-masked]>> wrote:
Lotte, Christopher,

Please?

Regards,
Stan

From: manet [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: Wednesday, March 16, 2016 1:23 PM
To: Lotte Steenbrink <[email-masked]<mailto:[email-masked]>>
Cc: Charlie Perkins <[email-masked]<mailto:[email-masked]>>; manet <[email-masked]<mailto:[email-masked]>>
Subject: Re: [manet] AODVv2 responses to recent comments

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 16 Mar 2016 13:32:49 -0700

Hello Chris,

I stand by my statement.  The cited paper did not identify a loop. Most 
importantly, the crucial part about route looping being prevented by 
sequence number still stands.  I also point out that the authors of that 
paper were constructive and complimentary to the clarity of the AODVv2 
specification.  I truly hope we can work together with them to further 
prove the correctness of the protocol.

Regarding the situation with unconfirmed routes, please not that 
unconfirmed routes can never be part of a routing loop because they 
don't carry data.

Regarding the off-list discussion, it is our online equivalent of a 
hallway discussion, and a manageable, constructive environment for us to 
produce responsive resolutions to the comments from you and others.  I 
hope we will see the rest of your comments soon because we want to 
resolve them as soon as possible.  We were honor-bound to not disclose 
private information to the list, but as you can see we also work hard to 
resolve privately submitted comments.

Regards,
Charlie P.

On 3/16/2016 10:22 AM, Dearlove, Christopher (UK) wrote:
>
> I haven’t followed the example (I hope to find time - but that’s true 
> of too many things, with DLEP ahead of AODVv2 on this list).
>
> But we have a loop, a pretty fundamental problem in a routing 
> algorithm, being discussed by the authors off-list, while in parallel 
> assuring the list that “Other discussion about routing loops has not 
> identified routing loop problems in the existing specification.” (see 
> email chain below).
>
> I think we have a real problem with what’s wanting to advance to 
> Proposed Standard soon, in terms of process and confidence.
>
> (I still haven’t managed to even write up comments on the perhaps one 
> third of the draft I have read through yet.)
>
> *-- *
>
> *Christopher Dearlove
> **__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  | *E: [email-masked] 
> <mailto:[email-masked]>
>
> *From:*Lotte Steenbrink [mailto:[email-masked]]
> *Sent:* 16 March 2016 17:13
> *To:* Dearlove, Christopher (UK)
> *Cc:* Charlie Perkins; manet
> *Subject:* Re: [manet] AODVv2 responses to recent comments
>
> **** 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>.//
>
> Hi Christopher,
>
>     Am 02.03.2016 um 11:36 schrieb Dearlove, Christopher (UK)
>     <[email-masked]
>     <mailto:[email-masked]>>:
>
>     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.
>
> 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:
>
> 2. n1 and n4 upon receiving the “rreq” message, add a route to their 
> routing tables towards n2 and store n2 as their next hop. Since it is 
> the first time that these nodes have received a message from n2, the 
> neighbor state of n2 is set to unconfirmed. Therefore, the route state 
> is unconfirmed.
>
> 4. n1 receives the “rreq” message sent by n4 and since the route to n2 
> is unconfirmed it adds n4 as new next hop to n2.
>
> 5. n4 also adds n1 as the new next hop towards n2 after processing the 
> “rreq” sent by node1. At this point a loop is formed between n1 and n4 
> but not used yet.
>
> 6. n3 receives the “rreq” message sent by n1 and since it is the 
> destination, it sends a “rrep” message towards n1.
>
> 8. n1 receives the “rrep” message sent by n3 and as the route state 
> towards n2 is unconfirmed it multicasts the “rrep” message to the 
> existing next hops, n2 and n4. Since n4 is adjacent to n1, it receives 
> the message and then sends an ack to n1. Therefore, n1 sets the 
> neighbor state of n4 to confirm and subsequently the route state 
> towards n2 to valid. Then expunge the next hop n2 which has not 
> received an ack from.
>
> and similar to n1 it updates its routing table by validating n1 as its 
> next hop to n2. At this point, a loop between n1 and n4 becomes valid.
>
> In response to these findings, we've changed 6.7.1.  Evaluating Route 
> Information in -13, so that LoopFree() is *always* considered before 
> adding a new route, even if all known routes to date are Unconfirmed.
>
>  2. n0 initiates a route discovery procedure for destination n3 by
>     multicasting a “rreq” message to n2 with sq=2.
>  4. n1 upon receiving the “rreq” message sent by n2 updates its
>     routing table and adds a route with hop-count=2, sq=2 and next-hope=2
>  5. Consider that topology changes at this point and n1 moves into
>     communication range of n0, gets connected to n0, and n2 leaves n0
>     communication range, gets disconnected from n0, which leads to
>     network topology shown in Fig1.b.
>  6. n0, which hasn’t received an “rrep” yet, resend the “rreq” message
>     after increasing its sequence number to 3.
>  7. n1 receives the new “rreq” message, with sq=3, next-hop=0 and
>     hop-count=1, since it’s a better route it would be added to the
>     routing table. Then n1 multicast the “rreq” message to its
>     neighbors, n2 and n3.
>  8. n2 evaluate the received message sent by n1 and adds a new route
>     to its routing table with sq=3, next-hop=1 and hop-count=2 since
>     the sequence number of the received message is greater than the
>     stored one.
>
> Since we’ve moved to disallowing multiple Unconfirmed routes (in -14, 
> which isn’t published yet), this one is resolved already as well.
>
> The reason we didn’t discuss this earlier on [manet] was that the 
> authors hadn’t submitted their paper yet (and I didn’t want to leak 
> their work). They’ve done so now, and will send us a link to their 
> paper once it’s available. I’m guessing it’ll take a while to be 
> published properly, but it should be enough for for our purposes for 
> the paper to appear on arxiv.org <http://arxiv.org> for now…
>
> Best regards,
>
> Lotte
>
>
>
> *--*
>
> *Christopher Dearlove
> **__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  | *E:[email-masked] 
> <mailto:[email-masked]>
>
> *From:*Charlie Perkins [mailto:[email-masked]]
> *Sent:*01 March 2016 01:08
> *To:*Dearlove, Christopher (UK); manet
> *Subject:*Re: [manet] AODVv2 responses to recent comments
>
> **** 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>.//
>
> Hello Chris,
>
>     And outside those 31, that we’re at this position with a
>     suggestion there’s possible looping (about which I have no idea)
>     isn’t that comforting.
>
>
> I hope your concerns have been resolved on this matter. The paper 
> mentioned on the mailing list pointed out various ambiguities in RFC 
> 3561 described how the ambiguities might be construed to install 
> self-routes and, combined with possible inconsistent choices for 
> sequence number, loops could result.  But the email to the list 
> several weeks ago indicated that these ambiguities do not exist in 
> AODVv2.  The authors of that paper have expressed interest in doing a 
> similar analysis on AODVv2.
>
> 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.
>
> I'm looking for any other open issues outside of the Security 
> Considerations which is being reworked according to recent comments 
> but should be submitted soon.
>
> Regards,
> Charlie P.
>
>
>
>
> There’s also a lot of document to review. Which of course I haven’t 
> done at this time. But my attention did alight on the IANA 
> considerations section, and I noted there that:
>
> - We previously pointed out that CONT_SEQ_NUM (COMPLETE) already 
> exists and does the job that SEQ_NUM is doing, so why allocate another 
> TLV? (You could avoid the necessity of repeating (COMPLETE) by simply 
> commenting once and thereafter omitting.)
>
> *--*
> *Christopher Dearlove
> *
> *T*:  +44 (0)1245 242194  | *E:[email-masked] 
> <mailto:[email-masked]>
>
> *From:*manet [mailto:[email-masked]]*On Behalf Of*Victoria 
> Mercieca
> *Sent:*18 January 2016 21:45
> *To:*manet
> *Subject:*[manet] AODVv2 responses to recent comments
>
> **** 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>.//
>
> **** WARNING ****
> We have just released the newest AODVv2 draft. The major update is the 
> separation of the AODVv2 route set from the RIB.
>
> Here are also responses to the comments received before Christmas. 
> This should include all the points from Thomas Clausen regarding 
> versions 11 and 12, and also a couple of other points which have been 
> brought up since. Apologies for the huge email. For issues that need 
> further discussion, I have tried to include the main points of the 
> discussion so far. Please feel free to create a separate thread for 
> any further discussion.
>
> We are still looking into the loop conditions recently reported for 
> AODV, also still working on the text about security, and use of 
> msg-hop-limit.
>
> Kind regards,
>
> Victoria.
>
>
> 1. End-to-end / hop-by-hop acks - issue when a route is marked as 
> confirmed and valid when the link to the next hop is confirmed as 
> bidirectional (but the links downstream have not yet been verified as 
> bidirectional).
>
> This only occurs for the route to OrigAddr. What needs to happen for 
> this to occur is that an intermediate node that takes part in the 
> route discovery between OrigAddr and TargAddr coincidentally has 
> packets to send to OrigAddr in the time between confirming the link to 
> its own next hop toward OrigAddr is bidirectional, and the time taken 
> for all other routers on the path to confirm their next hops too. If 
> the route is used to forward packets before every other link in the 
> path is confirmed as bidirectional, and the data packets are forwarded 
> faster than the RREP and any RREP_Acks, then yes they could be 
> delivered to a router without a valid route to OrigAddr. Alternatively 
> if one of the links turns out to be unidirectional then the data 
> packets will also arrive at a router without a valid route. In these 
> cases, RERR messages will be generated toward the source of the 
> traffic, the route to OrigAddr will be deleted at routers back toward 
> TargAddr, but if data packets are still flowing from any source to 
> OrigAddr, the route will be re-requested by the router responsible for 
> discovering routes for the source of the data.
>
> The changes required to make acknowledgements end-to-end would require 
> a lot more control traffic and be necessary for every route discovery 
> and in almost all cases would be unnecessary.
>
> AODVv2: Packets are buffered before a route exists. A router only 
> begins sending them when it deems the route to be valid. In general, 
> buffering is not futile.
>
> True, there is this case outlined above where the router could deem 
> the route valid before the bidirectionality check has happened for 
> each and every hop. If the links chosen for the route are not all 
> bidirectional, then yes, any data packets forwarded along this route 
> will end up being dropped at some point on that path.
> “Buffers have huge impacts on TCP performance, and I doubt if the 
> issues on e.g. TCP are well enough understood by this WG (Bufferbloat 
> was an example of where people got it wrong, despite having extensive 
> experience).”
>
> AODVv2: Packets will only be buffered while a route is requested. The 
> TCP packets buffered will be packets for session initialisation. The 
> authors believe that buffering these will have a positive effect. Some 
> references have been suggested, listed here, the first of which has 
> been included in the draft:
> disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt 
> <http://disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt>
> Analysis of TCP performance over mobile ad hoc 
> networkshttp://dl.acm.org/citation.cfm?id=313540
> Alternatively, we could remove the mention of TCP, and instead state 
> that buffering MAY be used for packets awaiting a route, but that 
> implementation and implications of this are out of scope for AODVv2.
>
>
> 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.
>       <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.
>
> AODVv2: Discussion is still needed here. We wonder if these fields are 
> necessary at all for AODVv2. We were using them to limit the number of 
> regenerations of a RREQ. However, the hop limit value needs to be 
> large enough to allow a RREQ from one side of the network to another. 
> It might be the case that using the hop limit, almost every router in 
> the network would receive that RREQ anyway, and by using the 
> redundancy check, we already stop RREQs from circulating endlessly.
>
> 4. Abstract
> Thomas:
> “This is a little over-stating the applicability: these statements may 
> be true in some scenarios (for example, when there are few concurrent 
> traffic flows, and therefore few routes to repair, and therefore few 
> flooding operations to contend for channel access). As a general 
> statement, this last sentence is incorrect””
>
> AODVv2: The text has been removed and the abstract now states: “ The 
> Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocol 
> is intended for use by mobile routers in wireless, multihop networks.  
> AODVv2 determines unicast routes among AODVv2 routers within the 
> network in an on-demand fashion.”
>
> “I made a comment previously that “Router client” is a poorly chosen 
> term, and have proposed alternatives. I’ve seen some attempts on the 
> list at rather than change the term, explain it — some of which is in 
> this document. The “Overview” still talks about “a router…one of its 
> clients” - which is no less confusing than last time Iw went through it.
> I reiterate, why not use “Local Attached Network Set”, which is the 
> term used by other documents from this WG?”
>
> AODVv2: We already answered this suggestion on the MANET list and 
> asked for comments and suggestions, and no responses were received. We 
> have defined what we mean by Router Client, and the terminology has so 
> far not changed. However, some alternatives have been suggested, so if 
> you feel any of these are more effective, please let us know:
> •    Reduced Function Device [RFD]: doesn’t roll off the tongue, but 
> this is terminology used for L2R in IEEE 802 Wireless for a similar 
> situation
> •    Stably Connected IP Address: nothing is permanent, of course, 
> but the router client set is thought to be relatively stable
> •    Topologically Connected IP address: ... suggests that a 
> "topological connection" is stable compared to wireless
> •    Administratively Assigned IP address: ... somehow does not 
> connote the "otherness" of the router client devices.
>
> 6. Overview - adjacency
> Thomas:
> The term “confirming adjacency” is gone, and is now replaced by 
> “confirming bidirectionality” - which, alas, still sounds like there 
> is some active monitoring (HELLO message exchange) going on. Unless 
> that is the case, then please be more specific here.
> AODVv2: The text has been updated to avoid the word adjacency. We do 
> not believe the text implies active monitoring through HELLO messages.
>
> Thomas: I suggested in my last review: The overview must also include 
> a paragraph on the intersections between this protocol and the 
> forwarding plane — this, as it is different (and more invasive) from 
> that which is typically seen in routing protocols.
> 1) A “miss” when looking up a next hop for a data packet to be 
> forwarded, is signalled to the AODVv2 process so as to permit that 
> route discovery be launched;
> 2) A “miss” when attempting to deliver a data packet to a next hop, 
> which was recorded in the routing table, is signalled to the AODVv2 
> process so as to permit that a route repair be initiated and/or a 
> Route Error be generated.
> 3) A “hit” when looking up a next hop for a data packet to be 
> forwarded to a destination is signalled to the AODVv2 process so as to 
> permit maintenance of “active route” Route State, timers and such.
> Note that these things are necessary to call out in the “overview” and 
> in the “applicability statement”, both: it is not that they are 
> negatives per se, but that they are important factors governing the 
> applicability of this protocol: will a given platform permit such 
> access to the forwarding plane, for example? Important to understand 
> if for that platform this protocol is apple
> I see that this was not addressed in the overview, nor in the 
> applicability other than by a forward reference to section 6.4. While 
> it is positive that there is a section 6.4, this does not exonerate 
> the overview and the applicability statement for being honest about 
> the requirements (notably to the platform/os) that this protocol has 
> for being applicable
>
> AODVv2: The Overview and the Applicability Statement now refer to 
> these basic requirements for the interaction with the forwarding 
> plane. The Applicability Statement also contains the reference to the 
> later section which describes this in more detail.
>
> 8. 7182 and security
>
> Thomas: I suggested in my last review: It is important to do more than 
> this: 7182 does only provide “containers” for ICVs and timestamps, and 
> does not specify how to use them to obtain specific security 
> properties. RFC7182 may be a tool that can be used, but how* that tool 
> is used is what determines the security properties.
> Therefore, saying that “security is dealt with by using RFC7182” is 
> either an incomplete statement, or is indicative of insufficient 
> security considerations.”
> The actual sentence in the I-D has been changed, now it explicitly 
> names the two TLVs from 7182 that it uses. That is, alas, still not 
> sufficient.
> Making the aside that was discussed recently on the list, that (i) 
> control messages are not forwarded, and that (ii) they are modified in 
> transit, the security/trust model is somewhat different from that of 
> 7181 and consequently for what 7182 was initially written for. I think 
> that  calling out the trust model, and how 7182 actually is used here, 
> might be what is called for.
> Continuing with the aside, this *especially* as the applicability 
> statement says: "Providing security for a reactive routing protocol 
> can be difficult”
>
> Thomas:
> 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:
> 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.
> 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?
> 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
> If this specification targets std.track, then it should include 
> (reasonably solid, but definitely well specified) MTI security.
>
> Chris Dearlove:
> - RREQ has an integrity check value to indicate that someone trusted 
> created it, if not necessarily the destination. That someone might be 
> identifiable or not.
> Unfortunately, an RREQ that changes as it is forwarded (aggregating 
> data of any sort) makes the second option tricky, unless there’s some 
> sort of aggregating signature as it is forwarded. But I’m not an 
> expert on the latter.
>
> The most trivial case of the former is simply that everyone trusted 
> has a single shared key. That has obvious issues – although it was 
> good enough that embodied as RFC 7183 we could get 7181 through the 
> system (as a “must implement, do not need to use” minimal case). 
> Alternatively something identity-based (e.g. draft-ietf-manet-ibs) 
> could be used, so you know who created the message you received, but 
> you are relying on a chain of trust, hop by hop. At which point you 
> might as well just sign packets (see RFC 7182).
>
> But in even the weakest case (the single shared key used hop by hop) 
> there has to be a failure for things to go wrong - either loss of key 
> (in which case all bets are off) or suborning one router (who can do 
> quite a lot of damage).
>
> I haven't read the latest AODVv2 draft yet, but this sort of thing 
> should be described in its security considerations - the previous 
> draft though didn't discuss this as far as I recall.
>
> Chris Dearlove:
> 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.
>
> Jiazi Yi:
> 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.
>
> There are “hosts” and there are “routers” — whose roles are well 
> defined. Node” not so much — which is clear from looking at the 
> definition here: “either AODVv2 routers or router clients” (with 
> “router clients” being defined as “an AODVv2 router is also its own 
> router client”).
>
> This is very much related to the use of “Router Client”, and both that 
> term, and “node” indicative that some clarity is needed here.
>
> All a router cares about is “an address”. If that address is of a 
> network, or a router, or an interface (and, if said interface is 
> installed in a router or a host) doesn’t matter.
>
> So, “an address” is something that the routing protocol should care 
> about finding paths to. Which means that each address that should be 
> made reachable by the routing protocol should be advertised by (at 
> least) one router in the network.
>
> One way of doing that would be to simply talk about “Attached 
> Networks” as is done in RFC7181, wherein an address included in the 
> “Attached Network Set” is advertised by an OLSRv2 router....in this 
> case, the equivalent would be “for each address in the Attached 
> Network Set of an AODVv2 router the router MUST respond 
> authoritatively to a RREQ, and MUST maintain the corresponding 
> sequence number”.
> I note that the terms “Node” and “Router Client” are still used, in 
> their original form, and that other than some slight wordsmithing this 
> comment has not been addressed in the document.
>
> I reiterate that the need to use router, host, node, and router client 
> in and by itself should be an indicator that tightening up of 
> terminology is required.
>
> My understanding, but correct me if I am wrong, is that all that is 
> required is that all interfaces in a given AODVv2 routing domain has 
> an unique address.
> That some of these addresses (by an IP addressing architecture 
> document) has special semantics associated (such as are link locals, 
> or are for private use, or are for example use only, or are for 
> multicast) is out of scope here?
> I see nothing has changed on the above, so let me be more explicit: 
> the routing protocol itself probably) should not care about what kind 
> of addresses are filled into it. Is an 192.16./16 address appropriate? 
> Not across the internet, but it may be in somebody’s private 
> deployments. Should the routing protocol be “address police” and is 
> implementation of a “I refuse to route these addresses…” a requirement 
> for claiming conformance? Suggest simply stating what the requirements 
> are under which the routing protocol will work — and leave “address 
> assignment politics” aside.
>
> AODVv2: We ask for clarification on this issue. We use the phrase 
> “routable and unicast” in the draft with respect to OrigAddr and 
> TargAddr. We dont mean to exclude addresses from the private address 
> ranges. But we dont want to request routes for multicast, 
> indeterminate, link-local, or loopback addresses. This is not about 
> router interface addresses which are used for AODVv2.
>
> Now, with that being said also, the WG wanted that RFC7181 supports 
> not just multiple interfaces, but also the same address used on 
> multiple interfaces of the same router. There were good reasons for 
> that, and while it was not trivial to implement, it turned out to be 
> the right thing to support. If there are technical reasons why this is 
> not supported in AODVv2 (for example, if this cannot be made work 
> because of <reason>) then that should be called out in the 
> applicability statement also?
> Conversely, if it is possible in AODVv2, then I do not believe that it 
> is clearly specified how (at least, in the “naive” on paper examples I 
> drew up, something ended up not working). So either the protocol as-is 
> does not support it (but could be made to?) or it is supported (but 
> just need to be spelled out), or is not possible (and need to be 
> disclaimed in the applicability statement).
> Stan Ratliff was a driving force in holding the WG’s collective feet 
> to the fire in getting this support included in RFC7181, and would 
> likely be the right person to consult on this matter?
> I actually have not seen changes, or comments, on this. In OLSRv2, the 
> WG was making it a strong requirement that it should be possible to 
> use the same IP address on different interfaces of a router. It was 
> somewhat tedious to design around, but it was worked out, and the 
> conditions under which that was possible were defined and documented.
> I also note that this is not unrelated to RFC6621-discussions. For 
> example, when selecting S-MPRs on a multi-interface and 
> multi-address-per-interface router, care must be taken least things 
> won’t work. So, if (and this links back to previous mails) RFC6621 is 
> a requirement or desire for this protocol, then there are some 
> considerations required here.
>
> Initial thoughts on this topic of multiple interfaces using the same 
> IP address, is that this wouldn’t cause a problem, if the router has 
> only one sequence number. However, this is up for further discussion.
>
> Better than before, but still missing the target. The term “Router 
> Client” is, as I indicated numerous times before, odd.
> But the second part of the sentence, does that mean (what it says) 
> that the interfaces must be configured specially, so as to be able to 
> be “router clients”? That can’t be true.
> What you likely mean is:
> An AODVv2 router is configured so as to consider its own interfaces as 
> part of the locally attached network set” ?
> You configure the router, right? No special “interface configuration 
> properties” are required for an interface to be announcable by  an 
> AODVv2 router? (And, getting rid of node would actually make the 
> definition shorter and nicer)
>
> AODVv2: The wording we use says: "The IP Addresses of the router's 
> interfaces will appear in the Router Client Table." and in the 
> Terminology: "The AODVv2 router's interface addresses are also 
> configured as Router Clients." Both statements say that ‘interface 
> addresses are configured as router clients’ ...we are not sure why 
> this is misunderstood. We have a router client list, and the AODVv2 
> router’s interface addresses are included in this list. The interface 
> itself doesn’t have special “interface configuration properties”.
>
> "Multi-homing of an IP address is not supported by AODVv2, and 
> therefore a Router Client, i.e. an IP Address,  … "
> AODVv2: That was there as a reminder that a router client is based on 
> IP address, even though the device with that IP address may have other 
> IP addresses too. It’s the IP address that is the router client, not 
> the device as a whole with its entire collection of configured IP 
> addresses. One IP address of that device might be configured as a 
> router client on one router, and a different IP address of that device 
> could be configured as a router client on another router. The IP 
> addresses would seem to AODVv2 to be on different devices.
>
>
> 14. data elements
>
> Thomas: The below is a little bit of a meta-comment, I am not quite 
> sure what I think here. The definitions for Target Node and such were 
> confusing before. They still are, somewhat.
> I think that it may be because the definitions now used are simply 
> copy-pasted out from the tables in the previous version, for example:
> OK, I can trace back and see that a Data Element is something that 
> exists inside a protocol message. To me, however, that’s not really 
> general terminology as such, but part of the specification of a packet 
> format - or rather, it is the notation that you use when describing an 
> algorithm. By the way, why are some notations in CamelCase whereas 
> others have a space in them, e.g. “Target Node” and “TargMetric”, both 
> of which are Data Elements? Would be good with a consistent approach here.
> I *think* that it would be better to take all those “Data Element” 
> bits and move to a separate section (or subsection) to the 
> terminology, and then keep all the “other stuff” (Neighbor, …) in its 
> own section.
>
> "Also suggest abolishing this table and folding the definitions in 
> with the other definitions in the terminology section."
> We have updated to not refer so heavily to the term Data Element. All 
> the terms are described in the Terminology section. Those in CamelCase 
> are used as message fields.
>
>
> AODVv2: Every route is to a specific address...the address is 
> specified by Route.Address and Route.PrefixLength.
> Do you mean that routes are to the address TargAddr or OrigAddr and 
> therefore to a specific host address rather than to a network prefix? 
> This is not the case. Prefix Length is included in AODVv2 messages so 
> that the route learned from the message represents the prefix which 
> OrigAddr or TargAddr resides on (if the router client entry 
> corresponding to OrigAddr at RREQ_Gen or TargAddr at RREP_Gen is 
> configured with a prefix length). e.g. OrigAddr is 10.0.0.1 but the 
> corresponding router client entry at RREQ_Gen could be10.0.0.0/8 
> <http://10.0.0.0/8>. So when constructing the RREQ you include a 
> prefix length of 8, and when receiving the RREQ and learning the route 
> to OrigAddr, you can install a route to10.0.0.0/8 <http://10.0.0.0/8>. 
> Text has been updated to make this more obvious.
>
> 16. unreachable address
>
> Thomas: I also made a comment on "Unreachable Address” - I am glad I 
> did, because I apparently had a different understanding than what was 
> intended. I now see that an Unreachable Address by definition is an 
> address listed in a RERR message, and not the same as an address to 
> which no route has yet been discovered? If yes, then please use a 
> different term, such as FormerlyReachableAddress” or something of the 
> sort?
>
> AODVv2: "Formerly reachable" is inaccurate... we send a RERR if 
> another router forwards a packet via us, and we dont have a route, not 
> just when we lose a route. We might never have had a route, or might 
> never have had a valid route, so the address may not have been 
> "formerly reachable". Also, I think "FormerlyReachableAddress" is a 
> really ugly term. Unreachable means "we don’t have a route and we 
> aren’t going to request one" or "we lost this route" (depending on why 
> the RERR is being sent). It doesn’t mean "we didn’t request one yet", 
> and it would be wrong to class an address as unreachable because we 
> hadn’t requested a route for it yet, that is, assuming it’s configured 
> as a router client.
>
> If a better term is suggested we could consider changing but at the 
> moment we have kept “Unreachable Address”.
>
>
> Thomas: Applicability statement: First, I would like to recognize the 
> efforts made to improve this since last review. Thanks
> Second, the document states: "AODVv2 supports routers with multiple 
> interfaces, as long as each interface configured for AODVv2 has a 
> unicast IP address.  A router may use the same IP address on multiple 
> interfaces.  Address assignment procedures are out of scope for AODVv2.”
> Is that true? Granted, I have not worked this through in detail, but I 
> can present a counter-example: the use of RFC6621 means that there 
> certainly are some constraints that must be respected least various 
> flooding optimizations may not work.
> Secondly, if the multiple-interfaces-with-same-address are on the same 
> L2, and this is what I have not worked through, are there any 
> situations that will not work?
> "AODVv2 supports routers with multiple interfaces, as long as each 
> interface configured for AODVv2 has its own unicast routable IP address"
> AODVv2: Well, based on previous questions on this, we talked it 
> through and decided there shouldn’t be an issue if different 
> interfaces of a router used the same IP address. Note that we changed 
> AODVv2 so that there is one sequence number per router. No longer can 
> a router use different sequence numbers on different interfaces. If an 
> RREQ went out of two interfaces using the same address, we worked it 
> through and decided the request would be processed correctly.
> I think that appendix B needs to be removed. Essentially, it makes 
> claims that it is possible to do multi-homing — but neither specifies 
> how it is done, nor gives pointers to documents that justify the claim.
> AODVv2 does not support multi-homing — that’s clear, and it is fine 
> that it is called out here. Thank you for that.
> Now, with that being said, I am torn between being satisfied that it 
> is called out on one hand, and wanting to have “multi homing” on the 
> other hand. RFC7181 supports multi-homing, FWIW.
> I believe that this also would merit some explicit discussion by the 
> WG, in order to understand if this design decision is acceptable?
> I see that Appendix B still is in the document, and I do not recall 
> having seen this discussed on the mailing list. Simply removing the 
> reference from the Applicability Statement to Appendix B does not 
> address the issue that I raised in my previous review.
>
> In general, there are a lot of such “maybe normative language” through 
> the document, and I would much like to see an editorial pass — 
> essentially all may/should/ must and friends carefully evaluated as if 
> they should become 2119-terms, and ... more importantly (it has been 
> called out before, fwiw) quite a bit of should/SHOULD which ought to 
> be transformed into MUST.
> As indicated earlier, I believe that the term “Router Client” is ill 
> chosen. I believe that it is more appropriately an “Attached Network 
> Set” since — as indicated previously — the term “Router Client” is 
> ambiguous. I am pleased to see, though, that this “Router Client List” 
> in reality is an “Attached Network Set” and so that change should be 
> (relatively) easy.
> Also, I recommend to not say “subnet” — how about rephrasing to “If a 
> prefix is included in the attached network set of an AODVv2 router, 
> then that AODVv2 router MUST provide connectivity for, i.e. answer to 
> RREQs and maintain sequence numbers for, all addresses from within 
> that prefix.”
> I note that while the term has been removed from section 4, there’re 4 
> lingering instances of this term in the document, that could easily be 
> removed.
>
> AODVv2: All mentions of "subnet" were in the ENAR section. They have 
> been updated to say network, or "networks attached to the routers"
>
>
> Thomas: I Also made a comment about Appendix B in my previous review, 
> which is referenced here. That comment still applies.
>
> Does section 6.2 describe how to monitor an established adjacency 
> only, or how to discover neighbouring AODVv2 routers? Looking in 6.2, 
> I see
> “Not every pair of neighboring routers will necessarily form an 
> adjacency,” — so it likely isn’t 6.2 that tells me how to maintain 
> this table?
> “The default approach for monitoring bidirectional connectivity to the 
> next hop toward OrigAddr is to request acknowledgement of Route Reply 
> messages.”
> That certainly will tell me if a link over which an RREP is sent is 
> bi-directional, but will not maintain a “neighbor table”.
> So how is this done? Or, is the “Neighbor Table” not supposed to 
> contain the complete set of neighbours? What information “...MUST be 
> maintained” then, in this table?
> This is very unclear, I would not know how to implement a mechanism 
> that populates this “Neighbor Table” with the needed information here.
> AODVv2: A new section was added to show how to update the neighbour 
> table. There have also been updates to this entire section since 
> version 12.
>
> 24.     pseudo-code
>
> Thomas:
> I am throwing this in here, as I am sure that I commented on that in 
> the previous review, but I do not see that addressed: is Appendix C 
> normative, or not? It represents “ a second specification of the 
> protocol, in a different language” from the main part of the 
> specification. I have not walked through and made 200% sure that both 
> are perfectly aligned and that there are no ambiguities, but having 
> two different specifications of a protocol is a recipe for disaster.  
> Please either make 2000% sure that they are specifying the same thing 
> without ambiguities, or remove one.
>
> "would like to nit-pick that: the router can maintain this sequence 
> number in whatever format it pleases — but, when it includes it in 
> control messages, it must be representable in a specified format, 
> respecting certain rules.”
> AODVv2: Why store it as anything other than what it needs to be when 
> it goes into a message? However, we now state "MUST report its own 
> sequence number as a 16 bit....whenever it creates a RREQ or RREP 
> message".
>
>
> 26. multiple seqnums?
>
> Thomas:
> To section 4.4 I asked for clarification as to if sequence numbers 
> were per interface or per router, as the specification was unclear on 
> that. The words has changed, but it still is unclear: how many 
> sequence numbers does a router maintain? One? One per interface?
>
> AODVv2: We tried to start discussion on that point, and in the 
> meantime we reverted to having 1 seqnum per router. We think the text 
> is clear... we refer to "the routers sequence number" or "its sequence 
> number" - never hinting that there could be multiple seqnums per 
> router (as far as I'm aware).
>
>
> 27. sets/lists/tables
>
> Thomas:
> In my previous review, I expressed that it would be preferential to 
> use “a notation of Sets” rather than tables. I see that this has not 
> changed.
>
> AODVv2: You preferred sets rather than lists in your previous 
> review...and explained our reasoning for this in responses to the 
> MANET list, and we did not receive further comments.
>
>
> 28. use of “node”
>
> Thomas:
> An IP address of the node which requires the route, i.e., the source 
> address of the IP packet triggering the route request.
> All AODVv2 routers MUST maintain a route table.  The route table entry 
> is a conceptual data structure.  Implementations MAY use any internal 
> representation but MUST contain the following information:
> In order to avoid confusion, rename this to “Routing Information Base” 
> or “Routing Set” — a Routing Table is an operating system construct, 
> whereon operations directly influence packet forwarding. What you are 
> defining here is a RIB/an RS.
>
> The confusion that I pointed out in my previous review on “IP address” 
> and “Address” being used a bit haphazardly persists, fwiw. It makes me 
> think, can a router send an RREQ for a prefix?
>
> AODVv2: See also #15. RREQ_Gen can include the prefix associated with 
> OrigAddr by adding a prefix length to the message, the prefix length 
> associated with the router client entry corresponding to OrigAddr. So 
> all routers which receive it can learn a route to the prefix on which 
> OrigAddr resides. But for TargAddr... the RREQ only has one target IP 
> address - the destination IP address of the packet requiring the 
> route... so what prefix length would it use? The RREQ requests a route 
> to a single IP address. However, when the RREP is created, RREP_Gen 
> should include the prefix length associated with the router client 
> entry for TargAddr. So all routers which receive this RREP learn a 
> route to the prefix TargAddr is part of (if the router client entry is 
> configured with a prefix length). The text has been updated to make 
> this more obvious.
>
>
> If that “message” is an RFC5444 entity, then it does to have a “source 
> IP Address” — the encapsulating IP datagram containing the packet 
> containing the message does. And the message MAY have an Originator 
> Address
>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 16 Mar 2016 21:28:41 +0000

You said that the paper hadn't identified a loop. If you'd stopped there, that would have been fine. I think I can see where they were assuming rather strange behaviour.

But you then went on to say "Other discussion about routing loops has not identified routing loop problems in the existing specification." That goes further and indicates no other discussion about loops. But Lotte has just said that there was other discussion. More, she says two loops were identified (and now fixed).

In addition, you're now saying that unconfirmed routes can't form a loop. That may be so, as I said I haven't considered the case. But Lotte just said there were two loops that needed fixing.

The problem is that the statements the authors are making are contradictory. And that leads to a lack of confidence.

-- 
Christopher Dearlove
[email-masked]

> On 16 Mar 2016, at 20:32, Charlie Perkins <[email-masked]> wrote:
> 
> 
> Hello Chris,
> 
> I stand by my statement.  The cited paper did not identify a loop.  Most importantly, the crucial part about route looping being prevented by sequence number still stands.  I also point out that the authors of that paper were constructive and complimentary to the clarity of the AODVv2 specification.  I truly hope we can work together with them to further prove the correctness of the protocol.
> 
> Regarding the situation with unconfirmed routes, please not that unconfirmed routes can never be part of a routing loop because they don't carry data.
> 
> Regarding the off-list discussion, it is our online equivalent of a hallway discussion, and a manageable, constructive environment for us to produce responsive resolutions to the comments from you and others.  I hope we will see the rest of your comments soon because we want to resolve them as soon as possible.  We were honor-bound to not disclose private information to the list, but as you can see we also work hard to resolve privately submitted comments.
> 
> Regards,
> Charlie P.
> 
> 
>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>> If you feel the email is suspicious, please follow this process.
>> 
>> Hi Christopher,
>> 
>>  
>> 
>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>> If you feel the email is suspicious, please follow this process.
>> 
>> Hello Chris,
>> 
>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>> If you feel the email is suspicious, please follow this process.
>> 
>> *** WARNING ***
>> Do you mean that routes are to the address TargAddr or OrigAddr and therefore to a specific host address rather than to a network prefix? This is not the case. Prefix Length is                           included in AODVv2 messages so that the route learned from the message represents the prefix which OrigAddr or TargAddr resides on (if the router client entry corresponding to OrigAddr at RREQ_Gen or TargAddr at RREP_Gen is configured with a prefix length). e.g. OrigAddr is 10.0.0.1 but the corresponding router client entry at RREQ_Gen could be 10.0.0.0/8. So when constructing the RREQ you include a prefix length of 8, and when receiving the RREQ and learning the route to OrigAddr, you can install a route to 10.0.0.0/8.  Text has been updated to make this more obvious.
>> 
>> 16. unreachable address
>>

---

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

Hello Christopher,

> Am 16.03.2016 um 18:22 schrieb Dearlove, Christopher (UK) <[email-masked]>:
> 
> But we have a loop, a pretty fundamental problem in a routing algorithm, being discussed by the authors off-list,

If we could’ve, I would’ve loved to share this with the list immediately. I’m not sure if there’s a procedure for this kind of situation we should’ve followed? If there is, I’d be more than happy to learn from it and do better next time.

> while in parallel assuring the list that “Other discussion about routing loops has not identified routing loop problems in the existing specification.” (see email chain below).
>  

I think I understand where your worries come from. However, I do think our efforts to improve our communication are visible, and apart from the communication delay, the fact that this research exists actually improves my confidence in the document: It found loops that were (imho) pretty tricky to come up with by thinking hard about the problem alone, and we’ve been able to fix them, making AODVv2 more solid.

> (I still haven’t managed to even write up comments on the perhaps one third of the draft I have read through yet.)

Personally, I’d be happy to go through them in chunks as well :) Maybe that could also speed up the back and forth of „x isn’t quite right“ „would y resolve the issue?“ „yes/no“, which would in turn speed up the progress of this document? Anyhow, all feedback is very welcome.

Best regards,
Lotte Steenbrink

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 17 Mar 2016 16:40:43 +0000

There is a problem when you have information that isn’t public. Though if it’s sent to you wearing IETF hat, is it covered by Note Well?

But let’s suppose you’ve decided you can’t give details. You probably can still say “Someone has raised an issue with us, we’re trying to get it handled.”. What you (one) can definitely do is bear that in mind and not makes statements that will later appear to be at odds with what you then knew.

I’m still not clear as to whether there was a late discovered real problem that needed fixing.

Sent: 17 March 2016 16:19

*** WARNING ***

Am 16.03.2016 um 18:22 schrieb Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>>:

Best regards,
Lotte Steenbrink

---

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

> On 17 Mar 2016, at 17:40, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 

This is actually an interesting point. As one of the WG chairs is also an author, I would assume that he’d have been a recipient of this information, and that therefore very much should be covered by Note Well?

> I’m still not clear as to whether there was a late discovered real problem that needed fixing.

I’m with you on that one, coming down on the “…need to be convinced” side of the fence, however.

Thomas
 
> From: Lotte Steenbrink [mailto:[email-masked] <mailto:[email-masked]>] 
> Am 16.03.2016 um 18:22 schrieb Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>>:
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 20 Mar 2016 15:47:11 +0200

Hi All,

I did not read on the list that AODVv2 has problems in loops (IMO: no
participant reported this), it may happen outside the IETF because some
people may not understand AODV and we can advise them. I don't know why
participants are discussing a loop-problem that was not reported in details
in IETF.

Sorry that I don't understand the discussion of a problem that was not
defined, please help (I hope the participant that has the loop-problem to
respond because I still don't know who was the implementor)

AB

AB

On Thu, Mar 17, 2016 at 6:45 PM, <[email-masked]> wrote:

> There is a problem when you have information that isn’t public. Though if
> it’s sent to you wearing IETF hat, is it covered by Note Well?
>
>
> This is actually an interesting point. As one of the WG chairs is also an
> author, I would assume that he’d have been a recipient of this information,
> and that therefore very much should be covered by Note Well?
>
> But let’s suppose you’ve decided you can’t give details. You probably can
> still say “Someone has raised an issue with us, we’re trying to get it
> handled.”. What you (one) can definitely do is bear that in mind and not
> makes statements that will later appear to be at odds with what you then
> knew.
>
> *Christopher DearloveSenior Principal EngineerBAE Systems Applied
> Intelligence Laboratories*
>
> *__________________________________________________________________________*
> *From:* Lotte Steenbrink [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* 17 March 2016 16:19
> *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>.*
> Hello Christopher,
>
>
> I haven’t followed the example (I hope to find time - but that’s true of
> too many things, with DLEP ahead of AODVv2 on this list).
>
> If we could’ve, I would’ve loved to share this with the list immediately.
> I’m not sure if there’s a procedure for this kind of situation we should’ve
> followed? If there is, I’d be more than happy to learn from it and do
> better next time.
>
>
> while in parallel assuring the list that “Other discussion about routing
> loops has not identified routing loop problems in the existing
> specification.” (see email chain below).
>
>
> I think we have a real problem with what’s wanting to advance to Proposed
> Standard soon, in terms of process and confidence.
>
>
> I think I understand where your worries come from. However, I do think our
> efforts to improve our communication are visible, and apart from the
> communication delay, the fact that this research exists actually improves
> my confidence in the document: It found loops that were (imho) pretty
> tricky to come up with by thinking hard about the problem alone, and we’ve
> been able to fix them, making AODVv2 more solid.
>
>
>
> Personally, I’d be happy to go through them in chunks as well :) Maybe
> that could also speed up the back and forth of „x isn’t quite right“ „would
> y resolve the issue?“ „yes/no“, which would in turn speed up the progress
> of this document? Anyhow, all feedback is very welcome.
>
> Best regards,
> Lotte Steenbrink
>
>
>
>
>
> *--*
>
>
>
>
> *Christopher DearloveSenior Principal EngineerBAE Systems Applied
> Intelligence Laboratories*
>
> *__________________________________________________________________________*