Subject: Re: [manet] AODVv2 security considerations

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 14 Mar 2015 21:38:07 -0000

All (adding Alvaro to whom I bequeath my loving interest in your work),
 
It has been a little while, I can't claim to recall when I last looked at this document.
 
The best thing for me to do is look again at the Security considerations in this latest revision.
However, I think that the point that Christopher makes is that getting Security AD approval can be a bumpy road. They mean well, but...
I think that pain with OLSRv2 and with some of the recent OLSR-related work was late and unexpected.
I agree with him that the feedback can be variable and dependent on the person.
 
In general my advice is "assume the worst" and look very carefully at what issues might be raised. Don't dodge them! At the very least call them out (e.g., "It would be a security issue if A and B. Deployers should beware and consider this before enabling those options."), but better to have a resolution that you clearly state.
 
A good move is to get an "early" Security Directorate review. The chairs can email [email-masked] with the request. They should set the subject to "Early SecDir review requested", give a target date for the review, and should indicate the status of the document.
 
Cheers,
Adrian

From: Stan Ratliff [mailto:[email-masked]] 
Sent: 11 March 2015 15:27
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; Alia Atlas
Subject: Re: [manet] AODVv2 security considerations
 
Chris, 
 
Thanks again for the input. I've discussed this a bit with the co-editors, and we have a question for the ADs. 
 
Adrian/Alia,
 
My understanding is that there had been discussions earlier with Adrian regarding the security implications verbiage; the outcome from those discussions (at least from the editorial team perspective) was that AODVv2 was in pretty good shape. Chris brings up points from the perspective of having "been there, done that, didn't get the T-shirt, but got a bruise or two"... ;-)  So, I'm confused and concerned. 
 
Looking to you (our ADs) for some guidance on this issue, please. 
 
Regards,
Stan

On Tue, Mar 10, 2015 at 11:11 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
Another just one section set of comments.
 
First, I will note that what I’m saying is informed by our experiences in getting RFC 7181 (OLSRv2) standardised. As people may or may not recall, the version of OLSRv2 that left the WG basically said you can do what is appropriate to your requirements. This did not fly with the IESG. I do not expect what is in the security considerations section here to fly with the IESG. Specifically, we had cleared our original version with the then security AD, but a change in ADs meant we no longer had agreement. And although ADs have changed again, not where it matters here.
 
However we have done some of your work. Specifically RFC 7182 contains formalised versions of what’s just outlined as a sketch in RFC 5444. However note that even RFC 7182 (updating RFC 6622) was not enough, and we needed also to write RFC 7183. (We did this as a separate draft as that was less disruptive.) And, not obvious from those three drafts, we had to fight hard to get even those three as sufficient. Specifically, we needed a carefully reasoned explanation why we didn’t need to mandate a key distribution mechanism. And don’t assume that fight is won, it’s been demanded again since (in another context).
 
To summarise RFC 7183, we have a mandatory to implement mechanism (one of the RFC 7182 options) but not a mandatory to use mechanism, together with a  SHOULD for security of some sort.
 
So that’s me saying I don’t think what you’ve got will pass the IESG, unless they have a major change in policy. I think you could get to something they’ll accept, with work, by capturing the essence of RFC 7183 (adopted of course for your circumstances).
 
Now I’ll look at Section 15 in more detail. First I think there is quite a lot that is a “you SHOULD do this” without enough detail that two people could implement something that interworks. For example, but not only, “SHOULD also verify the integrity and identity”.  How? (The identity part is particularly tricky. RFC 7182 is not identity based. The draft that has an identity based signature is trapped in the IESG – they are really not a pushover.) The part that says you should repeat back the erroneous information. How – at the implementation level? The comment that S/MIME and OpenPGP could be adopted, that’s so vague as to be all but useless.
 
You suggest the use of IPsec. That’s probably OK hop by hop (I’m not an IPsec expert to know for certain). But if you want end to end that doesn’t work as IP packets aren’t sent end to end, as RFC 5444 packets are a one hop mechanism. If you want end to end its AODVv2 messages that need protecting, and IPsec won’t do that for you. There’s a ghost of problems overcome elsewhere with the reference to “AODVv2 control packets”. No such thing.
 
You incidentally reference an ICV as RFC 6621. I think you mean RFC 6622, or now RFC 7182. I agree that the establishment of security associations is out of scope – but be prepared to have to argue that.
 
In short, (a) I do not expect this to fly with the IESG, and it’s a lot better to fix now than later, (b) there’s too much vagueness in places I have noted and elsewhere to be able to create interoperable mechanisms, and (c) the IPsec approach does not work. (There’s a possible draft in IPsec for RFC 5444, but that’s not AODVv2 specific.)
 
But the good news is that we have a model of what does work, RFC 7183. Steal from that, with references to RFC 7182. The “mandatory to implement, but you may do something else” approach has worked in the past.
 
-- 
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 <tel:%2B44%201245%20242194>  |  Fax: +44 1245 242124 <tel:%2B44%201245%20242124> 
 <mailto:[email-masked]> [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
 
********************************************************************
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.
********************************************************************

_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet