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.
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...?
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.
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?
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>
