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)
<chris.dearlove@xxxxxxxxxxxxxx <mailto:chris.dearlove@xxxxxxxxxxxxxx>>
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>
chris.dearlove@xxxxxxxxxxxxxx
<mailto:chris.dearlove@xxxxxxxxxxxxxx> | 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
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manet
