Hi Vicky,
Am 02.03.2016 um 11:25 schrieb Victoria Mercieca <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> wrote:
Hi Vicky,
Am 01.03.2016 um 15:21 schrieb Victoria Mercieca <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.
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.
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?
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....?
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> 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>:
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>:
Am 22.02.2016 um 14:59 schrieb Stan Ratliff <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>