Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

[Justin Dean <[e-mail]>]

On Mon, Apr 25, 2016 at 10:37 AM, Thomas Heide Clausen <
[e-mail]> wrote:

>
>
> On 25 avr. 2016, at 16:32, Justin Dean <[e-mail]> wrote:
>
>
>
> On Mon, Apr 25, 2016 at 10:28 AM, <[e-mail]> wrote:
>
>>
>> On 25 Apr 2016, at 16:20, Justin Dean <[e-mail]> wrote:
>>
>> A thought regarding integrity checking.  A possible future "fix" for
>> integrity could be done on a "virtual" packet in which known TLVs/values
>> along with ordered addresses are uncompressed and then verified.  It could
>> allow extra TLV tagging without modifying the validity of that data.  The
>> very big drawback would be the overhead of having to uncompressed
>> everything to check the validity.  It's functionally the same as zeroing
>> out local (this is my stuff) TLV data vs remote (this is not my stuff) TLV
>> data.
>>
>>
>> That requires an imposed ordering of addresses, address TLVs, Message
>> TLVs, etc., even if only “in memory”, it is something that everybody should
>> be aware of, and doing the same way
>>
>> o That ordering would have to be specified in this document (no, it
>> would not be a “future fix”, this is
>> a requirement to the base spec, since *not* doing that would mean that
>> this “future fix” could render
>> current implementations non-compliant!)
>>
>> If you're building the virutal packet you could specify the order there,
> the on the wire packet doesn't need to be in that order.
>
>
>
> No idea what a virtual packet is.
>
> But imposing a point of universal agreement on how *any* packet - now or
> in the future - uncompresses  is not a trivial task.
>
>
o While this would be *hard* for the current messages/TLVs, I’d imagine
>> that it’d make extensions
>> impossible (in an interoperable fashion).
>>
>> Not at all if the integrity check in question only used well known
> registred TLVs (i.e. don't change the value of these!) types for building
> the virutal packet then you could add whatever other TLV info you wanted.
>
>
> If I understand you correctly, then you would do the ICV only over some of
> the packet content? In other words, any extensions would be unprotected, OR
> would require an update to whatever records the "known TLVs" list?
>

Correct extensions which didn't register wouldn't be protected.  It's
essentially the same as zeroing out unknown TLVs so lets go with that as
it's easier.

Those extensions in the case of AODVv2 are fundamentally different than
OLSRv2/NHDP messages as they do not contain information about the
originating router.  I get that this is an issue with current integrity
checking methods but there is value in having that data included in the
same message.  Local only information could be sent in another message
which would be locally signed.  That would work for AckReq messages but it
wouldn't work for information about the "path" traveled as there would be
no way of verifying or even associating that information with the data
contained in the original message.

Justin

>
>
That to me is a showstopper, similar to M. Perkins' E2E draft, to be
> designing an extensible protocol specifically so that extensions are
> "unsecured". We can and must. do better than that.
>
>
>
>> o It’d be *exceptionally* heavy for all intermediate routers, wanting to
>> verify the integrity of a
>> message: to be able to force everybody in a network to “unwrap” the
>> message into an
>> uncompressed form *before* validating its origins is opening up for DoS
>> attacks.
>>
>> I want to do a *minimum* number of operations with a message, *before*
>> deciding
>> to discard a message as harmful.
>>
>> This is true enough it'd be hell on processing.
>
>
> Indeed. There are many reasons why this is a bad idea.
>
> Thomas.
>
>