Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

From: Victoria Mercieca <[email-masked]>
Date: Sat, 23 Apr 2016 00:26:58 +0100

Hi all,

Continued in this thread because the other one seems to be more about TLV
types and metric type numbers, whereas this is about
regeneration/forwarding.

To recap, in the current draft, there are 3 things that might change at
each hop:
- the metric value (happens in RREQ and RREP),
- adding/changing Validity Time using the Validity Time TLV (can happen in
RREQ and RREP),
- adding an address (and corresponding value in the AddressType TLV to
indicate how to interpret the address) to indicate the address from which
an RREP_Ack is expected, to accomplish the bidirectionality check (can
happen in RREP).

If we define a certain portion of the message as immutable and include the
ICV to verify that part, end to end:
- The metric value would be excluded from the ICV since it needs changing
at each hop.
- Would adding a Validity Time TLV at an intermediate hop be acceptable?
The whole TLV could be removed in order to calculate the ICV?
- Would adding an address cause issues for the ICV, because it's in the
address block? Could the rule be "if it contains an AckReq address, remove
it (and the corresponding value in the AddressType TLV), before checking
the ICV", is that OK? Or would we need to avoid touching the ICV'ed part of
the message altogether, maybe put the AckReq address in a separate Address
Block, with an extra AddressType TLV following that address block? Is there
a way to accomplish this?

Also, to be thorough, do we need to consider RERR messages while we discuss
regeneration vs forwarding?
- RERR (sent when a link breaks) is a way of saying "I've lost my route so
I'm telling others" and "you were my next hop, so now I've also lost my
route, I'll tell others", etc. It's going to be tailored at each step to
include the relevant routes that got deleted, it's not one message being
sent end-to-end like RREQ and RREP are.
- However, RERR (sent when a source of traffic is sending data on a route
which comes through you, and you want to tell the Packet Source's router to
delete the route) could be seen as an end-to-end message which all
intermediate routers learn from, similar to RREQ and RREP. It reports one
route, and doesn't need changing at intermediate hops, so could be
protected with ICV.
- Would it be OK to only require a message ICV if a PktSource address was
included, i.e. when the message needs to go via a number of intermediate
hops to PktSource's router? All other RERRs are intended to be one-hop
messages, which may in turn prompt other one-hop messages, etc..., and a
packet ICV might be more appropriate?

Kind regards,
Victoria.

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

