ietf
[Top] [All Lists]

RE: Review of draft-ietf-manet-olsrv2-sec-threats-03

2016-12-20 08:39:46
Hi.
Thanks, Christopher.
So, I think the situation can be clarified - and would have provided a clearer 
answer to my question by 1.  adding a couple of sentences to s6.2 to point up 
the alternative packet and message protections; and 2. explaining in s6.2.1 
that that the 'hole' in the mitigation only occurs if message rather than 
packet ICVs are in use, and then a malicious node can just update the 
hop-limit/-count fields without actively getting involved in neighbour or 
topology discovery and then do a fast retransmit, but that it still never gets 
involved in data transmission or (probably) any other of the threats (see the 
other question I asked).
The 'hole' would then be a one of the entries in the list of things still to be 
mitigated that I suggested.
Cheers - and Merry Christmas, Elwyn



Sent from Samsung tablet.
-------- Original message --------From: "Dearlove, Christopher (UK)" 
<chris(_dot_)dearlove(_at_)baesystems(_dot_)com> Date: 19/12/2016  10:40  
(GMT+00:00) To: Elwyn Davies <elwynd(_at_)dial(_dot_)pipex(_dot_)com>, 
gen-art(_at_)ietf(_dot_)org Cc: 
draft-ietf-manet-olsrv2-sec-threats(_dot_)all(_at_)ietf(_dot_)org, 
manet(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)org Subject: RE: Review of 
draft-ietf-manet-olsrv2-sec-threats-03 
Elwyn Davies
s3.2:  I do not know enough about the details of NHDP and OLSRv2 to know if 
this is a silly question:  Would it be possible for a compromised node to 
perform hop-limit or hop-count modification attacks even with RFC 6183 
security in place just by modifying these fields and reforwarding the packet 
even if it wasn't actually in the network topology?   If so, it would be 
desirable to mention this if it can do any harm.

No, not a silly question at all. But there are details that make the answer 
longer than yes or no.

(Typo: RFC 6183 is RFC 7183.)

You need to distinguish packets from messages (this is RFC 5444 territory). And 
NHDP doesn't matter here, as its message (HELLO) is not forwarded and any hop 
count or limit is either ignored or possibly used as a reason to reject.

So OLSRv2 messages (TC) are forwarded, but at each hop they are put into a 
packet. That packet is assembled from one or more messages, and at each hop it 
is broken apart and a new packet formed. So the TC message may share a packet 
with different other messages at each hop.

RFC 7183, which forwards to RFC 7182 where the actual work is defined, allows 
you to protect either messages, or packets (or both). Packet protection 
protects hop count and hop limit, but has other limitations (it is not end to 
end). Message protection is applied to each message, and is end to end (or 
rather, originator to each processing/forwarding router) but does not protect 
hop count and hop limit.

So if using RFC 7183/7182 just to protect messages (it also covers sender 
addresses) then there is an attack. Attacker receives packet, sends new packet 
that resets hop count and limit in those messages it includes in a new packet 
to only one more hop before end of life. Sends quickly (normal forwarding may 
be delayed, especially if using RFC 5148) and possibly even elsewhere in 
network (wormhole attack). This "penultimate hop" message poisons the real 
message, if it arrives later, as it is seen before, and not forwarded, while 
the penultimate hop message will go one hop and stop. (Can we do this with a 
"last hop" message to poison even more successfully? That I would need to check 
some details in RFC 7181 to determine.)

Could this be prevented? I can imagine a revision of RFC 7181's forwarding 
rules that recorded hop count/limit, and if seeing a longer range message 
decided to forward that even if seen before with a lower range. But that 
introduces a new attack of creating a sequence of increasing range messages to 
add to the traffic load. Or you could use both packet and message ICVs, which 
does prevent this attack but increases overhead. Or (potential future that I 
know someone is working on, but is not a solution now as far as I know) find a 
form of aggregating signature that overcomes this problem efficiently.
********************************************************************
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.
********************************************************************