Re: [manet] On Forwarding-and-regeneration

[Jiazi YI <[e-mail]>]

I think it will make the specification complex, and hard to extend.

What about if I need to define a new TLV field for my extension? The field
would either be unprotected, or the extension won't be interoperable with
old implementations.

Jiazi

On Thu, Apr 28, 2016 at 2:04 AM, Charlie Perkins <
[e-mail]> wrote:

> 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]>
> [e-mail]> wrote:
>
>> On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink <
>> <[e-mail]>[e-mail]> wrote:
>>
>>>
>>> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove <
>>> <[e-mail]>[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] (iPhone)
>>> [e-mail] (home)
>>>
>>>
>>>
>>> --
>>> Christopher Dearlove
>>> [e-mail] (iPhone)
>>> [e-mail] (home)
>>> On 27 Apr 2016, at 22:46, Lotte Steenbrink <
>>> <[e-mail]>[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]>[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]>[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] <%2B44%20%280%291245%20242194>  |  *E: *
>>> <[e-mail]>[e-mail]
>>>
>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>> Baddow, Chelmsford, Essex CM2 8HN.
>>> <http://www.baesystems.com/ai>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 [ <[e-mail]>mailto:[e-mail]
>>> <[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]>[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] <%2B44%20%280%291245%20242194>  |  E:
>>> <[e-mail]>[e-mail]
>>>
>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>> Baddow, Chelmsford, Essex CM2 8HN.
>>> <http://www.baesystems.com/ai>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]>
>>> [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]>[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] <%2B44%20%280%291245%20242194>  |  E:
>>> <[e-mail]>[e-mail]
>>> >
>>> > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>> Baddow, Chelmsford, Essex CM2 8HN.
>>> >  <http://www.baesystems.com/ai>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]>
>>> [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]>[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]>
>>> [e-mail]
>>> >>
>>> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>> Baddow, Chelmsford, Essex CM2 8HN.
>>> >>  <http://www.baesystems.com/ai>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]>[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]>
>>> [e-mail]>:
>>> >>>
>>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>> >>> < <[e-mail]>[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]>[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]>[e-mail]
>>> >  <https://www.ietf.org/mailman/listinfo/manet>
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>> _______________________________________________
>>> manet mailing list
>>> <[e-mail]>[e-mail]
>>> <https://www.ietf.org/mailman/listinfo/manet>
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>> _______________________________________________
>>> manet mailing list
>>> <[e-mail]>[e-mail]
>>> <https://www.ietf.org/mailman/listinfo/manet>
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>>
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>
>
> _______________________________________________
> manet mailing [e-mail]://www.ietf.org/mailman/listinfo/manet
>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>