>
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
> [email-masked]> wrote:
>
> Yes, I meant AODVv2, thanks for the catch.
>
> So is your (Thomas) proposed base specification a hop count only metric?
>
>
> No, the would be silly as base specification, given that hop count mostly
> is useless.
>
> As base specification I would simply say “Include a Metric Type Message
> TLV with a value field, and a 7182 Message TLV & Timestamp” as we do in
> OLSRv2 (with the appropriate verbiage as to generation and processing).
>
> With the message generated by the originator of the RREQ/RREP and *not*
> deconstructed/reconstructed/reordered (as is the risk with “regeneration)
> allows knowing that it would be *only* that metric field being modified
> (other than hop count/limit) for when eventually writing up the extension.
>
>
> (Actually doesn’t the current specification only define hop count, or has
> that changed in latest draft?)
>
>
> No. That is one of the issues I raise in my original. For some reason, it
> cites RFC6551, which is a ROLL document and which has in its abstract that:
>
>    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.
>
>
> I.e. this document cites a metric document which clearly claims to be
> inapplicable in ad hoc networks. I note that this is another thing I’ve
> raised for years without seeing it attempted resolved.
>
> Best,
>
> Thomas
>
>
>
>
> *--*
>
>
>
>
> *Christopher DearloveSenior Principal EngineerBAE Systems Applied
> Intelligence Laboratories*
>
> *__________________________________________________________________________*
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> Baddow, Chelmsford, Essex CM2 8HN.
> 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:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* 17 March 2016 17:10
> *To:* Dearlove, Christopher (UK)
> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> *Consider carefully whether you should click on any links, open any
> attachments or reply.For information regarding **Red Flags** that you can
> look out for in emails you receive, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> *If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
>
> On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
> [email-masked]> wrote:
>
> OK, so we have a message that mutates by:
> - Modifying hop count/limit.
> - Modifying a metric value.
> Anything else?
>
> As mutating (other than hop count/limit) messages aren’t covered by 5444
> or any derivative document (but only recommended against, not banned) that
> you may need to make the message otherwise immutable (no deconstruction and
> rebuilding, other than guaranteed unchanging) that would have to be
> specified by AODVv2. (Easy to say, but needs saying.)
>
>
> With you so far.
>
>
> Then that information is not in a guaranteed fixed location given by a
> simple offset. So any signature algorithm that finds it and ignores it or
> aggregates on it is specific to OLSRv2.
>
> Surely you mean AODVv2
>
>
> So standard 7182 ICVs don’t do the job, you would need an AODVv2
> specialised variant. Which is the sort of thing that the message specific
> TLV space is there for, I’d be strongly against a “but ignore the value of
> this specific TLV should it occur” being in the general space. However it
> can easily be defined by reference to 7182 (“this TLV is like that TLV,
> except if an X TLV is present, set its value field to zero”).
>
> Messy, but could work.
>
> Not that messy, actually, although clearly not as nice as “fixed offset”.
>
> That said, I am arguing for the base spec being:
>
>             “make the message otherwise immutable (no deconstruction and
> rebuilding, other
>              than guaranteed unchanging)” which is afforded by forwarding
>
>                                     +
>
>             RFC7182 Timestamps and ICVs.
>
>                                     +
>
>             RFC7183 style text bringing it all together.
>
> The “aggregated signatures around mutable field” would very be an
> experimental extension.
>
> What I object to is, if the base spec specifically renders such extensions
> impossible
>
>
>
>
>
> *--*
>
>
>
>
> *Christopher DearloveSenior Principal EngineerBAE Systems Applied
> Intelligence Laboratories*
>
> *__________________________________________________________________________*
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> Baddow, Chelmsford, Essex CM2 8HN.
> 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:* Lotte Steenbrink [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* 17 March 2016 16:48
> *To:* Dearlove, Christopher (UK)
> *Cc:* [email-masked]; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> *Consider carefully whether you should click on any links, open any
> attachments or reply.For information regarding **Red Flags* *that you can
> look out for in emails you receive, click* *here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> *If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
> Hi all,
>
>
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
> [email-masked]>:
>
> Good point about whether you just pass on one cost or a set of costs. As I
> said, not looked at details - I will, when time permits. One cost is much
> easier, and yes, it reduces the fixed size aggregated signatures problem to
> “just” one of computational load.
>
>
> For the record, Thomas’ understanding is correct; the cost is one
> aggregated value.
>
> Best regards,
> Lotte Steenrbink
>
>
>
>
>
> *--*
>
>
>
>
> *Christopher DearloveSenior Principal EngineerBAE Systems Applied
> Intelligence Laboratories*
>
> *__________________________________________________________________________*
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> Baddow, Chelmsford, Essex CM2 8HN.
> 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:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* 17 March 2016 16:38
> *To:* Dearlove, Christopher (UK)
> *Cc:* Mobile Ad Hoc Networks mailing list
> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> *Consider carefully whether you should click on any links, open any
> attachments or reply.For information regarding **Red Flags* *that you can
> look out for in emails you receive, click* *here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> *If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
>
> On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
> [email-masked]> wrote:
>
> I appreciate Thomas’s comments about the limitations of message
> regeneration, but I would be a bit less absolute.
>
> The issues over end to end authentication and more advanced signatures are
> valid. I need to read the given reference on aggregate signatures to
> increase my knowledge (thanks for it), but my understanding of the
> possibilities in this field may offer a solution to the problem, but with
> some other issues (possibly including a new type of TLV).
>
> But the hop count/limit point I don’t fully agree with, you can regenerate
> with an incremented/decremented count/limit, which leaves the ability to
> prevent messages propagating indefinitely, including expanding ring
> searches, and retains the ability to use RFC 5497 interval and validity
> times that might be useful with an expanding ring search (or might not).
>
> But the key issue is that AODVv2 wants to accumulate metrics. I still
> haven’t got to the bottom of many details here, but let’s for the moment
> just consider that conceptually.
>
> It’s hard to handle end to end. Charlie’s draft attempts to do an end to
> end of some information, not this information. I’m not sure if that’s
> useful (and the specialised format is better avoided if possible). Other
> approaches are hop by hop (might as well use packet signatures) and shared
> key (might as well go hop by hop). Pairwise signatures for each pair of
> routers I’m discounting as scaling terribly. In the interests of
> completeness let’s mention not accumulating metrics, which puts us back to
> hop count and that’s not ideal either.
>
> I don’t think there is an ideal solution. (I like ideas I’ve seen about
> aggregating, but that has some issues of its own, even apart from
> computational load.) I’d love to be proved wrong - someone with the perfect
> solution to come along.
>
> Which means that either we make an arbitrary choice - which will be
> disagreed with, but needs discussing first - or create something flexible.
> Unfortunately flexible in that regard constrains in others, e.g. some
> (many? most?) aggregating signatures need fixed data sizes (which we can do
> by defining a TLV that “fills up” with hop count, but that has a cost too).
>
>
> I have been told by people much more well versed in this than I in
> cryptology, that the correct answer is “some”.
>
> That said, "AODVv2 wants to accumulate metrics” — does that mean that the
> message grows as it is being forwarded, and that the recipient of a
> RREQ/RREP will know the individual costs of each path segment? My
> understanding is, that the recipient will get “the sum the costs of each
> path segment” which should be fitting within a fixed size?
>
> Thomas
>
>
>
>
>
>
> Sorry, no answers, just comments. And I’m not addressing Thomas’s later
> points here.
>
>
> *--*
>
>
>
>
> *Christopher DearloveSenior Principal EngineerBAE Systems Applied
> Intelligence Laboratories*
>
> *__________________________________________________________________________*
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
>
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>
> *From:* manet [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> *Sent:* 17 March 2016 16:00
> *To:* Mobile Ad Hoc Networks mailing list
> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
> ticket Items
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> *Consider carefully whether you should click on any links, open any
> attachments or reply.For information regarding **Red Flags* *that you can
> look out for in emails you receive, click* *here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> *If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
> ***** *WARNING* *****
> EXTERNAL EMAIL -- This message originates from outside our organization.
>
> Dear all,
>
> Apologies for not having gotten this done sooner - day-job leaving few
> spare cycles.
>
> I’ve previously offered reviews and comments, and some of those have been
> addressed in the latest I-D — others have not, but should be. I recall that
> there was some mail attempting to rebut parts of the review, and I will dig
> it out and reply to that.
>
> With that being said, I have reviewed the latest version of the document,
> and full details will be forthcoming. There’re a couple of
> big-ticket/architectural items that I want to address up front, as I
> believe that before we have those hammered out, it will be useless to go
> into details. Note, I do not claim that this is an exhaustive list of “big
> ticket items”, but that’s as far as I have gotten in thinking this through.
>
> I also bring these up as they are items that have been brought up
> repeatedly over the past years, but not resolved nor discussed.
>
> *Loops*
> Just to bring this out: I share Chris’ worry about conflicting and
> concurrent statements from the authors on “There are no loops possible” and
> “We need to fix two situations where loops can occur” and “we are still
> investigating some loop conditions”
>
> I particularly worry that this is not a discussion had in public, but
> apparently in some other forum…
>
>
> *Intermediate Route Replies, and all of section 10*
> Section 10 contains a set of “vaguely specified extensions”, which is
> incoherent with the intended status indicated for this document.
>
> Specifically, and this is not unrelated to the point about loops above,
> intermediate RREPs (section 10.3) are a potential source for loops.
>
> Expanding Ring Multicast (section 10.1) is not documented in a way that
> can be implemented (and also, see “Forwarding-vs-regeneration” below, it is
> in the present form of this protocol impossible), etc.
>
>
> *Forwarding-vs-regeneration*
> Recent exchanges on the list made me understand that protocol control
> messages are *not* forwarded, but are consumed at each hop, then a new
> message with (almost-but-not-quite) the same content is generated and
> transmitted.
>
> I have thought some more on this (& read some of the exchanges on the list
> on this topic by Chris, Ulrich, and others), and I am convinced that this
> is not the right way to go, *at least* for the following reasons:
>
>
>             o          *It renders the hop-limit/hop-count fields in the
> RFC5444 message header useless.*
>                         This would not be bad if the functionality
> offered by those fields was not useful
>                         — sadly, it is. For example, for scope limited
> flooding (expanding ring search, and
>                         such) which may be of interest, and which require
> hop-limit.
>                         A hop-count field may also provide a “cheap” (in
> terms of overhead) additional piece
>                         of information to use conjunctively with a “real”
> metric.
>
>                         The only practical solution would be to
> re-introduce these functions by way of inserting a
>                         MessageTLV — which (i) is not specified in this
> document, and (ii) which would just
>                         serve to render messages bigger than strictly
> needed.
>
>                         Scope limited flooding  does seem to be a
> necessary requirement, if for no
>                         other reason than to prevent information from
> “circulating forever in the network”.
>
>             o          *It makes end-to-end authentication unnecessarily
> hard.*
>                         I think Chris called this out already, but it
> bears repeating: S generates a message
>                         (say, a RREQ), and includes an ICV calculated
> over the content of the message.
>                         For any recipient to be able to validate the ICV,
> the message has to be exactly
>                         the same — not just in content, but in structure
> — as what was generated.
>
>                         “Regenerating” rather than “forwarding” messages
> means, that the intermediate
>                         router “regenerating” the RREQ may chose a
> different structure (e.g., include TLVs
>                         in a different order).
>
>                         The proposal from
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>                         is to add constraints on (i) the set of elements
> to include in a signature and (ii) the
>                         order of these elements.
>
>                         One problem with that approach is (i): if an
> extension adds a message TLV, or an
>                         Address TLV, to a message, then that will not be
> “covered” by the proposed e2esec TLV.
>                         Rather for *each* extension developed, an
> “updates e2esec” clause needs to be done.
>
>                         I’d say that this approach would be prone to
> errors — and add entropy to the process
>                         of designing protocol extensions. The
> alternative, a message being generated by the
>                         source and *forwarded* (as we do in OLSRv2, for
> example) would allow ICV TLVs
>                         (even, allow reuse of those specified for OLSRv2)
> for covering a message and
>                         extensions.
>
>                         “But what about the metrics value which will
> change on each hop”, you may say?
>                         Fortunately, that is relatively easy to handle:
> simply zero out the value of that TLV when
>                         generating or verifying the ICV MessageTLV. And
> use Packet-TLVs for hop-by-hop
>                         authentication, if needed (but, see below).
>
>             o          *It prevents the use of more clever/advanced
> signature schemes/ICVs*
>                         Aggregate signature algorithms (
> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>                         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.
>
> *Security Considerations*
> This is an always thorny subject. When OLSRv2 was going through the
> process we got a thorough education in how little we knew about security
> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
> The bottom line is, that this protocol needs its “RFC7183  equivalent”,
> either as part of the main document, or as an independent document.
> currently, that is not the case.
>
> A minima, looking at BCP72 and BCP107 — taking inspiration from RFC7183
> might be aw good idea, as that was the most recent that went through the
> SEC AD. Regardless of how, however, a “mandatory to implement” security
> mechanism most be specified (I think the right term was “MUST implement,
> SHOULD use”), in sufficient detail to ensure interoperable implementations.
>
> As an example, both [RFC6130] and [RFC7181] set out that that:
>
>       On receiving a ... message, a router MUST first check if the
>       message is invalid for processing by this router
>
> and then proceed to give a number of conditions that, each, will lead to a
> rejection of the message as "badly formed and therefore invalid for
> processing” — a list which RFC7183 then amended. That gave a “hook” for
> RFC7183 for inserting “rejection”. Idem for message generation.
>
> If I was to do RFC7181/RFC6130 today, I would include that directly into
> the protocol specifications. It turned out to be more overhead (and slow
> down publication anyways) to do it as separate documents.
>
> Secondly, we need to be a lot more rigid in terms of what ICVs,
> Timestamps, etc. are added/removed, and what that brings.
>
> For example (with the assumption that messages are *forwarded* and *not*
> regenerated), this could be one option:
>
>                         o          When a RREQ, RREP message is
> generated, add an ICV Message TLV, which is calculated <this way>
>                                      …(take inspiration from RFC7183 here)
>
>
> ...
>
> [Message clipped]
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Victoria Mercieca <[email-masked]>
Date: Sat, 23 Apr 2016 10:55:04 +0100

Hi Chris,

These have both been in the draft in some form since before I got
involved... but I'll do my best to explain.

- For Validity Time, its a way to advertise that you would only support the
route contained in the message for a certain period of time. The originator
might use this, but the draft was written to allow any intermediate node to
be able to add it or update it too. The route created in the Local Route
Set has an expiration time associated with it, based on the received
validity time.
- For the AckReq address, its so that you can add into a RREP a request for
an acknowledgement, so that you don't have to have a different message type
altogether for working out whether links to neighbors are bidirectional,
and also, since you only care about bidirectionality on routes that are
being set up, you dont need to constantly monitor all neighbors.

In order to avoid the potential AckReq-related changes to each message,
maybe we do need to introduce a different message specifically for this. We
could maybe use RREP_Ack to both request and acknowledge? It means an extra
message of control traffic that needs to be sent, maybe one extra message
per hop on the path of a RREP, but it could still be limited to neighbors
which have participated in the route discovery rather than monitoring all
neighbors at all times.

This message could maybe also include "I'm happy to route anywhere for a
certain amount of time", sort of like willingness in OLSR/OLSRv2. So
instead of having a validity time per route, its a validity time per
neighbor. Then, for RREQ and RREP, only the metric value would change in
transit, as discussed. However, that leads to some issues with deciding
what a route's expiration time is. You might know how long the next hop
router is valid for, but what if a router beyond that, which was also part
of the route, had a lower validity time? You couldn't determine the real
validity time. Do we remove the route expiration time altogether to avoid
this issue? In which case, we would have to rely on RERR messages being
sent for routes which become invalid when the neighbor's validity time has
expired? So neighbor validity time expiration is treated the same as a link
break.

What do you think?

Kind regards,
Victoria.

On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
[email-masked]> wrote:

> Pretty much all of the discussion has been assuming only a metric value
> change. With multiple things changing many of the ideas go out of the
> window. That reinforces the point about not making specifications now that
> might turn out to be wrong for ICVs.
>
> Ignoring how this misunderstanding happened, I'll start by asking why.
> Metric changing I understand. Why the other two? (there's a partial
> explanation of one). What alternatives have people implemented in
> comparable protocols?
>
> --
> Christopher Dearlove
> [email-masked] (iPhone)
> [email-masked] (home)
>
> On 23 Apr 2016, at 00:26, Victoria Mercieca <[email-masked]> wrote:
>
> Hi all,
>
> Also, to be thorough, do we need to consider RERR messages while we
> discuss regeneration vs forwarding?
>> attachments or reply.For information regarding **Red Flags** that you
>> can look out for in emails you receive, click here
>> What I object to is, if the base spec specifically renders such
>> extensions impossible
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> attachments or reply.For information regarding **Red Flags* *that you
>> can look out for in emails you receive, click* *here
>> Good point about whether you just pass on one cost or a set of costs. As
>> I said, not looked at details - I will, when time permits. One cost is much
>> attachments or reply.For information regarding **Red Flags* *that you
>> can look out for in emails you receive, click* *here
>> The issues over end to end authentication and more advanced signatures
>> are valid. I need to read the given reference on aggregate signatures to
>> But the hop count/limit point I don’t fully agree with, you can
>> regenerate with an incremented/decremented count/limit, which leaves the
>> ability to prevent messages propagating indefinitely, including expanding
>> ring searches, and retains the ability to use RFC 5497 interval and
>> validity times that might be useful with an expanding ring search (or might
>> not).
>>
>> attachments or reply.For information regarding **Red Flags* *that you
>> can look out for in emails you receive, click* *here
>> 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:
>>
>>
>>                         such) which may be of interest, and which
>> require hop-limit.
>>                         of information to use conjunctively with a
>> “real” metric.
>>
>>                         For any recipient to be able to validate the
>> ICV, the message has to be exactly
>>                         (even, allow reuse of those specified for
>> OLSRv2) for covering a message and
>>                         extensions.
>>
>>                         Regeneration of messages, rather than
>> forwarding, renders that impossible (or, if used,
>>                         updating to
>> 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
>> 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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 25 Apr 2016 09:20:30 +0000

With regard to your validity time point, we here have a tradeoff. If you allow that feature, it significantly impacts on the approach that was coming together on as best you can end to end encryption.

So the question is, is this a feature that’s really wanted? Unfortunately I think we know that the answer to that is, we don’t know because we don’t have any experience. My view would be that in the tradeoff of an untested feature (unless I’m wrong about that) and the security complication, security wins and drop the feature. If there is some real requirement, then there’s a discussion. (Questions like how often the intermediate routers actually have any knowledge - typically links break for unexpected rather than expected reasons. Andan intermediate router could possibly use a validity time to influence its behaviour.) Note that dropping the ability of intermediate routers to modify/set still allows validity times per route to be set at endpoints.

With regard to the acknowledgements, the problem (with regard to security) comes from trying to do two jobs with the same message - end to end route advertisement and hop by hop acknowledgement. I understand the reasons - saving bytes and message types. (I would have to study the protocol really hard to identify if any message types can be folded together and recognised by content rather than type efficiently. This I do not expect to do.) Again a tradeoff. This one is in discussion space, though that needs people who understand both sides of the issue, including the details of the bidirectionality mechanism. Of course, as has been said, we need one of those.

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

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

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

From: Victoria Mercieca [mailto:[email-masked]]
Sent: 23 April 2016 10:55
To: Christopher Dearlove
Cc: [email-masked]; Dearlove, Christopher (UK); Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Hi Chris,

These have both been in the draft in some form since before I got involved... but I'll do my best to explain.

- For Validity Time, its a way to advertise that you would only support the route contained in the message for a certain period of time. The originator might use this, but the draft was written to allow any intermediate node to be able to add it or update it too. The route created in the Local Route Set has an expiration time associated with it, based on the received validity time.
- For the AckReq address, its so that you can add into a RREP a request for an acknowledgement, so that you don't have to have a different message type altogether for working out whether links to neighbors are bidirectional, and also, since you only care about bidirectionality on routes that are being set up, you dont need to constantly monitor all neighbors.

In order to avoid the potential AckReq-related changes to each message, maybe we do need to introduce a different message specifically for this. We could maybe use RREP_Ack to both request and acknowledge? It means an extra message of control traffic that needs to be sent, maybe one extra message per hop on the path of a RREP, but it could still be limited to neighbors which have participated in the route discovery rather than monitoring all neighbors at all times.

This message could maybe also include "I'm happy to route anywhere for a certain amount of time", sort of like willingness in OLSR/OLSRv2. So instead of having a validity time per route, its a validity time per neighbor. Then, for RREQ and RREP, only the metric value would change in transit, as discussed. However, that leads to some issues with deciding what a route's expiration time is. You might know how long the next hop router is valid for, but what if a router beyond that, which was also part of the route, had a lower validity time? You couldn't determine the real validity time. Do we remove the route expiration time altogether to avoid this issue? In which case, we would have to rely on RERR messages being sent for routes which become invalid when the neighbor's validity time has expired? So neighbor validity time expiration is treated the same as a link break.

What do you think?

Kind regards,
Victoria.

On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
Pretty much all of the discussion has been assuming only a metric value change. With multiple things changing many of the ideas go out of the window. That reinforces the point about not making specifications now that might turn out to be wrong for ICVs.

Ignoring how this misunderstanding happened, I'll start by asking why. Metric changing I understand. Why the other two? (there's a partial explanation of one). What alternatives have people implemented in comparable protocols?

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

On 23 Apr 2016, at 00:26, Victoria Mercieca <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Continued in this thread because the other one seems to be more about TLV types and metric type numbers, whereas this is about regeneration/forwarding.

To recap, in the current draft, there are 3 things that might change at each hop:
- the metric value (happens in RREQ and RREP),
- adding/changing Validity Time using the Validity Time TLV (can happen in RREQ and RREP),
- adding an address (and corresponding value in the AddressType TLV to indicate how to interpret the address) to indicate the address from which an RREP_Ack is expected, to accomplish the bidirectionality check (can happen in RREP).

If we define a certain portion of the message as immutable and include the ICV to verify that part, end to end:
- The metric value would be excluded from the ICV since it needs changing at each hop.
- Would adding a Validity Time TLV at an intermediate hop be acceptable? The whole TLV could be removed in order to calculate the ICV?
- Would adding an address cause issues for the ICV, because it's in the address block? Could the rule be "if it contains an AckReq address, remove it (and the corresponding value in the AddressType TLV), before checking the ICV", is that OK? Or would we need to avoid touching the ICV'ed part of the message altogether, maybe put the AckReq address in a separate Address Block, with an extra AddressType TLV following that address block? Is there a way to accomplish this?

Also, to be thorough, do we need to consider RERR messages while we discuss regeneration vs forwarding?
- RERR (sent when a link breaks) is a way of saying "I've lost my route so I'm telling others" and "you were my next hop, so now I've also lost my route, I'll tell others", etc. It's going to be tailored at each step to include the relevant routes that got deleted, it's not one message being sent end-to-end like RREQ and RREP are.
- However, RERR (sent when a source of traffic is sending data on a route which comes through you, and you want to tell the Packet Source's router to delete the route) could be seen as an end-to-end message which all intermediate routers learn from, similar to RREQ and RREP. It reports one route, and doesn't need changing at intermediate hops, so could be protected with ICV.
- Would it be OK to only require a message ICV if a PktSource address was included, i.e. when the message needs to go via a number of intermediate hops to PktSource's router? All other RERRs are intended to be one-hop messages, which may in turn prompt other one-hop messages, etc..., and a packet ICV might be more appropriate?

Kind regards,
Victoria.

On Thu, Mar 17, 2016 at 5:26 PM, <[email-masked]<mailto:[email-masked]>> wrote:

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

No, the would be silly as base specification, given that hop count mostly is useless.

As base specification I would simply say “Include a Metric Type Message TLV with a value field, and a 7182 Message TLV & Timestamp” as we do in OLSRv2 (with the appropriate verbiage as to generation and processing).

With the message generated by the originator of the RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk with “regeneration) allows knowing that it would be *only* that metric field being modified (other than hop count/limit) for when eventually writing up the extension.

(Actually doesn’t the current specification only define hop count, or has that changed in latest draft?)

No. That is one of the issues I raise in my original. For some reason, it cites RFC6551, which is a ROLL document and which has in its abstract that:

I.e. this document cites a metric document which clearly claims to be inapplicable in ad hoc networks. I note that this is another thing I’ve raised for years without seeing it attempted resolved.

Best,

Thomas

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

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

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: 17 March 2016 17:10
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.

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

As mutating (other than hop count/limit) messages aren’t covered by 5444 or any derivative document (but only recommended against, not banned) that you may need to make the message otherwise immutable (no deconstruction and rebuilding, other than guaranteed unchanging) that would have to be specified by AODVv2. (Easy to say, but needs saying.)

With you so far.

Then that information is not in a guaranteed fixed location given by a simple offset. So any signature algorithm that finds it and ignores it or aggregates on it is specific to OLSRv2.

Surely you mean AODVv2

So standard 7182 ICVs don’t do the job, you would need an AODVv2 specialised variant. Which is the sort of thing that the message specific TLV space is there for, I’d be strongly against a “but ignore the value of this specific TLV should it occur” being in the general space. However it can easily be defined by reference to 7182 (“this TLV is like that TLV, except if an X TLV is present, set its value field to zero”).

Messy, but could work.

            “make the message otherwise immutable (no deconstruction and rebuilding, other
             than guaranteed unchanging)” which is afforded by forwarding

                                    +

                                    +

The “aggregated signatures around mutable field” would very be an experimental extension.

What I object to is, if the base spec specifically renders such extensions impossible

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

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

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

From: Lotte Steenbrink [mailto:[email-masked]]
Sent: 17 March 2016 16:48
To: Dearlove, Christopher (UK)
Cc: [email-masked]<mailto:[email-masked]>; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Hi all,

Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>>:

Good point about whether you just pass on one cost or a set of costs. As I said, not looked at details - I will, when time permits. One cost is much easier, and yes, it reduces the fixed size aggregated signatures problem to “just” one of computational load.

For the record, Thomas’ understanding is correct; the cost is one aggregated value.

Best regards,
Lotte Steenrbink

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

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

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: 17 March 2016 16:38
To: Dearlove, Christopher (UK)
Cc: Mobile Ad Hoc Networks mailing list
Subject: Re: Message integrity and message mutability (was RE: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.

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

I appreciate Thomas’s comments about the limitations of message regeneration, but I would be a bit less absolute.

The issues over end to end authentication and more advanced signatures are valid. I need to read the given reference on aggregate signatures to increase my knowledge (thanks for it), but my understanding of the possibilities in this field may offer a solution to the problem, but with some other issues (possibly including a new type of TLV).

But the hop count/limit point I don’t fully agree with, you can regenerate with an incremented/decremented count/limit, which leaves the ability to prevent messages propagating indefinitely, including expanding ring searches, and retains the ability to use RFC 5497 interval and validity times that might be useful with an expanding ring search (or might not).

But the key issue is that AODVv2 wants to accumulate metrics. I still haven’t got to the bottom of many details here, but let’s for the moment just consider that conceptually.

It’s hard to handle end to end. Charlie’s draft attempts to do an end to end of some information, not this information. I’m not sure if that’s useful (and the specialised format is better avoided if possible). Other approaches are hop by hop (might as well use packet signatures) and shared key (might as well go hop by hop). Pairwise signatures for each pair of routers I’m discounting as scaling terribly. In the interests of completeness let’s mention not accumulating metrics, which puts us back to hop count and that’s not ideal either.

I don’t think there is an ideal solution. (I like ideas I’ve seen about aggregating, but that has some issues of its own, even apart from computational load.) I’d love to be proved wrong - someone with the perfect solution to come along.

Which means that either we make an arbitrary choice - which will be disagreed with, but needs discussing first - or create something flexible. Unfortunately flexible in that regard constrains in others, e.g. some (many? most?) aggregating signatures need fixed data sizes (which we can do by defining a TLV that “fills up” with hop count, but that has a cost too).

I have been told by people much more well versed in this than I in cryptology, that the correct answer is “some”.

That said, "AODVv2 wants to accumulate metrics” — does that mean that the message grows as it is being forwarded, and that the recipient of a RREQ/RREP will know the individual costs of each path segment? My understanding is, that the recipient will get “the sum the costs of each path segment” which should be fitting within a fixed size?

Thomas

Sorry, no answers, just comments. And I’m not addressing Thomas’s later points here.

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

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

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

From: manet [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 17 March 2016 16:00
To: Mobile Ad Hoc Networks mailing list
Subject: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Dear all,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            o          It prevents the use of more clever/advanced signature schemes/ICVs
                        Aggregate signature algorithms ( https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
                        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.

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

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

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

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

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

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)

...

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

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Jiazi YI <[email-masked]>
Date: Mon, 25 Apr 2016 14:04:17 +0200

Hi,

On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> With regard to your validity time point, we here have a tradeoff. If you
> allow that feature, it significantly impacts on the approach that was
> coming together on as best you can end to end encryption.
>
>
>
> So the question is, is this a feature that’s really wanted? Unfortunately
> I think we know that the answer to that is, we don’t know because we don’t
> have any experience. My view would be that in the tradeoff of an untested
> feature (unless I’m wrong about that) and the security complication,
> security wins and drop the feature. If there is some real requirement, then
> there’s a discussion. (Questions like how often the intermediate routers
> actually have any knowledge - typically links break for unexpected rather
> than expected reasons. Andan intermediate router could possibly use a
> validity time to influence its behaviour.) Note that dropping the ability
> of intermediate routers to modify/set still allows validity times per route
> to be set at endpoints.
>

I agree with Chris' concern.
The ValidityTime is optional, which makes the integrity protection hard.
Furthermore, it gives a potential attack vector: as all the routers in a
path will take the shortest validityTime, a compromised router can set the
the validityTime to a very short value, which will make the route installed
along the path became invalid (very soon).

On the other hand, I'm not sure this option will give us much help. Chris
mentioned much knowledge intermediate router would have to decide this
value (and how much sense the value would make).
Another issue is, a route to a destination might be updated by different
sources. For example, in the network below:

A----B-----C

A first establish a route to B with long validity time. Then A initiates a
route discovery to C. C tends to set a short validity time, which will make
the route between B and A expire earlier than expected.
Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered or
not.

>
>
> With regard to the acknowledgements, the problem (with regard to security)
> comes from trying to do two jobs with the same message - end to end route
> advertisement and hop by hop acknowledgement. I understand the reasons -
> saving bytes and message types. (I would have to study the protocol really
> hard to identify if any message types can be folded together and recognised
> by content rather than type efficiently. This I do not expect to do.) Again
> a tradeoff. This one is in discussion space, though that needs people who
> understand both sides of the issue, including the details of the
> bidirectionality mechanism. Of course, as has been said, we need one of
> those.
>

I haven't finished my review of the latest draft, and I don't get the
necessity of AckReq and the corresponding multicast RREP yet.
If possible, this "optional" field should be avoided.

regards

Jiazi

>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *From:* Victoria Mercieca [mailto:[email-masked]]
> *Sent:* 23 April 2016 10:55
> *To:* Christopher Dearlove
> *Cc:* [email-masked]; Dearlove, Christopher (UK); Mobile Ad Hoc
> Networks mailing list
>
> * Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding **Red Flags** that you
> * If you feel the email is suspicious, please follow this process
> - For Validity Time, its a way to advertise that you would only support
> the route contained in the message for a certain period of time. The
> originator might use this, but the draft was written to allow any
> intermediate node to be able to add it or update it too. The route created
> in the Local Route Set has an expiration time associated with it, based on
> the received validity time.
>
> - For the AckReq address, its so that you can add into a RREP a request
> for an acknowledgement, so that you don't have to have a different message
> type altogether for working out whether links to neighbors are
> bidirectional, and also, since you only care about bidirectionality on
> routes that are being set up, you dont need to constantly monitor all
> neighbors.
>
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> * Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding **Red Flags** that you
> * If you feel the email is suspicious, please follow this process
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> * 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
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> * 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
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> * 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
>                         exist, and an interesting use-case can be found in
> also reactive protocols, allowing verifying
>
>                         o          When a RREQ, RREP message is generated,
> add an ICV Message TLV, which is calculated <this way>
>

---

From: Victoria Mercieca <[email-masked]>
Date: Mon, 25 Apr 2016 14:14:52 +0100

Hi Jiazi,

> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered or

Not sure I follow here.

Currently, the validity time of the route between A and B would not
affected by a short validity time of a route between A and C. Validity
times are per-route, and the route A-B and the route A-C are separate.

If we switched to a validity time per neighbor (so that we can keep
validity time separate from route advertisements) as I mentioned in the
email below, then the validity of a route between A and C would be affected
if there was a short validity time between A and B. But, if B will only
route for a certain amount of time, then the route between A and C will of
course be affected. Is it best to know in advance that there's a time
limit, or just deal with RERRs when they happen?

>
>>
>> With regard to the acknowledgements, the problem (with regard to
>> security) comes from trying to do two jobs with the same message - end to
>> end route advertisement and hop by hop acknowledgement. I understand the
>> reasons - saving bytes and message types. (I would have to study the
>> protocol really hard to identify if any message types can be folded
>> together and recognised by content rather than type efficiently. This I do
>> not expect to do.) Again a tradeoff. This one is in discussion space,
>> though that needs people who understand both sides of the issue, including
>> the details of the bidirectionality mechanism. Of course, as has been said,
>> we need one of those.
>>
>
To give an overview of AckReq and RREP:

Since AODVv2 requires bidirectional links, this is the way to determine if
a link is bidirectional.

A----B----C

1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a
route to OrigAddr but they dont yet know if it's valid because they dont
know if the link to their next hop is available in the reverse direction.
2) C creates the RREP. Since it doesnt know if the link to B is
bidirectional, it includes the AckReq (an address to indicate that it
expects to receive a RREP_Ack from B).
3) B receives the RREP, installs a route to TargAddr and marks it as valid,
since it knows the link to C is bidirectional, because the RREQ went in one
direction and the RREP came in the other. B also sends the RREP_Ack to C
and forwards the RREP to A (and might change the message to indicate its
own AckReq - ie that it requires an ack from A).
4) C receives the RREP_Ack from B, and therefore knows that B received the
RREP, therefore the link is bidirectional. C can then mark its route to
OrigAddr as valid.
5) Similarly, A receives the RREP, installs the route to TargAddr and sends
an RREP_Ack to B.
6) B receives the RREP_Ack and marks its route to OrigAddr as valid.

