Re: [manet] draft-perkins-manet-aodv-e2esec-00

Requiring a signature based approach is I think quite undesirable. That puts a serious key management load on what is an ad hoc network, some of which are intended to be lightweight.

Where are the certificates coming from? Note that you can't simply download them, until the routing protocol has done its job, you don't have any way to do that. Pre-loaded? But that's getting really into scalability issues if you have to preload certificates for anyone who might be in the network. I think it's actually particularly bad for an on-demand protocol.

It also precludes what may be better solutions in many cases, for example draft-ietf-manet-ibs. (How do you get those keys? Also an issue, but a scalable one, you only need your own information, so preloading for example may be practical.)

Of course I'm not saying this might not be a solution, just not the one and only solution, and not to exclude all others. If you do have to put key management in (and it's hard to talk the SEC ADs out of that, but it can be done) add many more months to your time to finish.

This also doesn't address the key issue of the end to end or hop by hop architecture. I have some comments to make on that - comments that recognise there's a real issue that there is no ideal solution to - but I want to formulate them more clearly.

--  
Christopher Dearlove
christopher.dearlove@gmail.com

> On 5 Mar 2016, at 11:59, Anders Nilsson Plymoth <lanilsson@gmail.com> wrote:
> 
> Hi Charlie,
> 
> I understand you are mainly addressing E2E protection here, with regards to RREQ and RREP, but I am of the strong opinion that AODVv2 should have a more integrated security model, rather than ad hoc.
>  
> The use of HMACs for message authentication is a well known and well used approach. However, the use of HMAC implies the use of symmetric keys, and the question is how this key distribution should take place. I have seen hints of the usage of a single shared key, but this seems a little naive to me.
> 
> I would instead argue for a signature based approach, i.e. the use of public keys and certificates. This is the approach that was proposed for the SAODV draft, and although that draft is clearly outdated, I think the general idea there is good.
> 
> Regarding RFC 7182 instead of RFC 4868? Yes, definitely. You already rely on RFC 7182 for the security considerations of the AODVv2 draft. However, in the AODVv2 draft you mainly consider integrity protection, and less that of authentication. Also, this draft, draft-perkins-manet-aodv-e2esec-00 seems to address integrity more than authentication.
> 
> In summary, what I personally would like to see is a stronger integration of RFC 7182 and its concepts into the AODVv2 protocol specification, that also addresses authentication and key management considerations. As it is, it would be very hard to read the AODVv2 and its security considerations and build an implementation that incorporates RFC 7182, and have different implementations inter-operable. 
> 
> Thanks,
> Anders
> 
> 
> 
> 
> 
>> On Thu, Mar 3, 2016 at 11:24 PM, Charlie Perkins <charles.perkins@earthlink.net> wrote:
>> 
>> Hello folks,
>> 
>> In order to promote useful discussion about the security model for AODVv2, I have submitted a new draft with an idea to enable the source and destination of a Route Discovery to verify that they were indeed the source and destination of the route that was discovered. This is not a guarantee of a useful route, because intermediate routers are not authenticated, only the endpoints.  Nevertheless the idea seems like a useful adjunct to the existing hop-by-hop security as currently specified in AODVv2.
>> 
>> It can use more work:
>> - Should RFC 7182 be specified instead of RFC 4868?  If so, what is the simplest way to make the conversion?
>> - Should other message types be covered as well?  This would be pretty simple; I just need to reword the section specifying the input data.
>> 
>> I only used RFC 4868 because it seemed very straightforward for me to understand.
>> 
>> Comments are solicited and welcome.  The content of the document may well belong in the upcoming revision of AODVv2 that will be provide resolutions for the many recent comments.
>> 
>> Regards,
>> Charlie P.
>> 
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet