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

[Jiazi YI <[e-mail]>]

On Thu, Apr 28, 2016 at 7:08 PM, Justin Dean <[e-mail]> wrote:

>
>
> On Thu, Apr 28, 2016 at 12:55 PM, Victoria Mercieca <[e-mail]>
> wrote:
>
>> Hi Jiazi,
>>
>> Thanks for your response. So you think we could change back to sending
>> RREP by unicast (letting an implementation handle whether this requires a
>> route to the neighbor to be installed temporarily)? We would have to also
>> send a separate message to request an acknowledgement, but this could also
>> be unicast and could therefore potentially be sent in the same RFC5444
>> packet.
>>
>> Anyone have any objections?
>>
>
> I don't think it's a good idea to "temporarily" add a route that is not
> known to be bi-directional yet.  The timing of correctly adding and
> removing the route with different mediums and restricting the route to only
> that one packet doesn't seem like a workable solution.    Sending it
> unicast with a raw type socket or pcap out of a known interface sure.  IMO
> a route shouldn't be added until the link is confirmed bi-directional.
>

The point that I want to make is, it's possible to send unicast RREP even
without a route being set -- let the implementor decide which is the best
way.
Regarding the information of requesting RREP-ACK: it can be a flag (which
is much easier to secure than a optional address field), or another RFC5444
message.
Someone probably doesn't like such flags (because it must be zeroed when
calculating ICV), but I don't have strong opinion on that.

Jiazi


>
> Justin
>
>