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

[Victoria Mercieca <[e-mail]>]

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, <[e-mail]> wrote:

>
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
> [e-mail]> 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*:  [phone]  |  *E: *[e-mail]
>
> 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:* [e-mail] [mailto:[e-mail]
> <[e-mail]>]
> *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) <
> [e-mail]> 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*:  [phone]  |  *E: *[e-mail]
>
> 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:[e-mail]
> <[e-mail]>]
> *Sent:* 17 March 2016 16:48
> *To:* Dearlove, Christopher (UK)
> *Cc:* [e-mail]; 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) <
> [e-mail]>:
>
> 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*:  [phone]  |  *E: *[e-mail]
>
> 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:* [e-mail] [mailto:[e-mail]
> <[e-mail]>]
> *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) <
> [e-mail]> 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*:  [phone]  |  *E: *[e-mail]
>
> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *[e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>