Alternatively, in step 2, if C knows the link to B is bidirectional
(perhaps from some earlier route discovery), it doesnt need to put the
AckReq in the RREP. Then in step 3, since B doesnt know if the link to A is
bidirectional, it changes the message to add the AckReq address, in order
to get an RREP_Ack from A.

If we want to avoid changing the message, we'll need to look at forwarding
the RREP as-is, and creating a second message to solicit an RREP_Ack, in
order to verify that the link is bidirectional before marking the route to
OrigAddr as valid.

Kind regards,
Victoria.

>> - RERR (sent when a link breaks) is a way of saying "I've lost my route
>> so I'm telling others" and "you were my next hop, so now I've also lost my

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 25 Apr 2016 13:27:20 +0000

Assuming for the moment that everyone will need an RREP-Ack or won’t (let’s come back to that) why do C and B need to put an address in as an RREQ-Ack request? Why not a flag, because the address will be included as the IP sending address - and we know 5444 is required to pass that on. (It’s used by NHDP as well.) Then we don’t need to change the RREP, it will have a flag set or not, and won’t change (in this regard).

Now let’s consider do we know whether we can set a fixed flag. First I’d say there are two cases - you’ve got a firm control on what’s going on in your network, or it’s one of unknown parties and behaviour (consistent with specification). In the former case you only want one setting, for example no-Ack if running NHDP or your MAC layer tells you about bidirectionality, Ack otherwise. In the latter case, I think you just always want an Ack. So both cases get you to the same place.

