[aodvv2-discuss] Re: ICV and RFC5444 processing

  • From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 23 Apr 2015 15:09:35 +0200

Hi again,
so here is Hennings answer:

---------------------------------------------------------------------------------------------------------
the calculation and integration of the ICV TLV must be done after the
bytestream of a message (or packet) is done. Which means it should be
part of the message/packet generator (and be checked by the
message/packet parser).

My idea how to implement it would be

1) allow users to register a "ICV callback" which can calculate the ICV
for a binary data array

2) add a function that marks a message or packet as "add ICV type X".

3) generator will call the ICV callback after assembling the
message/packet, then add the ICV TLV for you

Parser would be similar

1) allow users to register a "ICV callback" which can calculate the ICV
for a binary data array

2) parser detects ICV TLVs and calls up the ICV callbacks with the
modified binary

3) parser supplies users with a boolean array that says which registered
ICV was present and which was valid/invalid.

Henning Rogge
---------------------------------------------------------------------------------------------------------

FWIW, Henning said his API doesn't implement this at the moment, but he's
planning to add the functionality.

Regards,
Lotte

Am 23.04.2015 um 12:00 schrieb Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>:

Hi John,

Am 23.04.2015 um 11:48 schrieb John Dowdell <john.dowdell486@xxxxxxxxx>:

Hi all

Further to the last hangout, during which we discussed RFC7182/7183 being
applied to AODVv2 messages. It struck me that while we can apply an
Integrity Check Vector (ICV) to a AODVv2 message, the 5444 parser will set
about compressing, rearranging and generally optimising the content. It
therefore strikes me (following a similar discussion on DTN) that the 5444
parser at the far end must losslessly (and in the reverse order) undo all
its optimisations for the ICV to correctly compute, otherwise an error will
occur and the far end router may choose to reject the message, fearing
corruption or a Man In The Middle attack.

I was thinking about writing to Chris D to ask about how OLSRv2 works around
this, when it struck me that Henning would probably know and Lotte has him
in the loop just now.

So Lotte, please would you ask Henning what his thoughts are on this please?


Interesting point! I'm on it.

Regards,
Lotte

Thanks and Best Regards
John


Other related posts: