Subject: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove)

From: "manet issue tracker" <[email-masked]>
Date: Mon, 21 Jul 2014 03:43:58 -0000

#47: Security approach unacceptable (submitted for Chris Dearlove)

 The security approach is unacceptable. The security
 directorate and ADs refused to accept this from OLSRv2. They will
 refuse to accept this from this protocol. Incidentally note that
 references to RFC 6621 should be to RFC 6622, except now to RFC 7182.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-manet-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  aodvv2       |    Version:
 Severity:  Active WG    |   Keywords:  security
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <https://tools.ietf.org/wg/manet/trac/ticket/47>
manet <http://tools.ietf.org/manet/>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 20 Jul 2014 21:41:22 -0700

Hello Chris,

I have thought about this for a long time.  Finally, after some good
discussion here at the IETF, I have identified a way forward.  I will
post it to the list after getting some proper security review for it.

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 12:38:30 +0000

It might make more sense to discuss a proposal for inclusion in a WG draft with the WG first.

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: 21 July 2014 05:41
To: [email-masked]; [email-masked]; Dearlove, Christopher (UK)
Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove)

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hello Chris,

I have thought about this for a long time.  Finally, after some good discussion here at the IETF, I have identified a way forward.  I will post it to the list after getting some proper security review for it.

--
Regards,
Charlie P.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 15:42:35 +0200

+1 to this.

> On 22 Jul 2014, at 14:38 , Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Jul 2014 09:26:02 -0700

Hello Chris,

First, I must have a proposal.  When I have that, I will certainly discuss
with the working group before inclusion in the draft.  Right now, I just 
have
a good idea for a proposal -- in other words, a way forward.  I have sent it
to my co-authors.  It needs more text.

If you would like to help flesh out the text, please let me know. I'll be
happy to work with you on it as well to make it a better-thought-out
proposal.  I've noticed that sometimes people on this list can be very,
very critical, and this motivates the desire to do a better job before
presenting ideas to the list.

Other working groups are different.

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 16:39:28 +0000

I would suggest outlining the basic concept on list. Doesn't need a detailed writeup to start with. In fact doing so might minimise the number of writeups and re-writeups.

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: 22 July 2014 17:26
To: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove)

Hello Chris,

First, I must have a proposal.  When I have that, I will certainly discuss with the working group before inclusion in the draft.  Right now, I just have a good idea for a proposal -- in other words, a way forward.  I have sent it to my co-authors.  It needs more text.

If you would like to help flesh out the text, please let me know. I'll be happy to work with you on it as well to make it a better-thought-out proposal.  I've noticed that sometimes people on this list can be very, very critical, and this motivates the desire to do a better job before presenting ideas to the list.

--
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Jul 2014 18:51:20 +0200

> I would suggest outlining the basic concept on list. Doesn't need a detailed writeup to start with. In fact doing so might minimise the number of writeups and re-writeups.

We might copy the basic security concept of OLSRv2... shared group key
should work for AODVv2 too, because its just a replacement for layer-2
security for most MANETs.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 16:57:27 +0000