Should that not be an acceptable argument (though I think it’s good for where we are - in fact always Ack is close) then at flag is a step better, it’s a fixed location to change. However it would be better in that case if the two things to change (metric and ack flag) were together. But that has its own issues, so I won’t go there.

From: Victoria Mercieca [mailto:[email-masked]]
Sent: 25 April 2016 14:15
To: Jiazi YI
Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***

On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
With regard to your validity time point, we here have a tradeoff. If you allow that feature, it significantly impacts on the approach that was coming together on as best you can end to end encryption.

I agree with Chris' concern.
The ValidityTime is optional, which makes the integrity protection hard. Furthermore, it gives a potential attack vector: as all the routers in a path will take the shortest validityTime, a compromised router can set the the validityTime to a very short value, which will make the route installed along the path became invalid (very soon).

On the other hand, I'm not sure this option will give us much help. Chris mentioned much knowledge intermediate router would have to decide this value (and how much sense the value would make).
Another issue is, a route to a destination might be updated by different sources. For example, in the network below:

A----B-----C

A first establish a route to B with long validity time. Then A initiates a route discovery to C. C tends to set a short validity time, which will make the route between B and A expire earlier than expected.
Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered or not.

Not sure I follow here.
Currently, the validity time of the route between A and B would not affected by a short validity time of a route between A and C. Validity times are per-route, and the route A-B and the route A-C are separate.
If we switched to a validity time per neighbor (so that we can keep validity time separate from route advertisements) as I mentioned in the email below, then the validity of a route between A and C would be affected if there was a short validity time between A and B. But, if B will only route for a certain amount of time, then the route between A and C will of course be affected. Is it best to know in advance that there's a time limit, or just deal with RERRs when they happen?

I haven't finished my review of the latest draft, and I don't get the necessity of AckReq and the corresponding multicast RREP yet.
If possible, this "optional" field should be avoided.

To give an overview of AckReq and RREP:
Since AODVv2 requires bidirectional links, this is the way to determine if a link is bidirectional.
A----B----C

1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a route to OrigAddr but they dont yet know if it's valid because they dont know if the link to their next hop is available in the reverse direction.
2) C creates the RREP. Since it doesnt know if the link to B is bidirectional, it includes the AckReq (an address to indicate that it expects to receive a RREP_Ack from B).
3) B receives the RREP, installs a route to TargAddr and marks it as valid, since it knows the link to C is bidirectional, because the RREQ went in one direction and the RREP came in the other. B also sends the RREP_Ack to C and forwards the RREP to A (and might change the message to indicate its own AckReq - ie that it requires an ack from A).
4) C receives the RREP_Ack from B, and therefore knows that B received the RREP, therefore the link is bidirectional. C can then mark its route to OrigAddr as valid.
5) Similarly, A receives the RREP, installs the route to TargAddr and sends an RREP_Ack to B.
6) B receives the RREP_Ack and marks its route to OrigAddr as valid.

Alternatively, in step 2, if C knows the link to B is bidirectional (perhaps from some earlier route discovery), it doesnt need to put the AckReq in the RREP. Then in step 3, since B doesnt know if the link to A is bidirectional, it changes the message to add the AckReq address, in order to get an RREP_Ack from A.
If we want to avoid changing the message, we'll need to look at forwarding the RREP as-is, and creating a second message to solicit an RREP_Ack, in order to verify that the link is bidirectional before marking the route to OrigAddr as valid.
Kind regards,
Victoria.

regards

Jiazi

From: Victoria Mercieca [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 23 April 2016 10:55
To: Christopher Dearlove
Cc: [email-masked]<mailto:[email-masked]>; Dearlove, Christopher (UK); Mobile Ad Hoc Networks mailing list

*** WARNING ***

What do you think?

Kind regards,
Victoria.

Kind regards,
Victoria.

Best,

Thomas

*** WARNING ***

With you so far.

Surely you mean AODVv2

Messy, but could work.

                                    +

                                    +

*** WARNING ***

Best regards,
Lotte Steenrbink

*** WARNING ***

Thomas

*** WARNING ***

Dear all,

Loops

Security Considerations

...

[Message clipped]

---

From: [email-masked]
Date: Mon, 25 Apr 2016 16:18:37 +0200

Hi,

I must admit that while I have reviewed the protocol several times, I’ve not been digging that deep into the protocol functioning to catch this issue of how invasive the protocol operations are when forwarding a message: there were other “major” issues to address (and which obscured the details), so as a first order: thank you Victoria, for having called attention to this.

To the substance of these emails.

I am afraid that I do not understand the use of inserting validity TLVs while in-flight, into a message. Actually, I am dubious for both the originator inserting this (how can the originator of a message know how “latter parts of the path” will be have”) except if we are talking duty-cycling of devices and inserting “the remaining time that I am going to be up before I suspend”. Intuitively, that would also assume fairly long duty cycles “I am up for tens of seconds”, which I am not sure are actually realistic. And, as Chris says in another email, this is trading off “the ability to do security” for an unknown/untested feature — which I think is the wrong trade-off.

On he topic of “needing to put an address in” for RREP-ACK, I must admit that this seems roundabout. I can see three issues here:

	o	I am not sure that adding an address vs. a flag may not have to do with the “multiple interfaces/
		multiple addresses” discrimination mechanics of the protocol? I haven’t worked it through, though, 
		but that would be a guess.

	o	The end-to-end topology diffusion mechanism should not need to be concerned with the 
		“bidirectionally check” of a local link (in part, as it encumbers security, but not only).  In short, a
		flag or an address, both are (equally) bad.

	o	A cleaner mechanism would be a “hello mechanism”, not necessarily as NHDP, but a “when 
		forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is estimated to be of a 
		type which potentially can be unidirectional”. There is another benefit to doing that, see the end 
		of this email.

Either way, I do not like the notion of fusing metrics-and-link-bidirectionality-detection any more than I like fusing global-topology-diffusion-and-link-bidirectionality-detection. 

The solution all this is, to me, threefold

	1)	Factor out the bidirectionally check in a (triggered) neighbour detection mechanism 
		(triggered HELLO message)

	2)	Remove the “validity time TLVs”, since they add complexity for no perceivable benefits

	3)	Use the security model that we’ve discussed previously, where (only) the metrics change per hop.

Since we’re discussing bi-directionality of links here, and the necessity of a mechanism for handling these, I want to call attention to a related issue, as I hinted previously.

