Vicky,
I think Justin caught this (and responded) on the MANET list.
Regards,
Stan
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Victoria Mercieca
Sent: Monday, April 25, 2016 10:18 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Fwd: [manet] Message integrity and message mutability
(was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Hi all,
Chris asks a question which is related to the whole multicast-RREP thing. It
was something I was quite confused with last year, so would anyone else like to
step in...?
As far as I remember, its because, if we were to unicast it to the next hop
neighbor, when the packet is handed to IP it might not have a route to the
neighbor and could then come back to AODVv2 and say "can I have a route to this
address please". Something to do with not necessarily talking AODVv2 on a
common subnet? Did a quick email search and these might jog your memories:
//www.freelists.org/post/aodvv2-discuss/Section-652Unconfirmed-routes,27
//www.freelists.org/archive/aodvv2-discuss/06-2015
I cant remember if we say anything about adding a route to a neighbor as part
of AODVv2?
Regards,
Vicky.
---------- Forwarded message ----------
From: Dearlove, Christopher (UK)
<chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>>
Date: Mon, Apr 25, 2016 at 2:27 PM
Subject: RE: [manet] Message integrity and message mutability (was RE:
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
To: Victoria Mercieca <vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>>,
Jiazi YI <ietf@xxxxxxxxxxx<mailto:ietf@xxxxxxxxxxx>>
Cc: Christopher Dearlove
<chris@xxxxxxxxxxxxxxxxxxxxx<mailto:chris@xxxxxxxxxxxxxxxxxxxxx>>, Mobile Ad
Hoc Networks mailing list <manet@xxxxxxxx<mailto:manet@xxxxxxxx>>
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.
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T: +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194> | E:
chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>
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:vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>]
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 ***
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 Jiazi,
On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI
<ietf@xxxxxxxxxxx<mailto:ietf@xxxxxxxxxxx>> wrote:
Hi,
On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK)
<chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>> 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: +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194> | E:
chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>
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:vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>]
Sent: 23 April 2016 10:55
To: Christopher Dearlove
Cc: ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>; 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
<chris@xxxxxxxxxxxxxxxxxxxxx<mailto:chris@xxxxxxxxxxxxxxxxxxxxx>> 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
christopher.dearlove@xxxxxxxxx<mailto:christopher.dearlove@xxxxxxxxx> (iPhone)
chris@xxxxxxxxxxxxxxxxxxxxx<mailto:chris@xxxxxxxxxxxxxxxxxxxxx> (home)
On 23 Apr 2016, at 00:26, Victoria Mercieca
<vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>> 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,
<ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>> wrote:
On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)
<chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>> 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: +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194> | E:
chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>
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: ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>
[mailto:ietf@xxxxxxxxxxxxxxxxx]
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)
<chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>> 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: +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194> | E:
chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>
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:lotte.steenbrink@xxxxxxxxxxxx]
Sent: 17 March 2016 16:48
To: Dearlove, Christopher (UK)
Cc: ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>; 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)
<chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>>:
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:
chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>
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: ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>
[mailto:ietf@xxxxxxxxxxxxxxxxx]
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)
<chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>> 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:
chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>
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:manet-bounces@xxxxxxxx] On Behalf Of ;
ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>
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
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
This 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
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
