Gang,
We’re gonna “get clocked” over this discussion being had on the private mailing
list…
Regards,
Stan
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Victoria Mercieca
Sent: Wednesday, March 02, 2016 9:15 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: Ulrich Herberg's email on Security Considerations
Hi Lotte,
On Wed, Mar 2, 2016 at 1:30 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi Vicky,
Am 02.03.2016 um 11:25 schrieb Victoria Mercieca
<vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>>:
Hi Lotte,
Thanks for the feedback. Couple of comments below but feel free to make your
own updates for a v4 of this section.
On Tue, Mar 1, 2016 at 11:17 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi Vicky,
Am 01.03.2016 um 15:21 schrieb Victoria Mercieca
<vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>>:
Hi all,
Brilliant work Lotte!!
Inspired by your progress I've done my best to fill in more details of how to
generate the ICV and Timestamp for each message type and restructured your text
a bit to separate some of the details like Ulrich said. Theres still some TODOs
in there though...and perhaps could do with fleshing out some detail the way
OLSRv2 does. I think I copied the changes to SHOULDs and MAYs like you said.
You're a star! I really like your reshufflings and additions and the bullet
points are on point. (ba-dum-tss)
As usual, some nitpicks:
* “However, since the sender of
the RERR message is either malicious or broken, it is better that it is not
used as a next
hop for these routes anyway.” should imo be deleted (see discussion "Re.
Security thread)
I think it just indicates "if you are a malicious router and you're withdrawing
perfectly valid routes, I dont want to forward data to you anyway..." This is a
good thing in a way, because it allows a RREQ to go out to fix the problem.
Yes, but how do we detect that the router is malicious (if no ICVs are used)?
We don't, but if its not malicious, the routes are really gone and we cant use
them. If it is malicious, its probably a good idea not to use them anyway
because the router might be doing other malicious things. Either way, whether
we know it's malicious or not, removing those routes is probably a good idea.
Although theres no guarantee the malicious router wont participate in the route
discovery and we end up in exactly the same situation. I dont mind if this bit
is deleted.
* "13.1.3 False Confirmation of Link Bidirectionality" made me falsely expect a
subsection about spoofed RREP_Acks... How about using "13.1.3 False
Confirmation of Link Existence" or "13.1.3 Premature RREP" or something similar?
I think I figured RREP_Acks wouldnt be a problem...if an RREP_Ack was
unsolicited (ie we didnt recently send an RREP to the router that just sent us
the RREP_Ack) we would ignore it. I made sure we check it's an expected
RREP_Ack before we update the neighbour table...and therefore any routes using
that router. I also did something similar for RREP too actually, I moved the
update of neighbour table to after we determine if the RREP answers a recently
sent RREQ, and said to ignore the RREP if it was unexpected.
So maybe the "false confirmation of bidirectionality" isn't an issue... unless
by coincidence a malicious router happens to fake a RREP or RREP_Ack at roughly
the same time as a genuine RREQ or RREP respectively is sent.
Couldn't a malicious node also immediately answer a RREQ with a RREP that has
stellar metric values, causing the genuine RREP of the route that is actually
established to be discarded? Then, all traffic would flow towards the malicious
router, which could drop it, disrupting communication to TargAddr.
True but that would be a different attack which probably deserves its own
mention in the message insertion section.
Kind regards,
Vicky :)
Also it would only be a false indication if the genuine RREQ or RREP didnt
arrive at the malicious router (ie the link was unidirectional from the genuine
router to the malicious one). Also the malicious RREP or RREP_Ack would have to
correspond to a RREQ or RREP the malicious router was not going to receive.
Chances are slim!
Unless theres potential in the statement "other non-AODVv2 signals might be
used to tell us links are bidirectional" from the next hop monitoring section.
But maybe that whole section 13.1.3 could be deleted?
I think it shouldn't, I was really just confused by its title :D
So the false confirmation could happen if we get a RREP.
* " o Ignoring unsolicited RREP and RREP_Ack messages partially mitigates
against this threat." Does this refer to entirely unsolicited messages (i.e. ne
RREQ sent before)?
Not sure what you mean....?
Me neither, I think I was just tired. Nevermind that one... Sorry
If not, How does a node know which RREP was unsolicited and which RREP is
genuine?
I think by matching it to a recently sent RREQ, and checking if the response
arrives within the allowed timeout. We might not be clear enough about how this
is done in the draft though, based on Justin's review.
* section 13.4.4 lists all steps as "1." I'm assuming this is because pandoc
doesn't care about the actual numbering and your text editor autocompleted it
this way, but I've changed this to avoid confusion when sharing it with the WG,
feel free to copy & paste:
1. The considerations in Section 8 of [](#RFC7182) are followed, removing
existing ICV TLVs
and adjusting the size and flags fields.
2. The ICV is calculated over the fields specified below, depending on message
type. This value
MAY be truncated (as specified in [](#RFC7182)).
3. If the TIMESTAMP is to be included, add the TIMESTAMP TLV, updating size
fields as necessary.
4. Add the ICV TLV, updating size fields as necessary.
5. The changes made in Step 1 are reversed to re-add any existing ICV TLVs and
adjusting the
size and flags fields.
Yep...just me being lazy :)
Again, like you, I don't feel fully qualified in this section!!
The whole "regeneration vs forwarding" thing looks like a pretty big annoyance
to MANET in general. I explained before that we use the term "regenerating"
because we make changes (adding ValidityTime, adding/removing AckReq, updating
metric). Thinking out loud... I guess in order to limit having those changes at
intermediate hops, we would have to make rules that only the originator can
choose a validity time...intermediate routers could then potentially either not
advertise the route, or advertise it and withdraw it later by using RERR to
enforce their own validity time. Also maybe the AckReq would have to be a
different message type. Or Ack could be end-to-end...so that sender of the RREP
includes the AckReq, every forwarded version contains the same contents,and
RREQ_Gen is responsible for sending the ack, and every intermediate node
responsible for forwarding it back to TargAddr. But then how do we do
blacklisting? Also the metric would still have to change and therefore couldnt
be included in the ICV.
...Seems like too huge and hideous a change to consider at this point...?
+1. I don't really understand how AODVv2 is supposed to work without
regeneration... Especially when it comes to metrics. Would it be a good idea to
open a new thread for this on the MANET list stating what you've just said? I'm
a bit afraid of the feedback, but it needs to be put to resolved :D
Anyway, happy for this to go out to MANET, happy for anyone to poke holes in it
or fill in the gaps. I leave it in your collective hands :) We can remove the
TODOs and stick it in the draft and release a new version tomorrow, by all
means.
Maybe it's okay to send _v3 out in this stage (including the TODOs) just to
show "this is the direction we're going in, we're still figuring stuff out but
what do you think so far?"
Would be good to recap all the comments and all the bits of the BCP document
we've seen in all the different emails just to tick them off (and then to
respond to each individually). Not sure how to include the matrix Charlie sent
out though? Any thoughts?
I'll look at John's follow-up to the matrix in a sec.. In general, I'd think
just as a table-ish thing at the beginning?
Feel free :)
Kind regards,
Vicky.
Regards,
Lotte
Kind regards,
Vicky :)
On Tue, Mar 1, 2016 at 9:41 AM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
So, just as an overview, things from Ulrichs e-mail that need addressing but
are *not* in the document as TODOs:
- I think the chain-of-trust model that doesn't allow end-to-end
integrity protection is problematic in an entirely distributed and
untrusted network environment. It's a bit like saying that you trust
that an email sent to someone else is integrity protected because the
step-wise SMTP between various mail servers along the path uses TLS.
This brings me to the deeper issue of why messages are regenerated
instead of forwarded. I have not understood why this is necessary in
the first place (and I argued this in an email to the list at
https://www.ietf.org/mail-archive/web/manet/current/msg18081.html)
- I have some doubts that the Security ADs will agree with the terms
"recommendations" in the title of the section together with a lot of
SHOULDs and MAYs in the text, which seems to imply that usage of the
integrity protection is not mandatory. When specifying OLSRv2, we were
clearly told that we require a "MUST-implement/SHOULD use until you
have something more better".
– but I don't really get what he's hinting at here, the the MAYs that the text
has aren't recommendations but risk assessments (and have since ben moved). We
could make the follwoung SHOULDs MUSTs:
* The ICV SHOULD be verified at every step along
the dispersal path of the RREQ to mitigate the threat.
* The ICV SHOULD be
verified at every step along the unicast path of the RREP.
* The RREP_Gen SHOULD use the source IP address of the RREP_Ack to identify the
sender, and so the ICV SHOULD be calculated using the message
contents and the IP source address (also, I've added "and SHOULD be verified
when received.")
* The receiver of the RERR SHOULD use the source IP address of the RERR to
identify the sender. (also– identify how? what does the receiver do with
that IP to "verify" it? check that that's a legitimate neighbor? we need to
write that down....)
plus:
* The message must also include
a timestamp to protect against replay attacks, -> i've changed this must to
MUST
* The message MUST also include a timestamp to protect
against replay attacks, using SeqNum from RERR_Gen as the value in the
TIMESTAMP TLV. -> i've changed this must to MUST
- The Sec ADs required us for OLSRv2 to argue (in the spec) why we
don't need to specify automatic key management as per BCP107. I don't
see a similar section in AODVv2. Have you confirmed with the Sec ADs
that their requirements have been relaxed?
- The biggest issue I have with the proposed security consideration
text is that there is no detailed specification of how to sign and
validate messages, similar to what we were required to do by the Sec
ADs in RFC7183. I doubt that two AODVv2 implementations by different
programmers would be interoperable just using the current text. You
mention the functions specified in RFC7182; but really these are just
the containers for the actual information. RFC7182 does not mandate
how to use them (such as we do in RFC7183).
I'll be happy to send out the current document to Ulrich, TODOs and all, but we
need to send *something* (ideally that someone more experienced has verified to
not be bogus)...
Regards,
Lotte
Am 23.02.2016 um 13:58 schrieb Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>>:
Hi all,
As a first step I've been going through BCP72 to see what we're missing and
I've added what I could and left TODOs in the document where I couldn't figure
out/thought it needed some more discussion.
The following should be (partly) addressed or added now:
[from BCP72]
Authors of internet standards MUST describe which denial of service
attacks their protocol is susceptible to. This description MUST
include the reasons it was either unreasonable or out of scope to
attempt to avoid these denial of service attacks.
[from BCP72]
Authors MUST describe
1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against
At least the following forms of attack MUST be considered:
eavesdropping, replay, message insertion, deletion, modification, and
man-in-the-middle. Potential denial of service attacks MUST be
identified as well. If the protocol incorporates cryptographic
protection mechanisms, it should be clearly indicated which portions
of the data are protected and what the protections are (i.e.,
integrity only, confidentiality, and/or endpoint authentication,
etc.). Some indication should also be given to what sorts of attacks
the cryptographic protection is susceptible. Data which should be
held secret (keying material, random seeds, etc.) should be clearly
labeled.
[From Ulrich Herbergs e-mail]
- The text in section 13.3.1 is hard to interpret as implementer,
since it mixes a security evaluation with the actual specifications of
how to protect the messages. I think it would be better to have
separate sections for these two parts. Also, as a stylistic
recommendation, I always had a hard time reading the continuous text
as opposed to bullet points as we applied in OLSRv2.
I've added TODOs for each of BCP72's MUSTs that I didn't address (in places
where I thought the issue could be addressed)
I've also reshuffled some text from 13.3.1 into the other subsections.
Additional remarks:
* Regarding the detailed spec on how to sign and validated messages requested
by Ulrich Herberg,
I think I can suggest some instructions on the RFC5444/7182 part, but these
would need to be
triple-checked by someone who knows what they're talking about in terms of
security– and I have
no idea how to write down the whole shebang for our generic format. Would
anyone like to join forces there?
* BCP 72 says:
Note: In general, the IESG will not approve standards track protocols
which do not provide for strong authentication, either internal to
the protocol or through tight binding to a lower layer security
protocol.
If I understand it correctly, we do not have any authentication mechanism
(only integrity, and according
to BCP72, it's difficult to have that without authentication). Again, I'm
lacking the expertise or experience
to figure this our properly, would anyone like to volunteer?
* (I've interpreted words in all caps from BCP72 as key words and re-used them
in them in the same way,
if that's correct, I suppose we'd have to add a disclaimer similar to the
classic "The key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",[...]" ? )
I'd like to run the updated text by the WG as quickly as possible, but with a
few less TODOs, so any input would be great! :)
Cheers,
Lotte
(ps: I've still got our other threads on my radar, but I felt like since this
got some responses, it should be priority right now...)
<13. Security Considerations_v2-from-.diff.html>
<13. Security Considerations_v2.txt>
Am 22.02.2016 um 17:34 schrieb Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>>:
Am 22.02.2016 um 14:59 schrieb Stan Ratliff
<ratliffstan@xxxxxxxxx<mailto:ratliffstan@xxxxxxxxx>>:
Gang,
I think this looks like a reasonable starting point from which to consider
making changes to the Security Considerations. I think this is a high quality
review. Other opinions?
I agree. I'm working my way through it right now, but I'm afraid with my
limited understanding of security (I've been working on it, but that takes
time...), I'll only be of limited help. But I'll be happy to newbie-proof where
I can! ;)
Regards,
Lotte
Regards,
Stan
<13. Security Considerations_v3.txt>
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________