Subject: Re: [manet] On Forwarding-and-regeneration

From: Charlie Perkins <[email-masked]>
Date: Tue, 3 May 2016 09:06:37 -0700

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.

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.

Regards,
Charlie P.

---

From: [email-masked]
Date: Tue, 3 May 2016 18:17:10 +0200

> On 03 May 2016, at 18:06, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Jiazi,
> 
> Follow-up below...
> 
>> 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.
> 
> 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