Re: [manet] New AODVv2 draft and status

> On 21 Apr 2016, at 23:21, Charlie Perkins <charles.perkins@earthlink.net> wrote:
> 
> Hello Jiazi,
> 
> Follow-up below...  notably I probably should not be doing email today since I am ill,

First: take care of yourself, and do get well!

> but nevertheless you certainly deserve answers...
> 
>> On 4/21/2016 1:38 PM, Jiazi YI wrote:
>> Hi, 
>> 
>> 
>> On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins <charles.perkins@earthlink.net> wrote:
>>> <snip>
>>> 
>>> Regarding security: if AODVv2 were to solve all the possible security exposures of ad hoc networks, it would be historic and worthy of publication -- probably would win paper of the year. Needless to say, that was never part of the charter.
>> 
>> 
>> But security and its consideration are part of every specification.
> 
> And also part of AODVv2 specification.
> 

For having relatively recently seen an I-D through to RFC, as I have stated multiple times, the requirements for the security considerations have evolved considerably, since what you may be familiar with, or what you have been reading in the past.

> 
>> 
>> As one who co-authored several vulnerability analysis drafts/RFCs (ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what we always do for a protocol is:
>> 
>>   - assuming that we have a compromised router in the network, what can it do to break the network? What's the consequences? What about if there are several of them?
>> 
>>   - what about if there are mis-configured routers or wrong-implemented routers?
>> 
>>   - what kind of threats can be mitigated by existed security measurements (like RFC 7182/7183)? 
>> 
>>   - what kind of future work can be done to make the protocol more secure?
> 
> We have tried to do exactly these things, except for the last one.  I have read a lot of Security Considerations sections,

I repeat, for having relatively recently seen an I-D through to RFC, as I have stated multiple times, the requirements for the security considerations have evolved considerably, since what you may be familiar with, or what you have been reading in the past.

> and that last one is by no means universally included.
> 
>> 
>> With the current AODVv2 specification, if I was to produce a aodvv2-sec-threats draft, it would be much simpler: 
>> 
>>    - one single compromised router can easily jam the whole network (RREQ flooding), or even bring down the whole network (remember the multicast RERR?) because of the transit-trust model used. 
>> 
>>   - with my limited knowledge, as future work, there is no easy way to protect the message because of the reconstructed and length-varied message regenerated in every hop.
> 
> Well, I am somewhat happy to see that you are agreeing with me.  I did produce an e2e draft that has some protections, and asked for comments, and offered it as an adjunct to the current draft.

As I have also pointed out repeatedly, the e2e draft that you propose inhibits extensibility-without-also-updating-the-e2e-draft - I.e., each possible future extension requires also respinning / updating / replacing that draft. And, as it would be, I am not actually sure that the e2e draft suffices, even without considering extensions, given the things that can happen in a "regeneration of a message". Either way, even *if* the e2e draft was a solution, experience shows that it would have to advance in parallel with the protocol specification, and not as "a promised afterthought". The SEC-ADs won't have the latter.

As I have also pointed out repeatedly, the solution to this problem is to do away with "message regeneration". I have described *how* as well as the security model that would go with that, in several  emails in the past -- emails which so far have not been considered by the authors..

>> Even *if* security was acceptable as future work (it is not, but as a thought experiment, let's assume), there is no easy way to protect the message because of the reconstructed and length-varied message regenerated in every hop.
> 
> This is not true.  As is usual in such cases, one has to identify the parts that may modified as the packet goes from source to destination, and provide some way to verify the authenticity of those fields.
> 

Which is greatly simplified if doing away with both the regeneration and the e2e- Draft, as previously proposed, and repeatedly.

>> Securing a reactive protocol requires different considerations than does securing a proactive protocol, but there has been work done in this area, and other WG participants have raised both their concerns, and suggestions to security architectures, and protocol architectures (better) able to accommodate security, a long time ago. I don't see those works, nor the suggestions and comments made, reflected or considered in revision -15 of the draft. Especially, the current design based on message regeneration makes the future extension to the security very hard, as has been reiterated repeatedly.
>> 
>> Abdussalam doesn't agree with me on my observation on "Lack of response from the author team on the comments. " -- this is an example. 
> 
> If we missed some things, please be more specific. 

Done, for this subject, above. 

> But it is factually incorrect to suggest that we have not been responsive to the comments. 

No, that is factually accurate.

Several comments have been made, by myself and others, including proposals for how to address security, as indicated in the above,  which (demonstrably, least security would have been resolved) have not been addressed.

Thomas

> I have personally rewritten large parts of the Security Considerations twice in response, as well as offered a lot of text during the time when other co-authors have held the editorial pen.
> 
> Please excuse if I must delay further comment.
> 
> Regards,
> Charlie P.
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet