Re: [manet] New AODVv2 draft and status

[Lotte Steenbrink <[e-mail]>]

Hi Jiazi, hi everyone,

> Am 21.04.2016 um 23:00 schrieb 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 <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. 
> 

The strategy has never been changed, at least not in the past 2-3 years I’ve been watching AODVv2. We’ve just been talking past each other for a really long time. The discussion has just now finally taken a direction where all parties are on the same page, which is really unfortunate timing. For the sake of completeness, I’d also like to point out that we’ve brought up the topic of regeneration issues in September [1] and November [2] 2015, where we’ve explained why we use the word “regeneration”. That would’ve been a great place to resolve the miscommunication that’s apparently been happening. 
I get that we all have day jobs and lives and that E-Mails get lost, but to be pinned as the sole source of delay in this case when we were waiting for (and really curious about) the WG’s input is starting to get insulting.

Anyway, the regeneration discussion is now *finally* on the right path, so let’s get to it.

Best,
Lotte

[1] https://www.ietf.org/mail-archive/web/manet/current/msg18055.html <https://www.ietf.org/mail-archive/web/manet/current/msg18055.html>
[2] https://www.ietf.org/mail-archive/web/manet/current/msg18167.html <https://www.ietf.org/mail-archive/web/manet/current/msg18639.html>
> best
> 
> Jiazi
> 
> On Thu, Apr 21, 2016 at 10:38 PM, Jiazi YI <[e-mail] <mailto:[e-mail]>> wrote:
> Hi, 
> 
> 
> On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins <[e-mail] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> 
> 
> _______________________________________________
> manet mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> 
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet