Thanks Lotte, makes sense.
The homework (at least for me) is to take a look and see if that
explanation ties up with RFC7182 and 7183, or see if we are looking at
another 5444 missing API situation!
One day someone in the MANET team will have to write a draft on how all
the RFCs are supposed to hang together; perhaps one for the re-charter.
Regards
John
On 23/04/15 14:09, Lotte Steenbrink wrote:
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 allInteresting point! I'm on it.
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?
Regards,
Lotte
Thanks and Best Regards
John
