Re: [manet] AODVv2 responses to recent comments

"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Wed, 02 March 2016 10:37 UTC

Return-Path: <chris.dearlove@baesystems.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7D71ACDF8 for <manet@ietfa.amsl.com>; Wed, 2 Mar 2016 02:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.705
X-Spam-Level:
X-Spam-Status: No, score=-5.705 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpEQ2Aeb2iDo for <manet@ietfa.amsl.com>; Wed, 2 Mar 2016 02:36:46 -0800 (PST)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13841ACE44 for <manet@ietf.org>; Wed, 2 Mar 2016 02:36:33 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.22,528,1449532800"; d="scan'208,217"; a="48364491"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 02 Mar 2016 10:36:30 +0000
X-IronPort-AV: E=Sophos;i="5.22,528,1449532800"; d="scan'208,217";a="108487305"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 02 Mar 2016 10:36:30 +0000
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.232]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Wed, 2 Mar 2016 10:36:30 +0000
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Charlie Perkins <charles.perkins@earthlink.net>, manet <manet@ietf.org>
Thread-Topic: [manet] AODVv2 responses to recent comments
Thread-Index: AQHRUjmenBx9hbwuBk28hYSwiXsxV58C1pBAgEEypICAAjAlcA==
Date: Wed, 02 Mar 2016 10:36:29 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D8C0227E6@GLKXM0002V.GREENLNK.net>
References: <CAAePS4DCds3_vqJ8jwymmHWJdH4jXg=ksJ8RO4QqRFL77py7ng@mail.gmail.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D8A6F4A3D@GLKXM0002V.GREENLNK.net> <56D4EB7D.4010002@earthlink.net>
In-Reply-To: <56D4EB7D.4010002@earthlink.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C0227E6GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/S6Y31_q8MMZy18CP6noXZFMBLWg>
Subject: Re: [manet] AODVv2 responses to recent comments
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2016 10:37:00 -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: chris.dearlove@baesystems.com<mailto:chris.dearlove@baesystems.com>

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:charles.perkins@earthlink.net]
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: chris.dearlove@baesystems.com<mailto:chris.dearlove@baesystems.com>

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:manet-bounces@ietf.org] 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

manet@ietf.org<mailto:manet@ietf.org>

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