Hi all,
for the sake of completeness, the paper we’ve mentioned is available on arXiv
now:
http://arxiv.org/abs/1604.07179
And you can find the code of the tool that was used here:
https://github.com/b-yousefi/wRebeca
Kind regards,
Lotte
Am 16.03.2016 um 18:12 schrieb Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx>:
Hi Christopher,
Am 02.03.2016 um 11:36 schrieb Dearlove, Christopher (UK)
<chris.dearlove@xxxxxxxxxxxxxx <mailto:chris.dearlove@xxxxxxxxxxxxxx>>:
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:
<network.jpg>
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:
<network.jpg>
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
<http://arxiv.org/> for now…
Best regards,
Lotte
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T: +44 (0)1245 242194 | E: chris.dearlove@xxxxxxxxxxxxxx
<mailto:chris.dearlove@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxx ;
<mailto:charles.perkins@xxxxxxxxxxxxx>]
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@xxxxxxxxxxxxxx
<mailto:chris.dearlove@xxxxxxxxxxxxxx>
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@xxxxxxxx ;<mailto:manet-bounces@xxxxxxxx>]
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
<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 ;
<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@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet ;
<https://www.ietf.org/mailman/listinfo/manet>
_______________________________________________
manet mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet ;
<https://www.ietf.org/mailman/listinfo/manet>
