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

[Anders Nilsson Plymoth <[e-mail]>]

Hi,

Doing a AODVv2 7183 equivalent sounds like a very good idea, and I would
fully support it and be able to contribute if needed. It would also be able
to house more security implementation details for better inter-operability
that I was looking for. I would like to hear what Charlie's and the other
authors thoughts are. I got the impression this was partly the motive of
draft-perkins-manet-aodv-e2esec-00 which prompted me to start this
discussion.

As a side note, we did initially have an approach very similar to IBS but
moved to certificates based on outside requirements.

Thanks,
Anders



On Sun, Mar 6, 2016 at 11:18 AM, Christopher Dearlove <
[e-mail]> wrote:

> Note that for OLSRv2 there is 7183 as well as 7182. AODVv2 needs its 7183
> equivalent, though of course it doesn't have to be a separate draft.
>
> In terms of what you say, I completely disagree that if you have an IP
> address it's just as easy to have a certificate.
>
> Transferring certificates in TC or RREQ messages is a serious overhead.
> Just in HELLO messages is bad enough, but inadequate for end to end
> authentication. Alternatively they need pre-distribution.
>
> Addresses on the other hand have neither of those disadvantages. They are
> small. They are being included in messages anyway. But also, you learn IP
> addresses during routing (including neighbour discovery). I can and have
> implemented OLSRv2 with IBS without any prior knowledge of any other
> participant in the network.
>
> Also note in particular that as far as I'm concerned other nodes aren't
> just destinations, many are relays. I might need prior knowledge of actual
> traffic destinations if I'm the traffic source. But not of relays. And if
> I'm a relay, not even that. (That's especially true for AODVv2 that just
> gets an IP packet to deliver out of the blue.)
>
> More, even there, the final destination in routing protocol terms is a
> router, not a host. For encrypted comms it's a host I want to communicate
> with, have certificate of etc. And actually I can do that without a
> certificate too by using identity based mechanisms. Which is also something
> we're able to do.
>
> Yes, we're both saying no single solution. But I think you're downplaying
> the complications of what you're suggesting. Mostly that doesn't matter,
> but it is an additional reason I don't think this (in the AODVv2 draft, or
> its 7183 equivalent) is the right place.
>
> The right place is a draft how to use the approach you favour within a
> 7182 framework. Which then AODVv2 (or even OLSRv2) could then adopt as
> required. Similar approach to the IBS draft. People can then take it or
> leave it. (I'm not claiming IBS is perfect either, it's not very low
> processing power friendly for one. I'd also object if that were pushed as
> the primary approach.)
>
> --
> Christopher Dearlove
> [e-mail] (iPhone)
> [e-mail] (home)
>
> On 6 Mar 2016, at 00:16, Anders Nilsson Plymoth <[e-mail]>
> wrote:
>
> Hi Christopher,
>
> My point wasn't that a signature based approach should be the only
> solution, but that I think that signatures are preferable over HMAC based
> E2E authentication approaches. My point was also that I would like to see a
> tighter integration of the methods in RFC 7182 into the AODVv2 draft
> describing the protocol operation rather than just as security
> considerations. Maybe this is deemed not necessary, but I find that when
> using the current draft in combination with RFC 7182, it is hard to make an
> implementation that would be inter-operable. From my reading of RFC 7182
> signatures should be supported, but is unclear how. I also see
> authentication as desirable which was also indicated by Charlie.
>
> Even so, I regard a signature based approach as highly desirable,
> draft-ietf-manet-ibs is one example, but I don't see the big issue with
> certificates. Each node would need a certificate before joining the
> network. This is similar to the keys in draft-ietf-manet-ibs. The node
> would also need to have the certificate for the destination node in order
> to setup the route. How would have the node have this certificate? How
> would the node know the IP address of the destination? If a node knows the
> IP address of a destination and would like to exchange encrypted data, it
> would also have the certificate. How about authenticating routing messages?
> Certificates of neighboring nodes can easily be exchanged by a local
> protocol, e.g. NHDP. I have manet type network running with this approach
> and it works well. It also enables TLS/DTLS when desirable.
> Another approach as taken by SAODV was to include public keys, signatures
> and hashes into routing messages.
>
> And to quote you, I am saying not this is the one and only solution, but
> one that I think shouldn't be excluded.
>
> Thanks,
> Anders
>
>
>
>
> On Sat, Mar 5, 2016 at 1:36 PM, Christopher Dearlove <
> [e-mail]> wrote:
>
>> 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
>> [e-mail]
>>
>> On 5 Mar 2016, at 11:59, Anders Nilsson Plymoth <[e-mail]>
>> 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 <
>> [e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>