The abstract states that the protocol:

   ...is intended for use by mobile routers in wireless, multihop
   networks.

Section 5 paragraph 4  of the document, however, reads:

   Assuming link metrics are symmetric, the cost of the routes installed
   in the Local Route Set at each router will be correct.  While this
   assumption is not always correct, calculating incoming/outgoing
   metric data is outside of scope of this document. 

I do not know of any wireless systems, where the assumption that “link metrics are symmetric” actually holds. Consequently, the conclusion in the quoted paragraph:

   calculating incoming/outgoing
   metric data is outside of scope of this document.

Is not an acceptable design choice.

While this protocol may not want to “calculate if for this link the metrics is 4 or 5”, the protocol must be able to convey and distinguish that “the metric from A to B is 4, and the metric from B to A is 19”.

This is a “related issue” since the solution may (as with the bi-directionality check) be in the triggered neighbour detection mechanism: that exchange could, if designed carefully, be used to probe for and convey metrics information, also.

Hope this helps,

Thomas

> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
> T:  +44 (0)1245 242194  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: Victoria Mercieca [mailto:[email-masked] <mailto:[email-masked]>] 
> For information regarding Red Flags that you can look out for in emails you receive, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
> If you feel the email is suspicious, please follow this process <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
> 
> Hi Jiazi,
> 
> 
> 
>  
> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, 
>  
> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: Victoria Mercieca [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: [email-masked] <mailto:[email-masked]>; Dearlove, Christopher (UK); Mobile Ad Hoc Networks mailing list
> 
> For information regarding Red Flags that you can look out for in emails you receive, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
> If you feel the email is suspicious, please follow this process <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
> 
> Hi Chris,
>  
> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]> (iPhone)
> [email-masked] <mailto:[email-masked]> (home)
> 
> On 23 Apr 2016, at 00:26, Victoria Mercieca <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi all,
>  
> On Thu, Mar 17, 2016 at 5:26 PM, <[email-masked] <mailto:[email-masked]>> wrote:
>  
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> For information regarding Red Flags that you can look out for in emails you receive, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
> If you feel the email is suspicious, please follow this process <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
> 
>  
> On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: Lotte Steenbrink [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: [email-masked] <mailto:[email-masked]>; Mobile Ad Hoc Networks mailing list
> For information regarding Red Flags that you can look out for in emails you receive, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
> If you feel the email is suspicious, please follow this process <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
> 
> Hi all,
>  
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>>:
>  
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> For information regarding Red Flags that you can look out for in emails you receive, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
> If you feel the email is suspicious, please follow this process <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
> 
>  
> On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
> For information regarding Red Flags that you can look out for in emails you receive, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
> If you feel the email is suspicious, please follow this process <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
> 
> *** WARNING ***
>                         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>
>                         Aggregate signature algorithms ( https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf <https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf>)
>                         updating to  https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 <https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00>)
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>  
>

---

From: Justin Dean <[email-masked]>
Date: Mon, 25 Apr 2016 10:20:19 -0400

A thought regarding integrity checking.  A possible future "fix" for
integrity could be done on a "virtual" packet in which known TLVs/values
along with ordered addresses are uncompressed and then verified.  It could
allow extra TLV tagging without modifying the validity of that data.  The
very big drawback would be the overhead of having to uncompressed
everything to check the validity.  It's functionally the same as zeroing
out local (this is my stuff) TLV data vs remote (this is not my stuff) TLV
data.

As for the RREP-Ack having a flag vs an address doesn't much bother me as
either would have to be zeroed out for this type of future integrity
checking.

Justin

On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Assuming for the moment that everyone will need an RREP-Ack or won’t
> (let’s come back to that) why do C and B need to put an address in as an
> RREQ-Ack request? Why not a flag, because the address will be included as
> the IP sending address - and we know 5444 is required to pass that on.
> (It’s used by NHDP as well.) Then we don’t need to change the RREP, it will
> have a flag set or not, and won’t change (in this regard).
>
>
>
> Now let’s consider do we know whether we can set a fixed flag. First I’d
> say there are two cases - you’ve got a firm control on what’s going on in
> your network, or it’s one of unknown parties and behaviour (consistent with
> specification). In the former case you only want one setting, for example
> no-Ack if running NHDP or your MAC layer tells you about bidirectionality,
> Ack otherwise. In the latter case, I think you just always want an Ack. So
> both cases get you to the same place.
>
>
>
> Should that not be an acceptable argument (though I think it’s good for
> where we are - in fact always Ack is close) then at flag is a step better,
> it’s a fixed location to change. However it would be better in that case if
> the two things to change (metric and ack flag) were together. But that has
> its own issues, so I won’t go there.
>
>
>
> *-- *
>
>
>
>
> *Sent:* 25 April 2016 14:15
> *To:* Jiazi YI
> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
> Networks mailing list
> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install
> a route to OrigAddr but they dont yet know if it's valid because they dont
> 3) B receives the RREP, installs a route to TargAddr and marks it as
> valid, since it knows the link to C is bidirectional, because the RREQ went
> in one direction and the RREP came in the other. B also sends the RREP_Ack
> to C and forwards the RREP to A (and might change the message to indicate
> its own AckReq - ie that it requires an ack from A).
>
> external partner or the internet. Consider carefully whether you should
> click on any links, open any attachments or reply. For information
> regarding **Red Flags*
> external partner or the internet. Consider carefully whether you should
> click on any links, open any attachments or reply. For information
> regarding **Red Flags*
> external partner or the internet. Consider carefully whether you should
> click on any links, open any attachments or reply. For information
> regarding **Red Flags*
> external partner or the internet. Consider carefully whether you should
> click on any links, open any attachments or reply. For information
> regarding **Red Flags*
> external partner or the internet. Consider carefully whether you should
> click on any links, open any attachments or reply. For information
> regarding **Red Flags*
> **** **WARNING ******

---

From: Justin Dean <[email-masked]>
Date: Mon, 25 Apr 2016 10:26:29 -0400

The address in the RREP_Ack may be required due to the RREP_Ack being
multicast as there is not yet a verified unicast route installed yet.
Going to double check if I'm remembering correctly.

Justin

On Mon, Apr 25, 2016 at 10:18 AM, <[email-masked]> wrote:

> Hi,
>
> I must admit that while I have reviewed the protocol several times, I’ve
> not been digging that deep into the protocol functioning to catch this
> issue of how invasive the protocol operations are when forwarding a
> message: there were other “major” issues to address (and which obscured the
> details), so as a first order: thank you Victoria, for having called
> attention to this.
>
> I am afraid that I do not understand the use of inserting validity TLVs
> while in-flight, into a message. Actually, I am dubious for both the
> originator inserting this (how can the originator of a message know how
> “latter parts of the path” will be have”) except if we are talking
> duty-cycling of devices and inserting “the remaining time that I am going
> to be up before I suspend”. Intuitively, that would also assume fairly long
> duty cycles “I am up for tens of seconds”, which I am not sure are actually
> realistic. And, as Chris says in another email, this is trading off “the
> ability to do security” for an unknown/untested feature — which I think is
> the wrong trade-off.
>
> On he topic of “needing to put an address in” for RREP-ACK, I must admit
> that this seems roundabout. I can see three issues here:
>
> Either way, I do not like the notion of fusing
> metrics-and-link-bidirectionality-detection any more than I like fusing
> global-topology-diffusion-and-link-bidirectionality-detection.
>
> Since we’re discussing bi-directionality of links here, and the necessity
> of a mechanism for handling these, I want to call attention to a related
> issue, as I hinted previously.
>
> I do not know of *any* wireless systems, where the assumption that “link
> metrics are symmetric” actually holds. Consequently, the conclusion in the
> quoted paragraph:
>
>
> While this protocol may not want to “calculate if for this link the
> metrics is 4 or 5”, the protocol must be able to convey and distinguish
> that “the metric from A to B is 4, and the metric from B to A is 19”.
>
> This is a “related issue” since the solution may (as with the
> bi-directionality check) be in the triggered neighbour detection mechanism:
> that exchange could, if designed carefully, be used to probe for and convey
> metrics information, also.
>
> Hope this helps,
>
>
> Thomas
>
> *From:* Victoria Mercieca [mailto:[email-masked]
> <[email-masked]>]
> external partner or the internet.Consider carefully whether you should
> click on any links, open any attachments or reply.For information
> regarding **Red Flags*
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.If
> you feel the email is suspicious, please follow this process
> external partner or the internet.Consider carefully whether you should
> click on any links, open any attachments or reply.For information
> regarding **Red Flags*
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.If
> you feel the email is suspicious, please follow this process
> external partner or the internet.Consider carefully whether you should
> click on any links, open any attachments or reply.For information
> regarding **Red Flags*
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.If
> you feel the email is suspicious, please follow this process
> external partner or the internet.Consider carefully whether you should
> click on any links, open any attachments or reply.For information
> regarding **Red Flags*
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.If
> you feel the email is suspicious, please follow this process
> external partner or the internet.Consider carefully whether you should
> click on any links, open any attachments or reply.For information
> regarding **Red Flags*
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.If
> you feel the email is suspicious, please follow this process

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 25 Apr 2016 14:25:37 +0000

I’m afraid I didn’t understand your first paragraph “fix”.

