Re: [manet] On Forwarding-and-regeneration

[Charlie Perkins <[e-mail]>]

Hello Justin,

I think a new AODV-specific ICV is probably the right answer.  It would 
be nice to get some help generating the proper settings for all of the 
RFC 7182 fields to support this approach.  If not that, could we fall 
back on RFC 4868, which seems pretty straightforward?

Regards,
Charlie P.

On 4/27/2016 4:24 PM, Justin Dean wrote:
>
> An alternative solution to checking integrity. The current icv draft 
> is good at validating messages from an original source. OLSRV2 and 
> NHDP use this to good effect. AODVV2 doesn't because the messages are 
> regenerated; I belive this to be the correct term as the message 
> contains local information, path information, and originator 
> information. Getting the icv draft to work on forwarded packets is 
> ugly as they really are regenerated and should be. What we want to do 
> is secure the original source of information which is OrigAddr/target 
> address and sequence number. Why not just attach a new aodv specific 
> icv TLV which uses THAT info and nothing else? The current icv TLV 
> would/could still be used over the whole message hop by hop by each 
> router, as the messages are regenerated.
>
> Justin
>
>
> On Wed, Apr 27, 2016, 6:43 PM Jiazi YI <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>
>>         Am 28.04.2016 um 00:16 schrieb Christopher Dearlove
>>         <[e-mail]
>>         <mailto:[e-mail]>>:
>>
>>         The more you have to zero out, the messier it gets, and the
>>         less secure it gets (more things can be spoofed). I think
>>         that's about all I've got to add.
>>
>
>         Of course. My question was just:
>         * Do we want to come up with an exact description of how the
>         zeroing out should work now, with the short time we have left?
>
>
>     If a meaningful security mechanism is required, yes.
>     I think the first thing to do is to cut as many mutable fields and
>     optional fields as possible.
>
>     best
>
>     Jiazi
>
>         or
>         * Do we mention in the draft that zeroing out has to happen
>         somehow and leave the nitty gritty to future work?
>
>         At least that’s how I understood the options you laid out...
>
>>         -- 
>>         Christopher Dearlove
>>         [e-mail]
>>         <mailto:[e-mail]> (iPhone)
>>         [e-mail]
>>         <mailto:[e-mail]> (home)
>>
>>
>>
>>         -- 
>>         Christopher Dearlove
>>         [e-mail]
>>         <mailto:[e-mail]> (iPhone)
>>         [e-mail]
>>         <mailto:[e-mail]> (home)
>>         On 27 Apr 2016, at 22:46, Lotte Steenbrink
>>         <[e-mail]
>>         <mailto:[e-mail]>> wrote:
>>
>>>         Hi all,
>>>         I’m currently revising the security considerations with
>>>         regards to the move from regeneration to forwarding, which
>>>         depends on a decision being made on how/where we want to
>>>         mention the possibility of zeroing out TLVs to calculate the
>>>         ICV for the rest of a message’s contents (see second * of my
>>>         last e-mail). I’ve not found a decision on this in other
>>>         thread (please pardon me if I overlooked something), so I’ll
>>>         bump this thread and ask the WG for its opinions. (again,
>>>         personally, the 2nd option outlined by Christopher seems
>>>         more appealing to me)
>>>
>>>         Regards,
>>>         Lotte
>>>
>>>>         Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink
>>>>         <[e-mail]
>>>>         <mailto:[e-mail]>>:
>>>>
>>>>         Hi all,
>>>>         to summarize:
>>>>
>>>>         * AODVv2 message Type numbers should be in the Experimental
>>>>         type space and the AODVv2 TLV Types should be message
>>>>         type-specific. This also means changing the text regarding
>>>>         IANA actions and changing the text regarding what the
>>>>         experiment is to something along the lines of “we want to
>>>>         gather experience on how to make generic metric TLVs and
>>>>         ICVs that work with changing metric TV values happen with
>>>>         reactive protocols”
>>>>         * we’re undecided on (to quote Christopher) the "here's a
>>>>         mechanism we haven't really thought through in detail, but
>>>>         at least we've defined one", or "we know the sort of thing
>>>>         we want, and we'll describe it, but rather than produce
>>>>         something not quite right, we'll not go further“ decision
>>>>         on temporarily setting the metric value to 0 (i.e. the who
>>>>         and how). (personally, I think I’d prefer the latter
>>>>         approach, but that’s an entirely gut feeling-based preference)
>>>>
>>>>         Did I catch that correctly? If so, I’ll put together and
>>>>         suggest some text for the first point as soon as I get home
>>>>         and in case there has been a decision on the second by
>>>>         then, I’ll try to tackle that one too. :)
>>>>
>>>>         Best regards, Lotte
>>>>
>>>>>         Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK)
>>>>>         <[e-mail]
>>>>>         <mailto:[e-mail]>>:
>>>>>
>>>>>         I have no problem with that. I was trying to lay out the
>>>>>         issues without muddying the water with my preference.
>>>>>
>>>>>         *--*
>>>>>
>>>>>         *Christopher Dearlove
>>>>>         Senior Principal Engineer
>>>>>         BAE Systems Applied Intelligence Laboratories
>>>>>         **__________________________________________________________________________
>>>>>         *
>>>>>         *T*: [phone] <tel:%2B44%20%280%291245%20242194>
>>>>>          | *E:*[e-mail]
>>>>>         <mailto:[e-mail]>
>>>>>
>>>>>         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:*Justin Dean [mailto:[e-mail]]
>>>>>         *Sent:*22 April 2016 15:35
>>>>>         *To:*Dearlove, Christopher (UK)
>>>>>         *Cc:*Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>>>>>         *Subject:*Re: [manet] On Forwarding-and-regeneration (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, clickhere
>>>>>         <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.//
>>>>>         /If you feel the email is suspicious, please followthis
>>>>>         process
>>>>>         <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.//
>>>>>
>>>>>         Speaking as participant.
>>>>>
>>>>>         I kind of like the idea of using the experimental message
>>>>>         type space.  We only have a limited amount of these
>>>>>         message types.  The TLV assignments could just use the
>>>>>         message type specific space and there isn't an issue
>>>>>         there. IANA wouldn't assign a number but I don't see why
>>>>>         the document couldn't specify the experimental numbers it
>>>>>         was going to use so other future near term experiential
>>>>>         protocols could do the same and generally avoid conflict. 
>>>>>         If the experiment is successful IANA assignments could be
>>>>>         made. Functionally no real difference with protections vs
>>>>>         long term usage of limited space.
>>>>>         Justin
>>>>>         On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher
>>>>>         (UK) <[e-mail]
>>>>>         <mailto:[e-mail]>> wrote:
>>>>>         There's rather a contradiction between the concepts of a
>>>>>         definition of a protocol, even Experimental, and
>>>>>         experimental space, which usually assumes that the user
>>>>>         can do what he or she likes in it.
>>>>>
>>>>>         But chewing up messages types (how many, 3?) of which
>>>>>         there are relatively few for experimental is long term a
>>>>>         problem, although short term not.
>>>>>
>>>>>         TLV space is easier in two regards. It's bigger (though
>>>>>         the prime real estate of type extension zero isn't) and
>>>>>         can have message type specific TLVs.
>>>>>
>>>>>         So TLVS can actually be invisible, if that option is
>>>>>         chosen. For messages something has to give. Least bad
>>>>>         option is again one of those we should discuss, but time ...
>>>>>
>>>>>         (To be precise, messages types from 224 are defined in RFC
>>>>>         5444 as " Experimental Use", of which BCP 26 says "Similar
>>>>>         to private or local use only, with the  purpose being to
>>>>>         facilitate experimentation." The alternative 0-223 space
>>>>>         is Expert Review. IANA still thinks the experts are Joe
>>>>>         Macker and the recused Stan Ratliff. But that's a soluble
>>>>>         nit.)
>>>>>
>>>>>         --
>>>>>         Christopher Dearlove
>>>>>         Senior Principal Engineer
>>>>>         BAE Systems Applied Intelligence Laboratories
>>>>>         __________________________________________________________________________
>>>>>
>>>>>         T: [phone] <tel:%2B44%20%280%291245%20242194> |
>>>>>          E:[e-mail]
>>>>>         <mailto:[e-mail]>
>>>>>
>>>>>         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
>>>>>
>>>>>
>>>>>         -----Original Message-----
>>>>>         From: Thomas Heide Clausen [mailto:[e-mail]
>>>>>         <mailto:[e-mail]>]
>>>>>         Sent: 22 April 2016 14:21
>>>>>         To: Dearlove, Christopher (UK)
>>>>>         Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>>>         Subject: Re: [manet] On Forwarding-and-regeneration (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 from the internet.
>>>>>         Consider carefully whether you should click on any links,
>>>>>         open any attachments or reply.
>>>>>         Follow the 'Report Suspicious Emails' link on IT matters
>>>>>         for instructions on reporting suspicious email messages.
>>>>>         --------------------------------------------------------
>>>>>
>>>>>
>>>>>         > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK)
>>>>>         <[e-mail]
>>>>>         <mailto:[e-mail]>> wrote:
>>>>>         >
>>>>>         > Once you're entirely in AODV2's own space, and AODVv2 is
>>>>>         experimental (working assumption for this discussion) you
>>>>>         have more liberty.
>>>>>         >
>>>>>
>>>>>         Yep.
>>>>>
>>>>>         Taken somewhat by surprise both by the sudden "rush" and
>>>>>         the experimental maturity level, I am wondering (and
>>>>>         haven't thought through) about experimental space vs
>>>>>         non-experimental (for message types, and consequently for
>>>>>         message type specific TLV types).
>>>>>
>>>>>         I think that if the AODVv2 experiment specifies the use of
>>>>>         Message types from the Experimental message type space
>>>>>         without making actual registrations in the IANA registry,
>>>>>         AND the use of type specific TLV types, this becomes a
>>>>>         non-issue entirely (by design, this is precisely what that
>>>>>         experimental space is for)
>>>>>
>>>>>         Whereas, as you point out, the alternative is a "can open
>>>>>         - worms everywhere" situation that I think time is too
>>>>>         short to solve?
>>>>>
>>>>>         Thomas
>>>>>
>>>>>
>>>>>         > Then you could try specifying it. But with a very good
>>>>>         chance of producing something you later decide you should
>>>>>         have done differently.
>>>>>         >
>>>>>         > I honestly don't know which would go down better (or
>>>>>         less badly) - "here's a mechanism we haven't really
>>>>>         thought through in detail, but at least we've defined
>>>>>         one", or "we know the sort of thing we want, and we'll
>>>>>         describe it, but rather than produce something not quite
>>>>>         right, we'll not go further".
>>>>>         >
>>>>>         > --
>>>>>         > Christopher Dearlove
>>>>>         > Senior Principal Engineer
>>>>>         > BAE Systems Applied Intelligence Laboratories
>>>>>         >
>>>>>         __________________________________________________________________________
>>>>>         >
>>>>>         > T: [phone] <tel:%2B44%20%280%291245%20242194>
>>>>>         |  E:[e-mail]
>>>>>         <mailto:[e-mail]>
>>>>>         >
>>>>>         > 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
>>>>>         >
>>>>>         >
>>>>>         > -----Original Message-----
>>>>>         > From: Lotte Steenbrink
>>>>>         [mailto:[e-mail]
>>>>>         <mailto:[e-mail]>]
>>>>>         > Sent: 22 April 2016 13:59
>>>>>         > To: Mobile Ad Hoc Networks mailing list
>>>>>         > Cc: Henning Rogge; Dearlove, Christopher (UK)
>>>>>         > Subject: Re: [manet] On Forwarding-and-regeneration
>>>>>         (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 from the internet.
>>>>>         > Consider carefully whether you should click on any
>>>>>         links, open any attachments or reply.
>>>>>         > Follow the 'Report Suspicious Emails' link on IT matters
>>>>>         for instructions on reporting suspicious email messages.
>>>>>         > --------------------------------------------------------
>>>>>         >
>>>>>         > Hello Christopher,
>>>>>         >
>>>>>         >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher
>>>>>         (UK) <[e-mail]
>>>>>         <mailto:[e-mail]>>:
>>>>>         >>
>>>>>         >> Just be careful to note that this concept is as
>>>>>         currently being discussed (a) specific to AODVv2, and (b)
>>>>>         not an application of 7182, which has no knowledge of
>>>>>         special TLVs.
>>>>>         >>
>>>>>         >> This is something we'd want to get right, and need to
>>>>>         get right if in any space not specific to ADODVv2, because
>>>>>         getting it wrong produces future problems.
>>>>>         >
>>>>>         > Makes sense.
>>>>>         >
>>>>>         >> I can see some possible approaches, none is ideal and
>>>>>         we're rather out
>>>>>         >> of time to specify. But this is experimental, so I
>>>>>         think we might be
>>>>>         >> able to indicate the shape of the solution without
>>>>>         specifying it,
>>>>>         >> which would be a different RFC, under a bit less time
>>>>>         pressure.
>>>>>         >> (Extensions to existing protocols like 7182 would
>>>>>         naturally be in
>>>>>         >> scope rechartered I think.)
>>>>>         >>
>>>>>         >> To indicate the range that's open, here are two
>>>>>         possible ideas, one of which has an impact now, so needs
>>>>>         to be agreed. Note that I'm not suggesting (in fact quite
>>>>>         the opposite) defining an extension to 7182 here, rather
>>>>>         enabling such an extension, if written, to "do the right
>>>>>         thing".
>>>>>         >> - We have an extension to 7182 that says "zero out all
>>>>>         value octets in protocol specific TLVs. That requires now
>>>>>         putting the AODVv2 metric TLV in that space.
>>>>>         >
>>>>>         > Just to make sure that I understood you correctly– “that
>>>>>         space” meaning making the AODVv2 metric TLV protocol
>>>>>         specific? (By “the aodvv2 metric tlv” I’m referring to the
>>>>>         generic TLV we’ve been talking about on this list earlier
>>>>>         this week).
>>>>>         >
>>>>>         >> - We have an extension to 7182 that adds extra material
>>>>>         to the value field that indicates (TBD how, by position
>>>>>         with sanity check that this is TLV value perhaps?) which
>>>>>         octets are to be zeroed out before the ICV is calculated.
>>>>>         >
>>>>>         > The way I understand that approach, it wouldn’t warrant
>>>>>         any action from AODVv2 besides saying “if you calculate
>>>>>         the ICV, set the Metric value to zero” (leaving the nitty
>>>>>         gritty of how this would be done in detail to future
>>>>>         work)… Is that correct?
>>>>>         >
>>>>>         >>
>>>>>         >> We do not have the time to specify this in an
>>>>>         acceptable manner within two weeks though. But the
>>>>>         security consideration section could say something along
>>>>>         the lines of "this enables the use of an ICV defined to
>>>>>         zero out these octets“.
>>>>>         >
>>>>>         > Okay. :)
>>>>>         >
>>>>>         > Best regards,
>>>>>         > Lotte
>>>>>         >
>>>>>         >>
>>>>>         >> --
>>>>>         >> Christopher Dearlove
>>>>>         >> Senior Principal Engineer
>>>>>         >> BAE Systems Applied Intelligence Laboratories
>>>>>         >>
>>>>>         ______________________________________________________________________
>>>>>         >> ____
>>>>>         >>
>>>>>         >> T: [phone]
>>>>>         <tel:%2B44%20%280%291245%20242194>  | 
>>>>>         E:[e-mail]
>>>>>         <mailto:[e-mail]>
>>>>>         >>
>>>>>         >> 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
>>>>>         >>
>>>>>         >> -----Original Message-----
>>>>>         >> From: manet [mailto:[e-mail]
>>>>>         <mailto:[e-mail]>] On Behalf Of Lotte
>>>>>         >> Steenbrink
>>>>>         >> Sent: 22 April 2016 10:28
>>>>>         >> To: Henning Rogge
>>>>>         >> Cc: Mobile Ad Hoc Networks mailing list
>>>>>         >> Subject: Re: [manet] On Forwarding-and-regeneration
>>>>>         (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 from the internet.
>>>>>         >> Consider carefully whether you should click on any
>>>>>         links, open any attachments or reply.
>>>>>         >> Follow the 'Report Suspicious Emails' link on IT
>>>>>         matters for instructions on reporting suspicious email
>>>>>         messages.
>>>>>         >> --------------------------------------------------------
>>>>>         >>
>>>>>         >> *** WARNING ***
>>>>>         >> EXTERNAL EMAIL -- This message originates from outside
>>>>>         our organization.
>>>>>         >>
>>>>>         >>
>>>>>         >> Hi Henning,
>>>>>         >>
>>>>>         >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge
>>>>>         <[e-mail] <mailto:[e-mail]>>:
>>>>>         >>>
>>>>>         >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>>>>         >>> <[e-mail]
>>>>>         <mailto:[e-mail]>> wrote:
>>>>>         >>>> Hi Thomas,
>>>>>         >>>> Can it?! Iirc, the reason why we adopted the
>>>>>         “regeneration” language
>>>>>         >>>> in the first place is that we’ve been told that
>>>>>         whenever one bit in
>>>>>         >>>> the message (apart from its header) is changed, the
>>>>>         entire thing has to be regenerated.
>>>>>         >>>> I’m starting to get the feeling we’ve just been
>>>>>         misunderstanding
>>>>>         >>>> each other for more than a year. :( Anyway, it seems
>>>>>         like we’re
>>>>>         >>>> getting close now, so yay.
>>>>>         >>>
>>>>>         >>> "Modifying" the binary message instead of parsing and
>>>>>         generating a
>>>>>         >>> new one will be difficult as soon someone writes an
>>>>>         extension to
>>>>>         >>> AODVv2 that adds more TLVs to the message.
>>>>>         >>
>>>>>         >> D’oh, right. Yeah, if I remember it correctly, that’s
>>>>>         what you explained to me when I got confused about the
>>>>>         topic last spring… But– even if a message contains TLVs
>>>>>         that the AODVv2 implementation handling it doesn’t
>>>>>         understand, it will still be able to recognize the Metric
>>>>>         TLV, right? Isn’t that the nifty thing about RFC5444? So,
>>>>>         while we really shouldn’t write “before calculating the
>>>>>         ICV, set the n-th 4 octets to 0”, we might say “identify
>>>>>         the octets that make up the metric value and set those to 0”?
>>>>>         >>
>>>>>         >> Best regards,
>>>>>         >> Lotte
>>>>>         >>
>>>>>         >>> Henning Rogge
>>>>>         >>
>>>>>         >> _______________________________________________
>>>>>         >> manet mailing list
>>>>>         >>[e-mail] <mailto:[e-mail]>
>>>>>         >>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
>>>>>         >[e-mail] <mailto:[e-mail]>
>>>>>         >https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>>         _______________________________________________
>>>>>         manet mailing list
>>>>>         [e-mail] <mailto:[e-mail]>
>>>>>         https://www.ietf.org/mailman/listinfo/manet
>>>>>         _______________________________________________
>>>>>         manet mailing list
>>>>>         [e-mail] <mailto:[e-mail]>
>>>>>         https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>         _______________________________________________
>>>>         manet mailing list
>>>>         [e-mail] <mailto:[e-mail]>
>>>>         https://www.ietf.org/mailman/listinfo/manet
>>>
>>>         _______________________________________________
>>>         manet mailing list
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/manet
>
>
>         _______________________________________________
>         manet mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/manet
>
>     _______________________________________________
>     manet mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/manet
>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet