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

["Dearlove, Christopher (UK)" <[e-mail]>]

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.)

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. 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.

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

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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:[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]<mailto:[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 Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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: [e-mail]<mailto:[e-mail]> [mailto:[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]<mailto:[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 Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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:[e-mail]] On Behalf Of [e-mail]<mailto:[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)

                        o          When a RREQ, RREP message is transmitted  (by the source, or forwarded by an intermediary)
                                    in an RFC5444 packet, an ICV Packet TLV is added to the packet, which is calculated <this way> …

                        o          When an RFC5444 packet is received, validate the ICV Packet TLV <this way> and if the ICV doesn’t validate,
                                    discard the contained messages.

                        o          When receiving a RREQ/RREP (either as destination, or as an intermediary), validate the ICV Message TLV
                                    <this way> and if the ICV doesn’t validate, discard the message, do not process, do not forward.

This is a different (and more flexible?) model than “just” transitive trust and “just” end-to-end trust discussed previously, and is enabled by the “forwarding” bit described previously.

Metrics
I have asked this numerous times, but have not gotten any answer so I am escalating this again. Why is this document having a normative reference to RFC6551?


   [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,

              and D. Barthel, "Routing Metrics Used for Path Calculation

              in Low-Power and Lossy Networks", RFC 6551<https://tools.ietf.org/html/rfc6551>, DOI 10.17487/

              RFC6551<https://tools.ietf.org/html/rfc6551>, March 2012,

              <http://www.rfc-editor.org/info/rfc6551>.


Unless I am mistaken, this is not the ROLL WG. And the abstract to RFC6551 explicitly reads:


   Low-Power and Lossy Networks (LLNs) have unique characteristics

   compared with traditional wired and ad hoc networks that require the

   specification of new routing metrics and constraints.
Which explicitly is disclaiming that these metrics are not applicable in ad hoc networks — and, I am wondering, what has changed since the publication of RFC6551 to suddenly make these applicable?

 I am also wondering if looking at (and, perhaps, using?) the same metric type TLV type as in OLSRv2 is not a possibility?

Either way, referencing RFC6551 here is wrong.

RFC6621 (SMF) usage
As late as earlier this month, RFC6621 reared its head again on the mailing list. I understand that the authors are set on using flooding reduction as part of RREQ distribution. If that is the case, then this protocol MUST specify that flooding reduction.

Saying “Use RFC6621” won’t work, for reasons Chris point out in an email earlier to the list:
The network does not and fundamentally cannot offer multicast suppression to AODVv2. This isn't a hard concept, but seems to keep having to be said. AODVv2 messages are carried in 5444 packets, and those only travel one hop. That doesn't allow for suppression. Furthermore AODVv2 is creating new messages each hop. That needs AODVv2 specific handling.

And quoting an email from myself:
If protocol X relies on using a flooding operation, then it certainly is protocol X's responsibility to  specify the flooding operation (or, at least, the requirements to the flooding operation ) for correct functioning of protocol X.

I’ve previously pointed out that RFC6621 requires some degree of configuration (can’t just, for example, pick two different relay set selection algorithms, as that may produce a disconnected flooding domain).

In other words, what the authors propose in https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00 is insufficient.

Multiple interfaces configured with the same address(es) - & RFC6621
I think that it has been established that the ability to use the same address on multiple interfaces is a requirement. It’s not clear to me that a single way of doing so has been proposed, nor that the “operating conditions” are called out (for example, will it work  if router A and router B both have two interfaces, and that all 4 interfaces use the same IP address?)

This is not entirely unrelated to flooding reduction and RFC6621. One of the complexities is to get that just right: OLSRv2 - for example - calculates Flooding-MPRs per interface, and RFC6130 is careful in how it detects bidirectionality of links.

I have not worked out all the details of how this impacts this protocol — but, it requires attention. Especially when wanting to be able to say “…use RFC6621”, then the interface configuration constraints when faced with multiple interfaces must be worked out.

Prefixes & Gateways
A question to my mind, and I am not sure I know how to answer that from reading the draft since it is not discussed in section 9 (at least), is: “What happens if I send a RREQ to a prefix” (i.e., a /<128 in IPv6)?

            o          If the whole prefix is part of the attached network set of a single router,
                        then I expect to get a single RREP back, is that the case?

            o          If "half the prefix"  is part of the attached network set of a single router,
                        and the other half is part of the attached network set of another  single router,
                        then I expect two RREPs, is that the case?

            o          More generally, will I get a tree build through the network here?

Section 9 (or, the whole spec) is also not explicit enough about multiple  "default gateways" — i.e., the external network being “the rest of the Internet”, and there being multiple gateways to the Internet. I understand how the RREQ gets to the gateway, and how the gateway determines if it should respond (the destination is not part of “the MANET prefix, with which it is configured”).

But, if A is close to GW1, and B is close to GW2, but A and B being far far apart (according to the metric used) within the MANET, then it would be preferential for the route from A to B to go via GW1-“the-Internet”-GW2?

Is this a supported configuration?
            o          If yes, how is it (seq# wise, I would expect some complications) handled?
            o          If not, where is it stated that this configuration is not possible with this protocol?


The applicability statement says:


   AODVv2 is designed for stub or disconnected mobile ad hoc networks,

   i.e., non-transit networks or those not connected to the internet.

   AODVv2 can, however, be configured to perform gateway functions when

   attached to external networks, as discussed in Section 9<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-9>.

I believe that the scenario I describe is indeed a stub network (and not a transit network)?

— — —

As I indicated, these are the big-picture issues that I have gotten around to thinking about enough to write up. I’m not through working through the document, but those were the ones that came to mind, and which seem imperative to resolve.

Best,

Thomas



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

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