Re: [manet] New AODVv2 draft and status

[Jiazi YI <[e-mail]>]

And by simply searching the archive, I would like to point out that those
comments are nothing new.

In the comments from Thomas in 2010 (6 years ago), the issue has been
brought out in
http://www.ietf.org/mail-archive/web/manet/current/msg11858.html , I quote:


<DYMO>   In situations where routing information or router identity are
   suspect, integrity and authentication techniques SHOULD be applied to
   DYMO messages.  In these situations, routing information that is
   distributed over multiple hops SHOULD also verify the integrity and
   identity of information based on originator of the routing
   information.

<TC> This is really difficult to do, in case messages are mutable
in-transit, which appears to be the case for RERR and RM's; i.e. for all
DYMO messages. For that reason, using SHOULD is - imo - dangerous here.
Also, for that reason, I think that this issue of mutable messages deserves
being called out explicitly in this section, especially if there are known
or recommended ways of handling this (as is the case, for example, in the
security considerations section of RFC5444 regarding the mutable header
fields for hop-count/hop-limit of messages.

Then related comments were repeated again and again. Isn't enough to bring
the attention of the authors? In fact, the situation get even worse by
changing the strategy to regenerating messages.

best

Jiazi

On Thu, Apr 21, 2016 at 10:38 PM, Jiazi YI <[e-mail]> wrote:

> 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
>>
>
>