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

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 3 Mar 2016 08:13:00 -0800

Hello folks,

Where I work, it's easier for people to understand the value of contributing an Internet Draft, compared to the value of contributing to a mailing list. So I'll make an Internet Draft and explain on the mailing list where it would fit in the current AODVv2 draft if inclusion is desired.

Regards,
Charlie P.


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

Hi Charlie,

I think this just needs to go straight to MANET, and if they approve, or make suggestions etc, then when we reach consensus on it, we can incorporate it. It needs their opinion soon though. I'm happy for you to email straight to MANET to get discussion going.

Regards,
Vicky.

On Thu, Mar 3, 2016 at 3:49 PM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:

    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: