No objections here. Ask away.
Regards,
Stan
Sent from my iPhone
On Apr 7, 2016, at 12:07 PM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello folks,
RFC 6551 provides a table of metrics.
We can use that.
Or we can duplicate it.
I think the routing AD should tell us which is preferable. For those who
weren't around, the commentor below made serious and permanent enemies in
[roll] and so would probably like to avoid validating any of the work done in
that group.
Regarding the usefulness of the OLSR metric -- notably, it does not measure
anything. But it should still be considered an option for AODVv2 as well, and
so we could ask for it to be registered in the RFC 6551 metric table.
Or whatever metric table is recommended by the Routing AD. Any objection if I
ask?
Regards,
Charlie P.
On 4/7/2016 7:40 AM, Lotte Steenbrink wrote:
*bump*
anyone remember the metrics discussion? please? we’ve got to come up with an
answer, folks...
Am 19.03.2016 um 12:41 schrieb Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>>:
Hi all,
I’ve replied to Thomas where I could, but some points need to be addressed by
someone else (or discussed here and then addressed).
I’m on his side regarding the Metrics thing because I’ve been a fan of OLSRv2’s
metric notation when I finally understood what it was all about (thanks to
Henning), but I think we had a discussion that brought up some very good points
why it’s just not that simple for AODVv2. Unfortunately I can’t remember them!
:( Does anyone else?
Regards,
Lotte
Anfang der weitergeleiteten Nachricht:
Von: Lotte Steenbrink
<<mailto:lotte.steenbrink@xxxxxxxxxxxx>lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>>
Betreff: Aw: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket
Items
Datum: 19. März 2016 um 12:34:39 MEZ
An: Thomas Heide Clausen
<<mailto:ietf@xxxxxxxxxxxxxxxxx>ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>>
Kopie: Mobile Ad Hoc Networks mailing list
<manet@xxxxxxxx<mailto:manet@xxxxxxxx>>
Hi Thomas,
thank you for reviewing AODVv2 yet again :) Some answers below:
Am 17.03.2016 um 17:00 schrieb <mailto:ietf@xxxxxxxxxxxxxxxxx>
ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>:
Dear all,
Apologies for not having gotten this done sooner - day-job leaving few spare
cycles.
I’ve previously offered reviews and comments, and some of those have been
addressed in the latest I-D — others have not, but should be. I recall that
there was some mail attempting to rebut parts of the review, and I will dig it
out and reply to that.
That wold be great.
With that being said, I have reviewed the latest version of the document, and
full details will be forthcoming. There’re a couple of big-ticket/architectural
items that I want to address up front, as I believe that before we have those
hammered out, it will be useless to go into details. Note, I do not claim that
this is an exhaustive list of “big ticket items”, but that’s as far as I have
gotten in thinking this through.
I also bring these up as they are items that have been brought up repeatedly
over the past years, but not resolved nor discussed.
Loops
Just to bring this out: I share Chris’ worry about conflicting and concurrent
statements from the authors on “There are no loops possible” and “We need to
fix two situations where loops can occur” and “we are still investigating some
loop conditions”
I particularly worry that this is not a discussion had in public, but
apparently in some other forum…
Intermediate Route Replies, and all of section 10
Section 10 contains a set of “vaguely specified extensions”, which is
incoherent with the intended status indicated for this document.
Specifically, and this is not unrelated to the point about loops above,
intermediate RREPs (section 10.3) are a potential source for loops.
Expanding Ring Multicast (section 10.1) is not documented in a way that can be
implemented (and also, see “Forwarding-vs-regeneration” below, it is in the
present form of this protocol impossible), etc.
Forwarding-vs-regeneration
Recent exchanges on the list made me understand that protocol control messages
are *not* forwarded, but are consumed at each hop, then a new message with
(almost-but-not-quite) the same content is generated and transmitted.
That’s what we’ve been trying to say all along! I’m really glad we’re having
this conversation.
I have thought some more on this (& read some of the exchanges on the list on
this topic by Chris, Ulrich, and others), and I am convinced that this is not
the right way to go, at least for the following reasons:
o It renders the hop-limit/hop-count fields in the RFC5444 message header
useless.
This would not be bad if the functionality offered by those fields was not
useful
— sadly, it is. For example, for scope limited flooding (expanding ring search,
and
such) which may be of interest, and which require hop-limit.
A hop-count field may also provide a “cheap” (in terms of overhead) additional
piece
of information to use conjunctively with a “real” metric.
I agree on the usefulness, which is why we were puzzled when we were told we
weren’t allowed to use those fields (or, rather, that we were using them wrong,
but that the right way to use them doesn’t work for AODvv2). I believe Vicky
has written about this in more detail in previous discussions, and we were/are
looking forward to reading your answers...
The only practical solution would be to re-introduce these functions by way of
inserting a
MessageTLV — which (i) is not specified in this document, and (ii) which would
just
serve to render messages bigger than strictly needed.
Exactly; we’d really like to avoid this as well.
Scope limited flooding does seem to be a necessary requirement, if for no
other reason than to prevent information from “circulating forever in the
network”.
AODVv2’s duplicated detection hopefully should take care of that. Iirc, We
interpreted your earlier E-Mails to (implicitly) mean that you think we should
rely on that, since you said we can’t use the hop-limit/hop-count fields.
o It makes end-to-end authentication unnecessarily hard.
I think Chris called this out already, but it bears repeating: S generates a
message
(say, a RREQ), and includes an ICV calculated over the content of the message.
For any recipient to be able to validate the ICV, the message has to be exactly
the same — not just in content, but in structure — as what was generated.
“Regenerating” rather than “forwarding” messages means, that the intermediate
router “regenerating” the RREQ may chose a different structure (e.g., include
TLVs
in a different order).
The proposal from
<https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00>
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
is to add constraints on (i) the set of elements to include in a signature and
(ii) the
order of these elements.
One problem with that approach is (i): if an extension adds a message TLV, or an
Address TLV, to a message, then that will not be “covered” by the proposed
e2esec TLV.
Rather for *each* extension developed, an “updates e2esec” clause needs to be
done.
I’d say that this approach would be prone to errors — and add entropy to the
process
of designing protocol extensions. The alternative, a message being generated by
the
source and *forwarded* (as we do in OLSRv2, for example) would allow ICV TLVs
(even, allow reuse of those specified for OLSRv2) for covering a message and
extensions.
“But what about the metrics value which will change on each hop”, you may say?
Fortunately, that is relatively easy to handle: simply zero out the value of
that TLV when
generating or verifying the ICV MessageTLV. And use Packet-TLVs for hop-by-hop
authentication, if needed (but, see below).
o It prevents the use of more clever/advanced signature schemes/ICVs
Aggregate signature algorithms (
<https://crypto.stanford.edu/%7Edabo/papers/aggsurvey.pdf>
https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
exist, and an interesting use-case can be found in also reactive protocols,
allowing verifying
not “just” the end points, but also the intermediaries (again, with the
appropriate “zero out”
discussed above, or something smarter).
Regeneration of messages, rather than forwarding, renders that impossible (or,
if used,
updating to https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
There are other reasons, but the above are those that jump at me as immediate
show-stoppers.
I do honestly not see what possible benefit there is from “regeneration” — but
I see very clear inconveniences, and security is not the least of these.
Insisting on “regeneration” requires development of “non-general workarounds”
as pointed out above.
The possible benefit is that we need to accumulate & transport metric values
somehow, and we can’t do that without regenerating at least parts of the
message.
If we’re missing a solution here, please share it with us.
Security Considerations
Just for context’s sake, did you review the security considerations in
draft-ietf-manet-aodvv2-13 or the ones proposed in the thread „AODVv2: Security
considerations update“?
This is an always thorny subject. When OLSRv2 was going through the process we
got a thorough education in how little we knew about security from the SEC-ADs,
and had to spend about a year or so developing RFC7183. The bottom line is,
that this protocol needs its “RFC7183 equivalent”, either as part of the main
document, or as an independent document. currently, that is not the case.
A minima, looking at BCP72 and BCP107 — taking inspiration from RFC7183 might
be aw good idea, as that was the most recent that went through the SEC AD.
Regardless of how, however, a “mandatory to implement” security mechanism most
be specified (I think the right term was “MUST implement, SHOULD use”), in
sufficient detail to ensure interoperable implementations.
As an example, both [RFC6130] and [RFC7181] set out that that:
On receiving a ... message, a router MUST first check if the
message is invalid for processing by this router
and then proceed to give a number of conditions that, each, will lead to a
rejection of the message as "badly formed and therefore invalid for processing”
— a list which RFC7183 then amended. That gave a “hook” for RFC7183 for
inserting “rejection”. Idem for message generation.
If I was to do RFC7181/RFC6130 today, I would include that directly into the
protocol specifications. It turned out to be more overhead (and slow down
publication anyways) to do it as separate documents.
Secondly, we need to be a lot more rigid in terms of what ICVs, Timestamps,
etc. are added/removed, and what that brings.
For example (with the assumption that messages are *forwarded* and *not*
regenerated), this could be one option:
o When a RREQ, RREP message is generated, add an ICV Message TLV, which is
calculated <this way>
…(take inspiration from RFC7183 here)
o When a RREQ, RREP message is transmitted (by the source, or forwarded by an
intermediary)
in an RFC5444 packet, an ICV Packet TLV is added to the packet, which is
calculated <this way> …
o When an RFC5444 packet is received, validate the ICV Packet TLV <this way>
and if the ICV doesn’t validate,
discard the contained messages.
o When receiving a RREQ/RREP (either as destination, or as an intermediary),
validate the ICV Message TLV
<this way> and if the ICV doesn’t validate, discard the message, do not
process, do not forward.
This is a different (and more flexible?) model than “just” transitive trust and
“just” end-to-end trust discussed previously, and is enabled by the
“forwarding” bit described previously.
Metrics
I have asked this numerous times, but have not gotten any answer so I am
escalating this again. Why is this document having a normative reference to
RFC6551?
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC
6551<https://tools.ietf.org/html/rfc6551>, DOI 10.17487/
RFC6551<https://tools.ietf.org/html/rfc6551>, March 2012,
<http://www.rfc-editor.org/info/rfc6551>.
Unless I am mistaken, this is not the ROLL WG. And the abstract to RFC6551
explicitly reads:
Low-Power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired and ad hoc networks that require the
specification of new routing metrics and constraints.
Which explicitly is disclaiming that these metrics are not applicable in ad hoc
networks — and, I am wondering, what has changed since the publication of
RFC6551 to suddenly make these applicable?
I am also wondering if looking at (and, perhaps, using?) the same metric type
TLV type as in OLSRv2 is not a possibility?
Either way, referencing RFC6551 here is wrong.
RFC6621 (SMF) usage
As late as earlier this month, RFC6621 reared its head again on the mailing
list. I understand that the authors are set on using flooding reduction as part
of RREQ distribution. If that is the case, then this protocol MUST specify that
flooding reduction.
Saying “Use RFC6621” won’t work, for reasons Chris point out in an email
earlier to the list:
The network does not and fundamentally cannot offer multicast suppression to
AODVv2. This isn't a hard concept, but seems to keep having to be said. AODVv2
messages are carried in 5444 packets, and those only travel one hop. That
doesn't allow for suppression. Furthermore AODVv2 is creating new messages each
hop. That needs AODVv2 specific handling.
And quoting an email from myself:
If protocol X relies on using a flooding operation, then it certainly is
protocol X's responsibility to specify the flooding operation (or, at least,
the requirements to the flooding operation ) for correct functioning of
protocol X.
I’ve previously pointed out that RFC6621 requires some degree of configuration
(can’t just, for example, pick two different relay set selection algorithms, as
that may produce a disconnected flooding domain).
In other words, what the authors propose in
<https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00>
https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00 is ;
insufficient.
Multiple interfaces configured with the same address(es) - & RFC6621
I think that it has been established that the ability to use the same address
on multiple interfaces is a requirement. It’s not clear to me that a single way
of doing so has been proposed, nor that the “operating conditions” are called
out (for example, will it work if router A and router B both have two
interfaces, and that all 4 interfaces use the same IP address?)
This is not entirely unrelated to flooding reduction and RFC6621. One of the
complexities is to get that just right: OLSRv2 - for example - calculates
Flooding-MPRs per interface, and RFC6130 is careful in how it detects
bidirectionality of links.
I have not worked out all the details of how this impacts this protocol — but,
it requires attention. Especially when wanting to be able to say “…use
RFC6621”, then the interface configuration constraints when faced with multiple
interfaces must be worked out.
Prefixes & Gateways
A question to my mind, and I am not sure I know how to answer that from reading
the draft since it is not discussed in section 9 (at least), is: “What happens
if I send a RREQ to a prefix” (i.e., a /<128 in IPv6)?
o If the whole prefix is part of the attached network set of a single router,
then I expect to get a single RREP back, is that the case?
o If "half the prefix" is part of the attached network set of a single router,
and the other half is part of the attached network set of another single
router,
then I expect two RREPs, is that the case?
o More generally, will I get a tree build through the network here?
AODVv2 currently doesn’t support RREQs for prefixes. I’ve already added „If
RteMsg is a RREQ, RteMsg.TargPrefixLen SHOULD equal address length.“ to
RteMsg.TargPrefixLen in section
4.6<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-4.6>.
Multicast Route Message Table in response to Justin’s comments, but I’ll go
through the draft again and see where we need to state this more clearly.
Best regards,
Lotte Steenbrink
Section 9 (or, the whole spec) is also not explicit enough about multiple
"default gateways" — i.e., the external network being “the rest of the
Internet”, and there being multiple gateways to the Internet. I understand how
the RREQ gets to the gateway, and how the gateway determines if it should
respond (the destination is not part of “the MANET prefix, with which it is
configured”).
But, if A is close to GW1, and B is close to GW2, but A and B being far far
apart (according to the metric used) within the MANET, then it would be
preferential for the route from A to B to go via GW1-“the-Internet”-GW2?
Is this a supported configuration?
o If yes, how is it (seq# wise, I would expect some complications) handled?
o If not, where is it stated that this configuration is not possible with this
protocol?
The applicability statement says:
AODVv2 is designed for stub or disconnected mobile ad hoc networks,
i.e., non-transit networks or those not connected to the internet.
AODVv2 can, however, be configured to perform gateway functions when
attached to external networks, as discussed in Section
9<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-9>.
I believe that the scenario I describe is indeed a stub network (and not a
transit network)?
— — —
As I indicated, these are the big-picture issues that I have gotten around to
thinking about enough to write up. I’m not through working through the
document, but those were the ones that came to mind, and which seem imperative
to resolve.
Best,
Thomas
_______________________________________________
manet mailing list
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________