Re: [manet] New AODVv2 draft and status

[Jiazi YI <[e-mail]>]

Hi,


On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins <
[e-mail]> 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.

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?

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.


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.

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.

regards

Jiazi

btw, I would like to confirm with the WG chair: the WGLC is from April 20th
to May 4th, right?



>
> Regards,
> Charlie P.
>
>
>
> On 4/21/2016 11:24 AM, John Dowdell wrote:
>
>> All
>>
>> I believe we’re going about this the wrong way, and we’re setting
>> ourselves an impossible target at which we are bound to fail.
>>
>> BCP 9, governing the Internet Standards process, section 4.1.1 deals with
>> the first level of maturity, termed Proposed Standard. To paraphrase, a
>> Proposed Standard is supposed to be as correct as we can make it, but there
>> is no requirement to have made an implementation. Since no engineer has
>> ever written a fully correct specification before cutting metal, it may be
>> expected that there are some areas which will need attention later on, at
>> Draft Standard if we ever wanted to go that far. I’ll say now that one area
>> in AODVv2 will need some work later, that of hop-by-hop security in an ad
>> hoc network. This is because nobody has really cracked that problem yet;
>> some real bright people are grappling with that right now over in DTN. The
>> work in our own group on Identity Based Signatures will help but there is
>> still ground to cover. However the actual level of security is not for
>> AODVv2 to mandate, it is for the implementor and system integrator, based
>> on an assessment of the likely risk and the thickness of their wallet.
>>
>> It is clear to me that few will make an independent implementation
>> without the RFC stamp. This much is obvious in modems fitted with DLEP;
>> there are just four such implementations I know of, and two of those were
>> written with the encouragement of author team members, but I know of many
>> more who are just waiting for the dust to settle so they can make the
>> business case to proceed. Allow AODVv2 to get to RFC and we’ll encourage
>> others to use it and get some feedback.
>>
>> Regards
>> John
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>