I thought with all the disapproval of the current transitive trust model,
this would go some way to resolving that, and therefore would be part of
the main draft?
Kind regards,
Vicky.
On Thu, Mar 3, 2016 at 3:41 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,
I wrote it as a new draft because it's a new feature that was never part
of the protocol before, and indeed never really requested until recently.
But on the other hand the reason I asked a question to this list was so
that I could get your feedback...
Regards,
Charlie P.
On 3/3/2016 7:35 AM, Victoria Mercieca wrote:
Hi Charlie,
Why a new draft? Just email it as discussion and ask for feedback?
Kind regards,
Vicky
On Thu, Mar 3, 2016 at 2:26 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,
Thanks for following up. I'll try to get this draft out today, and I
will resume working on it now.
Should it be a separate draft, or incorporated into the text of AODVv2?
I've been writing it up as a separate draft in order to reduce the impact
on the base draft, but it could go either way.
Regards,
Charlie P.
On 3/3/2016 2:30 AM, Victoria Mercieca wrote:
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.
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>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:
aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-
Charlie,
I encourage you to write that up, and post to the MANET list.
Regards,
Stan
-----Original Message-----
From: <aodvv2-discuss-bounce@xxxxxxxxxxxxx>
withbounce@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
thepositive 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
with aRREQ, 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
securityreal 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
individualassociation 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
or entity to whom they are addressed. If you are not the originalemail
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
in error, please delete it and immediately notify the sender.
_____________________________________________________
