Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

[Lotte Steenbrink <[e-mail]>]

> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove <[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?
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]  |  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] <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, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
>>>> If you feel the email is suspicious, please follow this 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]  |  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 <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 <https://www.ietf.org/mailman/listinfo/manet>
>>>> 
>>>> _______________________________________________
>>>> manet mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>>>>  
>>>> _______________________________________________
>>>> manet mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>> 
>> _______________________________________________
>> manet mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>