Re: [manet] On Forwarding-and-regeneration

[[e-mail]]

> On 03 May 2016, at 18:06, Charlie Perkins <[e-mail]> wrote:
> 
> Hello Jiazi,
> 
> Follow-up below...
> 
> On 4/28/2016 5:14 AM, Jiazi YI wrote:
>> 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.
> 
> RFC 7182 has the following language:
> 
>>   The rationale for removing any ICV Message TLVs already present prior
>>   to calculating the ICV is that several ICV TLVs may be added to the
>>   same message, e.g., using different ICV cryptographic and/or hash
>>   functions. 
> 
> So you could use another ICV for the new purpose, and handling for previous ICVs is already specified.
> 

That is not the point. The point is, that this e2e draft that you are proposing says “calculate ICV over these elements only” — and so when Jiazi develops a <FOO> extension that adds a <BAR> TLV to RREQs, that <BAR> TLV is not covered by the ICV.

Covering such TVLs with the ICV would require an “Updates e2esec” for each extension to be specified. Horrible source of non-interoperability.

> I don't think it's necessary to discourage mutable fields in reactive route discovery.  There have been many variations on AODV route discovery, and I can't think of any that didn't change the control messages as they were passed hop by hop from source to destination and back.


… but, none of those "variations on AODV route discovery” came with security …

Thomas