Hi all...
It's time to bring up our favourite topic again...The comments from the
last teleconf were that we should include some processing steps: which
fields to calculate an ICV from, when to include it, check it, discard
messages based on it etc. Also that we need to state the trust model, i.e.
hop by hop transitive trust. Again, pasting everything below to start more
discussion.
Kind regards,
Vicky.
8. 7182 and security
Thomas: I suggested in my last review: It is important to do more than
this: 7182 does only provide “containers” for ICVs and timestamps, and does
not specify how to use them to obtain specific security properties. RFC7182
may be a tool that can be used, but how* that tool is used is what
determines the security properties.
Therefore, saying that “security is dealt with by using RFC7182” is either
an incomplete statement, or is indicative of insufficient security
considerations.”
The actual sentence in the I-D has been changed, now it explicitly names
the two TLVs from 7182 that it uses. That is, alas, still not sufficient.
Making the aside that was discussed recently on the list, that (i) control
messages are not forwarded, and that (ii) they are modified in transit, the
security/trust model is somewhat different from that of 7181 and
consequently for what 7182 was initially written for. I think that calling
out the trust model, and how 7182 actually is used here, might be what is
called for.
Continuing with the aside, this *especially* as the applicability statement
says: "Providing security for a reactive routing protocol can be difficult”
Thomas:
OK, so assume that I understand regeneration as per my previous email, as
meaning “generate a new message and send to my neighbors, based on what I
learned when processing a received message” — just like any distance vector
protocol does.
In that model, what you write makes sense: each originator of a control
message (i.e., whoever generates or regenerates it) is free to include the
information it desires, such as the 4 points you list above. No issues with
that.
However, and this joins what I pointed out in a previous email, you write
in the applicability statement: "Providing security for a reactive routing
protocol can be difficult."
While we can discuss if the nature of “reactive routing protocol” generates
particular difficulties, we certainly can agree that this protocol has the
same “difficulties” as a distance vector protocol: routing topology
information (by definition) not being exchanged end-to-end, but between
neighbors (who do calculations and generate their own announcements —
regeneration, as you call it).
This means that a specific security model of transitive trust must be
assumed, no? I trust Victoria, therefore when Victoria says “Stan told
me” then I trust that she actually verified that "it was indeed Stan who
told her …” — and either way, I have no way of verifying?
I did not see the trust model / trust assumption discussed in the
specification (specifically not in applicability and in section 13, both of
where it should be called out), but I think that this is actually a crucial
point to get right, in order to approach developing the MTI security
mechanisms.
Anyways, that observation actually contrasts strongly with what the
applicability statement then goes on to say, namely:
AODVv2 provides for message integrity and security against replay
attacks by using integrity check values, timestamps and sequence
numbers, as described in Section 13.
This is true only in as much as messages are indeed exchanged between
neighbors: when you “regenerate” a message, i.e., generate a new message in
response to receipt of a message, you generate brand new payload (but
possibly including some of the data from the received message, of course):
thus, any ICVs “from farther away than the neighbor” will be useless (or,
if you zero out the parts that you change, these parts will not be
protected).
The above sentence, quoted from the applicability statement, and that which
transpires from section 13, seems - certainly, absent the trust model
assumed - to suggest that end-to-end protection/validation is provided.
But, this is not the case.
Finally to the applicability statement, a question:
If security associations can be established, encryption can be used for
AODVv2 messages to ensure that only trusted routers participate in routing
operations.
What you want to say here is that “if all trusted routers have a shared
secret, then we’re able to use that shared secret to ignore non-trusted
routers”, right?
While “security associations” that do not pass through a shared secret
probably can be thought up, it’s not trivial and I did not find any
discussion of that in the document?
Having, on the topic of security, re-read Section 13, which starts:
This section describes various security considerations and potential
avenues to secure AODVv2 routing.
While this is an honest description of what follows, I remain convinced
that this is not sufficient. So let me ask as precisely as I can:
o what is the MTI security mechanism that a conformant implementation must
provide? Specifically: - which are the processing steps (for example in
section 7.2.1 and section 7.2.2 for RREP - and similarly for the other
message types) that define that security mechanism
o what protection is offered by that MTI security mechanism? And what
remains vulnerable.
If this specification targets std.track, then it should include (reasonably
solid, but definitely well specified) MTI security.
Chris Dearlove:
There are two potential choices:
- RREQ has an integrity check value to indicate that someone trusted
created it, if not necessarily the destination. That someone might be
identifiable or not.
- RREQ has a signature that indicates that the destination created it.
Unfortunately, an RREQ that changes as it is forwarded (aggregating data of
any sort) makes the second option tricky, unless there’s some sort of
aggregating signature as it is forwarded. But I’m not an expert on the
latter.
The most trivial case of the former is simply that everyone trusted has a
single shared key. That has obvious issues – although it was good enough
that embodied as RFC 7183 we could get 7181 through the system (as a “must
implement, do not need to use” minimal case). Alternatively something
identity-based (e.g. draft-ietf-manet-ibs) could be used, so you know who
created the message you received, but you are relying on a chain of trust,
hop by hop. At which point you might as well just sign packets (see RFC
7182).
But in even the weakest case (the single shared key used hop by hop) there
has to be a failure for things to go wrong - either loss of key (in which
case all bets are off) or suborning one router (who can do quite a lot of
damage).
I haven't read the latest AODVv2 draft yet, but this sort of thing should
be described in its security considerations - the previous draft though
didn't discuss this as far as I recall.
Chris Dearlove:
If you go down this route of assuming transitive trust, then you might as
well use 7182’s packet ICV and timestamp rather than message ICV and
timestamp.
There is a complication (mostly one of presentation) that the 5444
multiplexer (rather than AODVv2) needs to do this, at least for packets
containing AODVv2 messages (but at which point, probably all 5444 packets).
So you either, depending on your point of view, need to request it to do
that, or (administratively) decline to operate except over a 5444
multiplexer that is doing this.
The advantage is one of saved space and time when packets contain more than
one message. Plus slightly better protection (hop count and limit are
covered) but which probably doesn’t matter here.
If messages are changed/replaced on a one-to-one basis as forwarded, then
the only solutions I can see are hop by hop transitive trust (packets or
messages per hop), or something complicated involving aggregation and
knowledge of changes. But the latter would be a research task to develop,
so let’s not try that.
Jiazi Yi:
I agree with Chris and Thomas on their concerns on the hop-by-hop security
issue.
This is very different from classical DV protocol, in which the vector
information is designed to be exchanged between neighbours.
In AODVv2, the RREQ/RREP/RERR are to be forwarded through multiple hops. A
router can sign a message that isn't actually initialised by itself -- this
is, at least, against intuition.
This can be an issue if we have compromised routers in the network. Of
course, a compromised router is a problem for every protocol, like OLSRv2.
But in OLSRv2, a compromised router can only speak on behalf of itself --
however, in AODVv2, a compromised/mis-configured router can pretend to be
any other router (for example, generate RREQ messages using another address
as OrigAddr). The consequence will be much more serious if that happens.
AODVv2: This is not yet addressed.