Thomas has earlier pointed out an issue (which I hadn't thought of) that if AODVv2 reacts to IP packets, what about them? That's new compared to OLSRv2 and RFCs 7182/7183.

But yes, RFC 7182 can definitely be a starting point. It will work applied to 5444 packets. For it to work applied to AODVv2 messages they need to be immutable. I'm not sure if they currently are or are not.

(With a shared secret key, there's little if any win in protecting messages rather than packets. With other approaches, such as in the IBS draft, protecting messages can be a definite win.)

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 22 July 2014 17:51
To: Dearlove, Christopher (UK)
Cc: Charles E. Perkins; [email-masked]
Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove)

> I would suggest outlining the basic concept on list. Doesn't need a detailed writeup to start with. In fact doing so might minimise the number of writeups and re-writeups.

We might copy the basic security concept of OLSRv2... shared group key should work for AODVv2 too, because its just a replacement for layer-2 security for most MANETs.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 22 Jul 2014 12:59:59 -0400

> security for most MANETs.

I think it will not be as easy as that (although I am in favor of
reusing the security related RFCs we have recently published). In
link-state routing protocols, that works pretty well to just stick an
ICV to messages flooded through the network. In reactive protocols,
paths are established by forwarding RREQs/RREP that change underway
(in particular the metrics that change at every hop). So this may be
more difficult. There are also the issues mentioned previously in the
discussion of how RERRs are triggered and that they may tear down
routes.

I believe to remember that Charlie mentioned somewhere that his intent
is to re-add intermediate RREPs (although I personally don't agree
with that if this is really the case). This will make it very
difficult, since routers may reply "on behalf" of others.

Regards
Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Jul 2014 19:01:55 +0200

> But yes, RFC 7182 can definitely be a starting point. It will work applied to 5444 packets. For it to work applied to AODVv2 messages they need to be immutable. I'm not sure if they currently are o…

Packets are always immutable, because they only exist for a single
hop... but you are right, this would be "hop-by-hop" security. But its
a starting point.

> (With a shared secret key, there's little if any win in protecting messages rather than packets. With other approaches, such as in the IBS draft, protecting messages can be a definite win.)

Exactly.

On Tue, Jul 22, 2014 at 6:59 PM, Ulrich Herberg <[email-masked]> wrote:
> reusing the security related RFCs we have recently published).

I was thinking about reusing the concept, not the RFC itself. Use it
as a blueprint.

> In

With a shared group-key every node could impersonate every other node anyways.

Henning Rogge

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 13:10:20 -0400

> On 22 Jul 2014, at 12:59, Ulrich Herberg <[email-masked]> wrote:
> 

I seem to recall back in the days when I looked at this, that when academic work was published on securing reactive protocols, the first step was systematically "disable intermediate / gratuitous RREPs".

Thomas

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 22 Jul 2014 18:13:54 +0100

Why reinvent the wheel again? If the RFC 7182 concept works, let's use RFC 7182. If not, let's understand why not.

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 22 Jul 2014, at 18:01, Henning Rogge <[email-masked]> wrote:
>

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 13:18:57 -0400

> On 22 Jul 2014, at 13:01, Henning Rogge <[email-masked]> wrote:
> 

Well, RFC7182 just defines ICV and TIMESTAMP TLVs for inclusion in RFC5444 messages, packets, and does IANA allocations for code-points, etc. That, certainly, should be reusable and be reused.

RFC7183 may, or may not, be applicable as a blueprint. Although, I reiterate, that it does not protect against the various attacks possible in a reactive protocol by way of an attacker generating data traffic (i.e., "non control packets").

> With a shared group-key every node could impersonate every other node anyways.

Doesn't all this, then, become a matter of "secure only when running over a secured L2"? 

It might be acceptable in some contexts, but I am not sure that I would suggest this as the solution this WG (or, the IETF) should push. I'm not sure that it will actually pass muster in the various later-stage reviews of the SEC-DIR And IESG.

Thomas

ps: I know that you're not suggesting that this is good security, Henning.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Jul 2014 19:21:59 +0200

> RFC7183 may, or may not, be applicable as a blueprint. Although, I reiterate, that it does not protect against the various attacks possible in a reactive protocol by way of an attacker generating d…

Spoofed ICMP messages to make a router drop a route?

> Doesn't all this, then, become a matter of "secure only when running over a secured L2"?

If you have a secure L2, you just need an ACL and you have similar
security than a HMAC based on a shared key...

Henning Rogge

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 13:26:25 -0400

> On 22 Jul 2014, at 13:21, Henning Rogge <[email-masked]> wrote:
> 

That, or various approaches of (for example) 

	"Send data packets to (non-existing) destinations within the network to 
	  a router, watch it exhaust itself (and, create contention in the channel around it)
	  by sending RERRs."

> security than a HMAC based on a shared key...

Yes.

If that's the security model for this protocol, then that probably should be documented, and it should be stated in the applicability statement to not attempts its use elsewhere?

Thomas

---

From: "manet issue tracker" <[email-masked]>
Date: Tue, 22 Jul 2014 18:04:37 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]

-- 
-----------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                 |      Status:  new
 Priority:  major                  |   Milestone:
Component:  aodvv2                 |     Version:
 Severity:  Active WG Document     |  Resolution:
 Keywords:  security               |
-----------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/47#comment:1>
manet <http://tools.ietf.org/manet/>