[aodvv2-discuss] Re: End to end security model

  • From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Fri, 4 Mar 2016 14:58:13 +0100


Am 04.03.2016 um 14:31 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:

Hehe sorry Lotte, my bad, I missed that!

No worries, just thought I'd mention it so we don't have the same discussion in 
two places :)


Vicky

On Fri, Mar 4, 2016 at 12:00 PM, Lotte Steenbrink 
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky, hi all,

Am 03.03.2016 um 11:30 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:

Agreed,

Just to add a little maybe, before you do...
Since OrigAddr, TargAddr, both prefixlengths, any seqnums, and metric type, 
will be (should be, if not be tampered with!) the same in every regenerated 
version of the message, an ICV could be calculated over these fields. This 
block of information could be classed as the "message" which will be 
forwarded, although there will also be some extra info that may change at 
intermediate hops, i.e. metric, validity time and ackreq. 

By forwarding that chunk unchanged with ICV from the originator, we can be 
sure that all intermediate routers have received a message which originated 
from a trusted router, and therefore the route via the intermediate router 
can be trusted, even if we dont have a security association with this 
intermediate router. 

However, the RFC5444 message would still differ at each hop (Metric, 
validity time, ackreq)...so I don't know if that defeats the purpose...its 
still not forwarded....but it's not a total regeneration either.....

Also, metrics are very important in route decisions and could still be 
manipulated since not protected by ICV. 


Just FYI, I think that's what I tried to describe in 
http://ietf.10.n7.nabble.com/AODVv2-Security-considerations-update-td487447.html#a488740
 (the big chunk of text starting with "The way I'm understanding the E-Mail 
you're citing, your issue"). I think it's great that this gets its own thread 
soon. :)

Cheers,
Lotte

Definitely get this discussion on MANET sooner rather than later though. 
Thanks Charlie!


Kind regards,
Vicky.




On Wed, Mar 2, 2016 at 10:06 PM, John Dowdell <john.dowdell486@xxxxxxxxx> 
wrote:
Charlie

I similarly award you a large helping of encouragement!

Regards
John

On 2 Mar 2016, at 17:02, Ratliff, Stanley <sratliff@xxxxxxxxxxx> wrote:

Charlie,

I encourage you to write that up, and post to the MANET list.

Regards,
Stan


-----Original Message-----
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-
bounce@xxxxxxxxxxxxx] On Behalf Of Charlie Perkins
Sent: Wednesday, March 02, 2016 11:59 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] End to end security model


Hello folks,

It would be simple enough to make some sort of end-to-end security with
positive effects.  Not a cure-all, of course, but perhaps worthwhile.

Suppose that OrigNode and TargNode share a security association. Then:
a) OrigNode could include a signature as one of the RFC 5444 TLVs in the
RREQ, calculated including its sequence number
b) TargNode could do the same in the RREP.

This would at least assure each node that they were in communication with 
a
real partner, even if there were compromised intermediate nodes.

With a small bit of encouragement, I will write this up and submit it
straightaway.  It does not need to include the method by which the 
security
association is established.

Regards,
Charlie P.




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






Other related posts: