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 Jiazi,




On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <[e-mail]> wrote:

> Hi,
>
> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
> [e-mail]> 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.
>
>

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.
>>
>
> 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
>
>
>>
>>
>> *-- *
>>
>>
>>
>>
>> *Christopher Dearlove Senior Principal Engineer BAE 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:* Victoria Mercieca [mailto:[e-mail]]
>> *Sent:* 23 April 2016 10:55
>> *To:* Christopher Dearlove
>> *Cc:* [e-mail]; 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 <
>> [e-mail]> 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
>>
>> [e-mail] (iPhone)
>>
>> [e-mail] (home)
>>
>>
>> On 23 Apr 2016, at 00:26, Victoria Mercieca <[e-mail]> 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, <[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 Dearlove Senior Principal Engineer BAE 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 Dearlove Senior Principal Engineer BAE 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 Dearlove Senior Principal Engineer BAE 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 Dearlove Senior Principal Engineer BAE 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
>>
>>
>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> 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.
>> ********************************************************************
>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>