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

From: Charlie Perkins <[email-masked]>
Date: Thu, 3 Mar 2016 14:24:00 -0800

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.

---

From: Anders Nilsson Plymoth <[email-masked]>
Date: Sat, 5 Mar 2016 12:59:50 +0100

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 <
[email-masked]> 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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Christopher Dearlove <[email-masked]>
Date: Sat, 5 Mar 2016 12:36:42 +0000

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
[email-masked]

> On 5 Mar 2016, at 11:59, Anders Nilsson Plymoth <[email-masked]> 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 <[email-masked]> 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.
>>

---

From: Anders Nilsson Plymoth <[email-masked]>
Date: Sun, 6 Mar 2016 01:16:32 +0100

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 <
[email-masked]> 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
> 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
>> AODVv2, I have submitted a new draft with an idea to enable the source and

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 6 Mar 2016 10:18:20 +0000

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
[email-masked] (iPhone)
[email-masked] (home)

> On 6 Mar 2016, at 00:16, Anders Nilsson Plymoth <[email-masked]> 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 <[email-masked]> wrote:

---

From: Anders Nilsson Plymoth <[email-masked]>
Date: Sun, 6 Mar 2016 23:49:29 +0100

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 <
[email-masked]> 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

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 6 Mar 2016 23:38:55 +0000

Outside requirements are of course the trump card, and the reason one size doesn't fit all.

> On 6 Mar 2016, at 22:49, Anders Nilsson Plymoth <[email-masked]> wrote:
> 
> 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 <[email-masked]> wrote: