Right, it is always up to the authors (subject to wg consensus)... but it
certainly helps me understand - so many thanks for that.
Cheers,Elwyn
Sent from Samsung tablet.
-------- Original message --------From: "Dearlove, Christopher (UK)"
<chris(_dot_)dearlove(_at_)baesystems(_dot_)com> Date: 20/12/2016 14:50
(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
I was just commenting as an author of most of the RFCs referred to - but not
this one. So that’s down to the authors of this one to accept, adjust or
whatever.
But in my personal capacity, I think a comment on packet ICVs would not go
amiss - but it needs to get its layering right. (It’s not “if OLSRv2 uses packet
ICVs” its “if OLSRv2 runs over an implementation of 5444 with packet ICVs
enabled”, roughly speaking. And that can be an also or an instead.)
(I’m assuming you saw my other email in which I noted I’d forgotten that 7183
does not discuss packet ICVs, only 7182 does. That’s because of that layering
issue.)
Also, if the authors were to go further into tradeoffs between packet and
message ICVs, whether we have a single shared key or per router keys for that
latter
makes a big difference. 7183 is really about the shared case - but 7182 does
allocate at least one code point that must be per router, 7859 - experimental -
has a more detailed non-shared case. Roughly, with a shared key, there’s no
real advantage in message
ICVs over packet ICVs. With individual keys that’s not so, there are pros and
cons each way (though message ICVs probably have more pros, but hop count/limit
attacks are not one of them).
Christopher
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T: +44 (0)1245 242194 | E:
chris(_dot_)dearlove(_at_)baesystems(_dot_)com
BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
From: Elwyn Davies [mailto:elwynd(_at_)dial(_dot_)pipex(_dot_)com]
Sent: 20 December 2016 14:29
To: Dearlove, Christopher (UK); 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
*** WARNING ***
This message originates from outside our organisation, either from an external
partner or the internet.
Consider carefully whether you should click on any links, open any attachments
or reply.
For information regarding
Red Flags that you can look out for in emails you receive,
click
here.
If you feel the email is suspicious, please follow
this process.
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.
********************************************************************