With regard to the flag/address, I must admit my analysis was one step missing. I got as far as arguing it would be the same everywhere in space. I didn’t take that the extra step (which is much the same argument) to the same everywhere in time. At which point we don’t need the flag- (and, I’m saying, we don’t need the address because it’s the IP source address. (Thomas raises the issue of interfaces. Locally you should know which interface you received on - and 5444 usage makes that clearer, but is already relied on by NHDP.)

From: Justin Dean [mailto:[email-masked]]
Sent: 25 April 2016 15:20
To: Dearlove, Christopher (UK)
Cc: Victoria Mercieca; Jiazi YI; Christopher Dearlove; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***
A thought regarding integrity checking.  A possible future "fix" for integrity could be done on a "virtual" packet in which known TLVs/values along with ordered addresses are uncompressed and then verified.  It could allow extra TLV tagging without modifying the validity of that data.  The very big drawback would be the overhead of having to uncompressed everything to check the validity.  It's functionally the same as zeroing out local (this is my stuff) TLV data vs remote (this is not my stuff) TLV data.

As for the RREP-Ack having a flag vs an address doesn't much bother me as either would have to be zeroed out for this type of future integrity checking.

Justin

On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Assuming for the moment that everyone will need an RREP-Ack or won’t (let’s come back to that) why do C and B need to put an address in as an RREQ-Ack request? Why not a flag, because the address will be included as the IP sending address - and we know 5444 is required to pass that on. (It’s used by NHDP as well.) Then we don’t need to change the RREP, it will have a flag set or not, and won’t change (in this regard).

*** WARNING ***

A----B-----C

Not sure I follow here.

regards

Jiazi

*** WARNING ***

What do you think?

Kind regards,
Victoria.

Kind regards,
Victoria.

Best,

Thomas

*** WARNING ***

With you so far.

Surely you mean AODVv2

Messy, but could work.

                                    +

                                    +

*** WARNING ***

Best regards,
Lotte Steenrbink

*** WARNING ***

Thomas

*** WARNING ***

Dear all,

Loops

Security Considerations

...

[Message clipped]

---

From: [email-masked]
Date: Mon, 25 Apr 2016 16:28:52 +0200

> On 25 Apr 2016, at 16:20, Justin Dean <[email-masked]> wrote:
> 

That requires an imposed ordering of addresses, address TLVs, Message TLVs, etc., even if only “in memory”, it is something that everybody should be aware of, and doing the same way

	o	That ordering would have to be specified in this document (no, it would not be a “future fix”, this is 
		a requirement to the base spec, since *not* doing that would mean that this “future fix” could render
		current implementations non-compliant!)

	o	While this would be *hard* for the current messages/TLVs, I’d imagine that it’d make extensions
		impossible (in an interoperable fashion).

	o	It’d be *exceptionally* heavy for all intermediate routers, wanting to verify the integrity of a 
		message: to be able to force everybody in a network to “unwrap” the message into an 
		uncompressed form *before* validating its origins is opening up for DoS attacks. 

		I want to do a *minimum* number of operations with a message, *before* deciding 
		to discard a message as harmful.

> As for the RREP-Ack having a flag vs an address doesn't much bother me as either would have to be zeroed out for this type of future integrity checking.

This is not a question of future integrity checking, but a requirement for the base specification to be able to support. 

Thomas

> Justin
> 
> On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Justin Dean <[email-masked]>
Date: Mon, 25 Apr 2016 10:32:56 -0400

On Mon, Apr 25, 2016 at 10:28 AM, <[email-masked]> wrote:

> That requires an imposed ordering of addresses, address TLVs, Message
> TLVs, etc., even if only “in memory”, it is something that everybody should
> be aware of, and doing the same way
>
> If you're building the virutal packet you could specify the order there,
the on the wire packet doesn't need to be in that order.

> Not at all if the integrity check in question only used well known
registred TLVs (i.e. don't change the value of these!) types for building
the virutal packet then you could add whatever other TLV info you wanted.

> This is true enough it'd be hell on processing.

> This is not a question of future integrity checking, but a requirement for
> the base specification to be able to support.
>
> Thomas
>
>
> Justin
>
>> A first establish a route to B with long validity time. Then A initiates
>> a route discovery to C. C tends to set a short validity time, which will
>> make the route between B and A expire earlier than expected.
>>
>> 4) C receives the RREP_Ack from B, and therefore knows that B received
>> the RREP, therefore the link is bidirectional. C can then mark its route to
>> OrigAddr as valid.
>>
>> If we want to avoid changing the message, we'll need to look at
>> forwarding the RREP as-is, and creating a second message to solicit an
>> RREP_Ack, in order to verify that the link is bidirectional before marking
>> the route to OrigAddr as valid.
>>
>> Kind regards,
>>
>> Victoria.
>>
>>
>>
>>
>>
>> regards
>>
>>
>>
>> Jiazi
>>
>>
>>
>>
>>
>> *-- *
>>
>>
>>
>>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 25 Apr 2016 14:32:55 +0000

We actually took what became RFC 5444 to the IESG with a TLV ordering requirement. It wasn’t acceptable.

And yes, they saved us from an error we would have made.

From: [email-masked] [mailto:[email-masked]]
Sent: 25 April 2016 15:29
To: Justin Dean
Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc Networks mailing list; Victoria Mercieca
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***

On 25 Apr 2016, at 16:20, Justin Dean <[email-masked]<mailto:[email-masked]>> wrote:

Thomas

Justin

*** WARNING ***

A----B-----C

Not sure I follow here.

regards

Jiazi

*** WARNING ***

What do you think?

Kind regards,
Victoria.

Kind regards,
Victoria.

Best,

Thomas

*** WARNING ***

With you so far.

Surely you mean AODVv2

Messy, but could work.

                                    +

                                    +

*** WARNING ***

Best regards,
Lotte Steenrbink

*** WARNING ***

Thomas

*** WARNING ***

Dear all,

Loops

Security Considerations

...

[Message clipped]

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 25 Apr 2016 16:37:53 +0200

> On 25 avr. 2016, at 16:32, Justin Dean <[email-masked]> wrote:
> 
> 
> 
> If you're building the virutal packet you could specify the order there, the on the wire packet doesn't need to be in that order.
>  

No idea what a virtual packet is. 

But imposing a point of universal agreement on how *any* packet - now or in the future - uncompresses  is not a trivial task. 

> Not at all if the integrity check in question only used well known registred TLVs (i.e. don't change the value of these!) types for building the virutal packet then you could add whatever other TLV info you wanted.

If I understand you correctly, then you would do the ICV only over some of the packet content? In other words, any extensions would be unprotected, OR would require an update to whatever records the "known TLVs" list?  

That to me is a showstopper, similar to M. Perkins' E2E draft, to be designing an extensible protocol specifically so that extensions are "unsecured". We can and must. do better than that. 

> This is true enough it'd be hell on processing. 

Indeed. There are many reasons why this is a bad idea. 

Thomas. 

>>>> On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>>>> T:  +44 (0)1245 242194  |  E: [email-masked]
>>>> 
>>>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>>>> If you feel the email is suspicious, please follow this process.
>>>> 
>>>> Hi Jiazi,
>>>> 
>>>> 
>>>> 
>>>>  
>>>> 
>>>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>>>> 
>>>> T:  +44 (0)1245 242194  |  E: [email-masked]
>>>> 
>>>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>>>> If you feel the email is suspicious, please follow this process.
>>>> 
>>>> Hi Chris,
>>>> 
>>>>  
>>>> 
>>>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <[email-masked]> wrote:
>>>> 
>>>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <[email-masked]> wrote:
>>>> 
>>>>  
>>>> 
>>>> T:  +44 (0)1245 242194  |  E: [email-masked]
>>>> 
>>>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>>>> If you feel the email is suspicious, please follow this process.
>>>> 
>>>>  
>>>> 
>>>> On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <[email-masked]> wrote:
>>>> 
>>>>  
>>>> 
>>>> T:  +44 (0)1245 242194  |  E: [email-masked]
>>>> 
>>>> Cc: [email-masked]; Mobile Ad Hoc Networks mailing list
>>>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>>>> If you feel the email is suspicious, please follow this process.
>>>> 
>>>> Hi all,
>>>> 
>>>>  
>>>> 
>>>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <[email-masked]>:
>>>> 
>>>>  
>>>> 
>>>> T:  +44 (0)1245 242194  |  E: [email-masked]
>>>> 
>>>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>>>> If you feel the email is suspicious, please follow this process.
>>>> 
>>>>  
>>>> 
>>>> On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <[email-masked]> wrote:
>>>> 
>>>>  
>>>> 
>>>> T:  +44 (0)1245 242194  |  E: [email-masked]
>>>> 
>>>> From: manet [mailto:[email-masked]] On Behalf Of [email-masked]
>>>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>>>> If you feel the email is suspicious, please follow this process.
>>>> 
>>>> *** WARNING ***

---

From: Justin Dean <[email-masked]>
Date: Mon, 25 Apr 2016 10:42:35 -0400

On Mon, Apr 25, 2016 at 10:26 AM, Justin Dean <[email-masked]> wrote:

> From section 7.2.3

This AODVv2 (RREP) message is used to create a corresponding [RFC5444
<https://tools.ietf.org/html/rfc5444>]
   message (see Section 8
<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-15#section-8>)
which is handed to the RFC5444 <https://tools.ietf.org/html/rfc5444>
multiplexer
   for further processing.  If the Neighbor Set contains an entry for
   the neighbor stored as LocalRoute[OrigAddr].NextHop, with
   Neighbor.State set to Confirmed, the multiplexer is instructed to
   unicast the RREP to LocalRoute[OrigAddr].NextHop.  Otherwise, it
   multicasts the RREP to LL-MANET-Routers.  The RREP MUST be sent over

   LocalRoute[OrigAddr].NextHopInterface.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 25 Apr 2016 14:51:38 +0000

I has to go back to Victoria’s summary here. It says:

That doesn’t actually indicate if that’s C’s address or B’s address being included. I’d assumed it was C’s address. Your comment makes sense if it’s B’s address. Reading again, I think you’re probably right. But only probably. Can we confirm that.

I assume you meant that the RREP (not RREP_Ack) is multicast. There’s a bit of a chicken and egg problem here. We do know how we want to unicast.

From: Justin Dean [mailto:[email-masked]]
Sent: 25 April 2016 15:26
To: Thomas Heide Clausen
Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc Networks mailing list; Victoria Mercieca
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***
The address in the RREP_Ack may be required due to the RREP_Ack being multicast as there is not yet a verified unicast route installed yet.  Going to double check if I'm remembering correctly.

Justin

On Mon, Apr 25, 2016 at 10:18 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

   networks.

Hope this helps,

Thomas

On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:

*** WARNING ***

A----B-----C

Not sure I follow here.

regards

Jiazi

*** WARNING ***

What do you think?

Kind regards,
Victoria.

Kind regards,
Victoria.

Best,

Thomas

*** WARNING ***

With you so far.

Surely you mean AODVv2

Messy, but could work.

                                    +

                                    +

*** WARNING ***

Best regards,
Lotte Steenrbink

*** WARNING ***

Thomas

*** WARNING ***

Dear all,

Loops

Security Considerations

...

[Message clipped]

---

From: Justin Dean <[email-masked]>
Date: Mon, 25 Apr 2016 10:54:04 -0400

On Mon, Apr 25, 2016 at 10:37 AM, Thomas Heide Clausen <
[email-masked]> wrote:

> But imposing a point of universal agreement on how *any* packet - now or
> in the future - uncompresses  is not a trivial task.
>
>
o While this would be *hard* for the current messages/TLVs, I’d imagine
>> that it’d make extensions
> If I understand you correctly, then you would do the ICV only over some of
> the packet content? In other words, any extensions would be unprotected, OR
> would require an update to whatever records the "known TLVs" list?
>

Correct extensions which didn't register wouldn't be protected.  It's
essentially the same as zeroing out unknown TLVs so lets go with that as
it's easier.

Those extensions in the case of AODVv2 are fundamentally different than
OLSRv2/NHDP messages as they do not contain information about the
originating router.  I get that this is an issue with current integrity
checking methods but there is value in having that data included in the
same message.  Local only information could be sent in another message
which would be locally signed.  That would work for AckReq messages but it
wouldn't work for information about the "path" traveled as there would be
no way of verifying or even associating that information with the data
contained in the original message.

Justin

That to me is a showstopper, similar to M. Perkins' E2E draft, to be
> designing an extensible protocol specifically so that extensions are
> "unsecured". We can and must. do better than that.
>
>
>

---

From: Victoria Mercieca <[email-masked]>
Date: Mon, 25 Apr 2016 15:59:46 +0100

Hi Chris,

On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> That doesn’t actually indicate if that’s C’s address or B’s address being
> included. I’d assumed it was C’s address. Your comment makes sense if it’s
> B’s address. Reading again, I think you’re probably right. But only
> probably. Can we confirm that.
>
>
>

C creates the RREP. The included AckReq address is B's address. The RREP
then gets multicast.
B receives it, sees that it own address is marked as the AckReq address,
and sends an ack unicast back to C.
Anyone else who receives the multicast RREP from C does not send the Ack,
since the AckReq address does not match any of their interface addresses.

> I assume you meant that the RREP (not RREP_Ack) is multicast. There’s a
> bit of a chicken and egg problem here. We do know how we want to unicast.
>

The RREP is multicast (when we dont know if the link is bidirectional), the
RREP_Ack is always unicast.

Kind regards,
Vicky.

> *From:* Justin Dean [mailto:[email-masked]]
> *Sent:* 25 April 2016 15:26
> *To:* Thomas Heide Clausen
> Networks mailing list; Victoria Mercieca
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
> [email-masked]
>
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
> [email-masked]
>
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
> [email-masked]
>
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
> [email-masked]
>
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
> [email-masked]
>

---

From: Justin Dean <[email-masked]>
Date: Mon, 25 Apr 2016 11:00:57 -0400

On Mon, Apr 25, 2016 at 10:51 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Yes I meant RREP and not RREP_Ack.

>From 7.2.3 again

The procedure for RREP regeneration is as follows:

   1.  If the link to the next hop router toward OrigAddr is not known
       to be bidirectional, include the AckReq with the address of the
       intended next hop router

 2. Set AddressList, PrefixLengthList, TargSeqNum and MetricType to

       the values in the received RREP

   3.  Set TargMetric := LocalRoute[TargAddr].Metric

4.  If the received RREP contains a ValidityTime, or if the
       regenerating router wishes to limit the time that it will offer a
       route to TargAddr (and any other addresses included in the given
       prefix length), the regenerated RREP MUST include ValidityTime

       *  The ValidityTime is either the time limit the previous AODVv2
          router specified, or the time limit this router wishes to
          impose, whichever is lower.

---

From: Jiazi YI <[email-masked]>
Date: Mon, 25 Apr 2016 17:29:45 +0200

Hi,

Maybe I missed a bit here:

If only the desired receiver of the multicast RREP (carrying a destination
address) can reply to the multicast RREP, why not using unicast directly?

best

Jiazi

On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca <[email-masked]>
wrote:

> The RREP is multicast (when we dont know if the link is bidirectional),
> the RREP_Ack is always unicast.
>
> Kind regards,
> Vicky.
>
>
>>
>> *-- *
>>
>>
>>
>>

---

From: Justin Dean <[email-masked]>
Date: Mon, 25 Apr 2016 11:34:52 -0400

On Mon, Apr 25, 2016 at 11:29 AM, Jiazi YI <[email-masked]> wrote:

> Because the link isn't yet known to be bi-directional and a unicast route
can't be installed yet.

Justin

>>> That doesn’t actually indicate if that’s C’s address or B’s address
>>> being included. I’d assumed it was C’s address. Your comment makes sense if
>>> it’s B’s address. Reading again, I think you’re probably right. But only
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** WARNING ****
>>>
>>> Since we’re discussing bi-directionality of links here, and the
>>> necessity of a mechanism for handling these, I want to call attention to a
>>> related issue, as I hinted previously.
>>>
>>>
>>>
>>> I do not know of *any* wireless systems, where the assumption that
>>> “link metrics are symmetric” actually holds. Consequently, the conclusion
>>> in the quoted paragraph:
>>>
>>>
>>>
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** WARNING ****
>>>
>>> So the question is, is this a feature that’s really wanted?
>>> Unfortunately I think we know that the answer to that is, we don’t know
>>> because we don’t have any experience. My view would be that in the tradeoff
>>> of an untested feature (unless I’m wrong about that) and the security
>>> complication, security wins and drop the feature. If there is some real
>>> requirement, then there’s a discussion. (Questions like how often the
>>> intermediate routers actually have any knowledge - typically links break
>>> for unexpected rather than expected reasons. Andan intermediate router
>>> could possibly use a validity time to influence its behaviour.) Note that
>>> dropping the ability of intermediate routers to modify/set still allows
>>> validity times per route to be set at endpoints.
>>>
>>>
>>>
>>> On the other hand, I'm not sure this option will give us much help.
>>> Chris mentioned much knowledge intermediate router would have to decide
>>> this value (and how much sense the value would make).
>>>
>>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both
>>> install a route to OrigAddr but they dont yet know if it's valid because
>>> they dont know if the link to their next hop is available in the reverse
>>> direction.
>>>
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** WARNING ****
>>>
>>>
>>>
>>> Continued in this thread because the other one seems to be more about
>>> TLV types and metric type numbers, whereas this is about
>>> regeneration/forwarding.
>>>
>>>
>>>
>>> - However, RERR (sent when a source of traffic is sending data on a
>>> route which comes through you, and you want to tell the Packet Source's
>>> router to delete the route) could be seen as an end-to-end message which
>>> all intermediate routers learn from, similar to RREQ and RREP. It reports
>>> one route, and doesn't need changing at intermediate hops, so could be
>>> protected with ICV.
>>>
>>> - Would it be OK to only require a message ICV if a PktSource address
>>> was included, i.e. when the message needs to go via a number of
>>> intermediate hops to PktSource's router? All other RERRs are intended to be
>>> one-hop messages, which may in turn prompt other one-hop messages, etc...,
>>> and a packet ICV might be more appropriate?
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Victoria.
>>>
>>>
>>>
>>> No. That is one of the issues I raise in my original. For some reason,
>>> it cites RFC6551, which is a ROLL document and which has in its abstract
>>> that:
>>>
>>>
>>>
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** WARNING ****
>>>
>>>
>>>
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** WARNING ****
>>>
>>>
>>>
>>> *Subject:* Re: Message integrity and message mutability (was RE:
>>> [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** WARNING ****
>>>
>>>
>>>
>>> That said, "AODVv2 wants to accumulate metrics” — does that mean that
>>> the message grows as it is being forwarded, and that the recipient of a
>>> I’ve previously offered reviews and comments, and some of those have
>>> been addressed in the latest I-D — others have not, but should be. I recall
>>> that there was some mail attempting to rebut parts of the review, and I
>>> will dig it out and reply to that.
>>>
>>>
>>>
>>> With that being said, I have reviewed the latest version of the
>>> document, and full details will be forthcoming. There’re a couple of
>>>             o          *It renders the hop-limit/hop-count fields in
>>> the RFC5444 message header useless.*
>>>
>>>             o          *It makes end-to-end authentication
>>> unnecessarily hard.*
>>>

---

From: Jiazi YI <[email-masked]>
Date: Mon, 25 Apr 2016 17:42:07 +0200

On Mon, Apr 25, 2016 at 5:34 PM, Justin Dean <[email-masked]> wrote:

>> If only the desired receiver of the multicast RREP (carrying a
>> destination address) can reply to the multicast RREP, why not using unicast
>> directly?
>>

Does it matter? I can send a unicast to the next hop anyways: if I didn't
get a RREP-ACK, then it's unidirectional, so that I can blacklist the next
hop.

If I get a RREP-ACK, then it's bidirectional and I can continue to set up
the (bi-directdional) route.

best

Jiazi

>>> Anyone else who receives the multicast RREP from C does not send the
>>> Ack, since the AckReq address does not match any of their interface
>>> addresses.
>>>
>>>
>>>> I must admit that while I have reviewed the protocol several times,
>>>> I’ve not been digging that deep into the protocol functioning to catch this
>>>> On he topic of “needing to put an address in” for RREP-ACK, I must
>>>> admit that this seems roundabout. I can see three issues here:
>>>>
>>>>
>>>>
>>>> Now let’s consider do we know whether we can set a fixed flag. First
>>>> I’d say there are two cases - you’ve got a firm control on what’s going on
>>>> in your network, or it’s one of unknown parties and behaviour (consistent
>>>> with specification). In the former case you only want one setting, for
>>>> example no-Ack if running NHDP or your MAC layer tells you about
>>>> bidirectionality, Ack otherwise. In the latter case, I think you just
>>>> always want an Ack. So both cases get you to the same place.
>>>>
>>>>
>>>>
>>>> With regard to your validity time point, we here have a tradeoff. If
>>>> you allow that feature, it significantly impacts on the approach that was
>>>> The ValidityTime is optional, which makes the integrity protection
>>>> hard. Furthermore, it gives a potential attack vector: as all the routers
>>>> in a path will take the shortest validityTime, a compromised router can set
>>>> the the validityTime to a very short value, which will make the route
>>>> installed along the path became invalid (very soon).
>>>>
>>>>
>>>>
>>>> Another issue is, a route to a destination might be updated by
>>>> different sources. For example, in the network below:
>>>>
>>>>
>>>>
>>>> A----B-----C
>>>>
>>>>
>>>>
>>>> A first establish a route to B with long validity time. Then A
>>>> initiates a route discovery to C. C tends to set a short validity time,
>>>> which will make the route between B and A expire earlier than expected.
>>>>
>>>> *Cc:* [email-masked]; Dearlove, Christopher (UK); Mobile Ad
>>>> Hoc Networks mailing list
>>>>
>>>>
>>>> This message could maybe also include "I'm happy to route anywhere for
>>>> a certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>>>> - Would adding a Validity Time TLV at an intermediate hop be
>>>> acceptable? The whole TLV could be removed in order to calculate the ICV?
>>>>
>>>> As mutating (other than hop count/limit) messages aren’t covered by
>>>> 5444 or any derivative document (but only recommended against, not banned)
>>>> that you may need to make the message otherwise immutable (no
>>>> deconstruction and rebuilding, other than guaranteed unchanging) that would
>>>> have to be specified by AODVv2. (Easy to say, but needs saying.)
>>>>
>>>>
>>>>
>>>> With you so far.
>>>>
>>>>
>>>>
>>>> Good point about whether you just pass on one cost or a set of costs.
>>>> As I said, not looked at details - I will, when time permits. One cost is
>>>> much easier, and yes, it reduces the fixed size aggregated signatures
>>>> problem to “just” one of computational load.
>>>>
>>>>
>>>>
>>>> It’s hard to handle end to end. Charlie’s draft attempts to do an end
>>>> to end of some information, not this information. I’m not sure if that’s
>>>>                         is to add constraints on (i) the set of
>>>> elements to include in a signature and (ii) the
>>>>
>>>>                         order of these elements.
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> 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
>>>> 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.
>>>>
>>>>
>>>>
>>>> For example (with the assumption that messages are *forwarded* and
>>>> *not* regenerated), this could be one option:
>>>>
>>>>
>>>>

---

From: Victoria Mercieca <[email-masked]>
Date: Wed, 27 Apr 2016 20:16:45 +0100

Hi Chris,

> of intermediate routers to modify/set still allows validity times per route
In the RREQ, the route contained within the message is the route to
OrigPrefix. Why would RREQ_Gen want to limit that? I can understand
intermediate routers might not want to commit resources for too long, but
can't see why RREQ_Gen would ever want to limit the time the route to its
Router Client is available? Similarly for the route to TargPrefix in the
RREP. Should we remove Validity Times altogether?

Kind regards,
Victoria.

---

From: Victoria Mercieca <[email-masked]>
Date: Wed, 27 Apr 2016 21:59:41 +0100

Just quickly, on this note, if we remove the AckReq from the RREP itself,
then because the RREP is multicast, there might be multiple receivers, but
there's no way for them to determine if they were the intended next hop, so
they would all have to forward the RREP. The RREP might then go by multiple
routes to get to RREQ_Gen. This assumes all receivers of the RREP have a
route to OrigAddr anyway (current rules say if they didnt, they would send
a RERR back to RREP_Gen).

So, do we have to install a route to the neighbour, then unicast the RREP
and create a separate message with an AckReq, then if no acknowledgement is
received, blacklist the neighbor and remove the route to the neighbor?
along with the route to OrigAddr which is not available because the link is
not bidirectional...?

Regards,
Victoria.

---

From: Jiazi YI <[email-masked]>
Date: Thu, 28 Apr 2016 00:34:55 +0200

> along with the route to OrigAddr which is not available because the link is

My opinion is, if we have a neighbor address and the interface through
which the neighbor can be (possibly) reached, then we can send an unicast
to it.
The others are more implementation details: for example, if a route to the
neighbor is required, we can setup a temporary route entry to the neighbor,
and remove it after the unicast is finished. As it's more implementation, I
don't think it's necessary to go to the specification.

Another related question: when I was reading the specification, a router
only sets up routes to the source/destination, but not to its direct
neighbors?

best

Jiazi

>>> Because the link isn't yet known to be bi-directional and a unicast
>> route can't be installed yet.
>>
>> Justin
>>
>>
>>> best
>>>
>>> Jiazi
>>>
>>> On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca <[email-masked]
>>> > wrote:
>>>
>>>> Hi Chris,
>>>>
>>>>
>>>> C creates the RREP. The included AckReq address is B's address. The
>>>> RREP then gets multicast.
>>>> B receives it, sees that it own address is marked as the AckReq
>>>> address, and sends an ack unicast back to C.
>>>>> I assume you meant that the RREP (not RREP_Ack) is multicast. There’s
>>>>> a bit of a chicken and egg problem here. We do know how we want to unicast.
>>>>>
>>>>
>>>>> attachments or reply. For information regarding **Red Flags** that
>>>>> you can look out for in emails you receive, click here
>>>>> I am afraid that I do not understand the use of inserting validity
>>>>> TLVs while in-flight, into a message. Actually, I am dubious for both the
>>>>> Should that not be an acceptable argument (though I think it’s good
>>>>> for where we are - in fact always Ack is close) then at flag is a step
>>>>> better, it’s a fixed location to change. However it would be better in that
>>>>> case if the two things to change (metric and ack flag) were together. But
>>>>> that has its own issues, so I won’t go there.
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> attachments or reply. For information regarding **Red Flags** that
>>>>> you can look out for in emails you receive, click here
>>>>> - For Validity Time, its a way to advertise that you would only
>>>>> support the route contained in the message for a certain period of time.
>>>>> The originator might use this, but the draft was written to allow any
>>>>> - For the AckReq address, its so that you can add into a RREP a
>>>>> request for an acknowledgement, so that you don't have to have a different
>>>>> message type altogether for working out whether links to neighbors are
>>>>> In order to avoid the potential AckReq-related changes to each
>>>>> message, maybe we do need to introduce a different message specifically for
>>>>> this. We could maybe use RREP_Ack to both request and acknowledge? It means
>>>>> an extra message of control traffic that needs to be sent, maybe one extra
>>>>> message per hop on the path of a RREP, but it could still be limited to
>>>>> neighbors which have participated in the route discovery rather than
>>>>> monitoring all neighbors at all times.
>>>>>
>>>>>
>>>>>
>>>>> Pretty much all of the discussion has been assuming only a metric
>>>>> value change. With multiple things changing many of the ideas go out of the
>>>>> - Would adding an address cause issues for the ICV, because it's in
>>>>> the address block? Could the rule be "if it contains an AckReq address,
>>>>> remove it (and the corresponding value in the AddressType TLV), before
>>>>> checking the ICV", is that OK? Or would we need to avoid touching the
>>>>> ICV'ed part of the message altogether, maybe put the AckReq address in a
>>>>> separate Address Block, with an extra AddressType TLV following that
>>>>> address block? Is there a way to accomplish this?
>>>>>
>>>>>
>>>>>
>>>>> - RERR (sent when a link breaks) is a way of saying "I've lost my
>>>>> route so I'm telling others" and "you were my next hop, so now I've also
>>>>> lost my route, I'll tell others", etc. It's going to be tailored at each
>>>>> step to include the relevant routes that got deleted, it's not one message
>>>>> being sent end-to-end like RREQ and RREP are.
>>>>>
>>>>> As base specification I would simply say “Include a Metric Type
>>>>> Message TLV with a value field, and a 7182 Message TLV & Timestamp” as we
>>>>> do in OLSRv2 (with the appropriate verbiage as to generation and
>>>>> processing).
>>>>>
>>>>>
>>>>>
>>>>> With the message generated by the originator of the RREQ/RREP and
>>>>> *not* deconstructed/reconstructed/reordered (as is the risk with
>>>>> “regeneration) allows knowing that it would be *only* that metric field
>>>>> being modified (other than hop count/limit) for when eventually writing up
>>>>> the extension.
>>>>>
>>>>>
>>>>>
>>>>> I don’t think there is an ideal solution. (I like ideas I’ve seen
>>>>> about aggregating, but that has some issues of its own, even apart from
>>>>> *From:* manet [mailto:[email-masked] <[email-masked]>
>>>>> ] *On Behalf Of [email-masked]
>>>>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of
>>>>> big ticket Items
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                         Fortunately, that is relatively easy to
>>>>> handle: simply zero out the value of that TLV when
>>>>>
>>>>>                         exist, and an interesting use-case can be
>>>>> found in also reactive protocols, allowing verifying
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>

---

From: Victoria Mercieca <[email-masked]>
Date: Thu, 28 Apr 2016 17:55:48 +0100

Hi Jiazi,

Thanks for your response. So you think we could change back to sending RREP
by unicast (letting an implementation handle whether this requires a route
to the neighbor to be installed temporarily)? We would have to also send a
separate message to request an acknowledgement, but this could also be
unicast and could therefore potentially be sent in the same RFC5444 packet.

Anyone have any objections?

Kind regards,
Victoria.

On Wed, Apr 27, 2016 at 11:34 PM, Jiazi YI <[email-masked]> wrote:

>>>> On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca <
>>>> [email-masked]> wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>>
>>>>> The RREP is multicast (when we dont know if the link is
>>>>> bidirectional), the RREP_Ack is always unicast.
>>>>>
>>>>> Kind regards,
>>>>> Vicky.
>>>>>
>>>>>
>>>>>>
>>>>>> *-- *
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad
>>>>>> Hoc Networks mailing list; Victoria Mercieca
>>>>>> *This message originates from outside our organisation, either from
>>>>>> an external partner or the internet.*
>>>>>>
>>>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad
>>>>>> *This message originates from outside our organisation, either from
>>>>>> an external partner or the internet.*
>>>>>>
>>>>>> 4) C receives the RREP_Ack from B, and therefore knows that B
>>>>>> received the RREP, therefore the link is bidirectional. C can then mark its
>>>>>> route to OrigAddr as valid.
>>>>>>
>>>>>> *This message originates from outside our organisation, either from
>>>>>> an external partner or the internet. Consider carefully whether you should
>>>>>> This message could maybe also include "I'm happy to route anywhere
>>>>>> for a certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>>>>>> Ignoring how this misunderstanding happened, I'll start by asking
>>>>>> why. Metric changing I understand. Why the other two? (there's a partial
>>>>>> - adding an address (and corresponding value in the AddressType TLV
>>>>>> to indicate how to interpret the address) to indicate the address from
>>>>>> which an RREP_Ack is expected, to accomplish the bidirectionality check
>>>>>> (can happen in RREP).
>>>>>>
>>>>>> If we define a certain portion of the message as immutable and
>>>>>> include the ICV to verify that part, end to end:
>>>>>> No. That is one of the issues I raise in my original. For some
>>>>>> reason, it cites RFC6551, which is a ROLL document and which has in its
>>>>>> abstract that:
>>>>>>
>>>>>>
>>>>>>
>>>>>> *This message originates from outside our organisation, either from
>>>>>> an external partner or the internet. Consider carefully whether you should
>>>>>> Then that information is not in a guaranteed fixed location given by
>>>>>> a simple offset. So any signature algorithm that finds it and ignores it or
>>>>>> *This message originates from outside our organisation, either from
>>>>>> an external partner or the internet. Consider carefully whether you should
>>>>>> *This message originates from outside our organisation, either from
>>>>>> an external partner or the internet. Consider carefully whether you should
>>>>>> The issues over end to end authentication and more advanced
>>>>>> signatures are valid. I need to read the given reference on aggregate
>>>>>> signatures to increase my knowledge (thanks for it), but my understanding
>>>>>> of the possibilities in this field may offer a solution to the problem, but
>>>>>> with some other issues (possibly including a new type of TLV).
>>>>>>
>>>>>>
>>>>>>
>>>>>> *This message originates from outside our organisation, either from
>>>>>> an external partner or the internet. Consider carefully whether you should
>>>>>>                         — sadly, it is. For example, for scope
>>>>>> limited flooding (expanding ring search, and
>>>>>>

---

From: Justin Dean <[email-masked]>
Date: Thu, 28 Apr 2016 13:08:44 -0400

On Thu, Apr 28, 2016 at 12:55 PM, Victoria Mercieca <[email-masked]>
wrote:

> Hi Jiazi,
>
> Thanks for your response. So you think we could change back to sending
> RREP by unicast (letting an implementation handle whether this requires a
> route to the neighbor to be installed temporarily)? We would have to also
> send a separate message to request an acknowledgement, but this could also
> be unicast and could therefore potentially be sent in the same RFC5444
> packet.
>

I don't think it's a good idea to "temporarily" add a route that is not
known to be bi-directional yet.  The timing of correctly adding and
removing the route with different mediums and restricting the route to only
that one packet doesn't seem like a workable solution.    Sending it
unicast with a raw type socket or pcap out of a known interface sure.  IMO
a route shouldn't be added until the link is confirmed bi-directional.

Justin

---

From: Henning Rogge <[email-masked]>
Date: Thu, 28 Apr 2016 19:40:29 +0200

On Thu, Apr 28, 2016 at 7:08 PM, Justin Dean <[email-masked]> wrote:
> known to be bi-directional yet.  The timing of correctly adding and removing
> the route with different mediums and restricting the route to only that one
> packet doesn't seem like a workable solution.    Sending it unicast with a
> raw type socket or pcap out of a known interface sure.  IMO a route
> shouldn't be added until the link is confirmed bi-directional.

Using IPv6 linklocal unicast would work fine because you always have a
route for the network.

Installing IPv4 linklocal addresses would give the same for IPv4.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 28 Apr 2016 21:12:50 +0200

> On 28 Apr 2016, at 19:40, Henning Rogge <[email-masked]> wrote:
> 

Not to forget:

    https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00

So assuming what works with v6 seems the way to go.

Thomas

---

From: Jiazi YI <[email-masked]>
Date: Thu, 28 Apr 2016 22:44:29 +0200

> a route shouldn't be added until the link is confirmed bi-directional.

The point that I want to make is, it's possible to send unicast RREP even
without a route being set -- let the implementor decide which is the best
way.
Regarding the information of requesting RREP-ACK: it can be a flag (which
is much easier to secure than a optional address field), or another RFC5444
message.
Someone probably doesn't like such flags (because it must be zeroed when
calculating ICV), but I don't have strong opinion on that.

Jiazi