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

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 3 Mar 2016 07:49:28 -0800

Hello Vicky,

No worries, I'll post my text to the [manet] list and you can incorporate it into the draft. Or perhaps better I'll post it here for your feedback before posting it to the list.

Yes the transitive trust model has well-known problems for large node populations, but these are not new problems and we had been going along with that trust model for a long time.

Regards,
Charlie P.


On 3/3/2016 7:43 AM, Victoria Mercieca wrote:

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 <mailto: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
    <mailto: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
        <mailto: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 <mailto: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>
            [mailto:aodvv2-discuss- ;<mailto:aodvv2-discuss->
            >> bounce@xxxxxxxxxxxxx <mailto:bounce@xxxxxxxxxxxxx>]
            On Behalf Of Charlie Perkins
            >> Sent: Wednesday, March 02, 2016 11:59 AM
            >> To: aodvv2-discuss@xxxxxxxxxxxxx
            <mailto: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: