Hi John,
Am 04.04.2016 um 23:57 schrieb John Dowdell <john.dowdell486@xxxxxxxxx>:
Maybe some text for the security considerations. This is current absolutely
On 4 Apr 2016, at 21:55, Victoria Mercieca <vmercieca0@xxxxxxxxx
<mailto:vmercieca0@xxxxxxxxx>> wrote:
Hi Lotte,
On 4 Apr 2016 17:34, "John Dowdell" <john.dowdell486@xxxxxxxxx
<mailto:john.dowdell486@xxxxxxxxx>> wrote:
Yes, post to show progress :)
+1
OK looking at some TODOs now
1. The ones in the definitions; is it worth linking from the definition to
where the explanatory text is?
2. Applicability statement. Sigh. Wireless networks. We discussed keeping
that rabbit hole shut, and I’d rather not open it again. Yes it is very
likely that AODVv2 will be used on wireless networks, but given that a
very high proportion of mesh and point to point wireless networks operate
some proprietary or closed standard protocol (apart from the usual 802.11
and .15 ones), I’d really rather not get into a protracted discussion of
what could and could not be done here.
3. Page 9: yes there is an issue with hop-by-hop trust. Correct. Does
anyone know how to fix that yet? No. We kicked it around again in DTN this
morning and still no nearer a workable solution. IMO best left as an
exercise for the reader, or text to that effect. If I was building such a
network today, I would probably pre-load key material into each node with
a lifetime of the mission plus a bit, maybe with a spare set of keys in
case of compromise. In the future when technology has moved on to be able
to properly negotiate trust without reference to a central PKI server, I
would do something fancier.
standard material that is in line with publicly available advice. This kind
of material should be formally recorded and enacted as system security
policy, but it is up to the system integrator as to what to do based on the
particular application they have in mind. I’ve tried to list some things that
should be considered because routers from multiple organisations could turn
up and you need to know if you can trust them or not. In the end it comes
down to money; super secure systems are massively more expensive than systems
with run of the mill security. Home broadband v nuclear reactor control
network, if you will. Most of what follows is actually not the job of AODVv2,
and the way security should be implemented will depend on current
industry-wide best practice for the application in hand. The best security
comes in layers, known as defence in depth, so that no single point of
failure exists.
"Trust between two or more AODVv2 routers needs to be established to the
satisfaction of the system integrator or implementor. The security strategy
used will depend on the level of potential risk, addressing such questions as
those below, but moderated according to the appetite for risk (including the
cost of implementing security or the assessed likelihood of compromise)
signed off by authorised persons within the organisation.
1. Are the routers all under the control of a single organisation, or from
multiple organisations? If multiple organisations, can trust be established
at the organisational level for the routers under each organisations control?
2. What is the maximum extent of the flow of traffic? Is the traffic
contained within a single closed network, or open to the internet? Can
control and user traffic be checked and secured at the boundaries between the
various networks, particularly to the public internet? In particular, is
management access to each router properly secured and is such security
monitored and reviewed regularly?
3. What is the risk of compromise of security in the proposed operating area
over the lifetime of the proposed usage? Can such a compromise be detected,
or could such a risk be mitigated by more frequent change of trust
credentials? Are currently recommended cryptography suites being used? AODVv2
is likely to be used in networks of routers fitted with wireless devices. The
overall threat to the network ultimately depends on the ability of an
attacker to intercept and exploit routing protocol and user traffic, which
becomes more likely if any wireless devices are used, particularly those
conforming to open standards.
4. What would be the effect of a security compromise? This risk should be
considered at all levels in the system up to and including application-level
user traffic, not just the risk to the routing protocol itself. The effect on
the organisational business being conducted across the network of routers
during or following such compromise should be considered. Can additional
security mechanisms be put in place to mitigate effects at multiple layers in
the system, if deemed necessary?
5. AODVv2 is designed for ad-hoc networks, and therefore any unexpected
addition to the network must be considered hostile until trust can be
established.”
I’m sure there should be some more but I can’t think of anything just now.
Regards
John
4. Page 17, maximum single hop metric value. The current IETF favourite
appears to be two bytes worth, think this is the same in DLEP (Stan can
you confirm please?). Can we go with that?
5. RREP_Ack timeout. I’d expect to get an Ack back pretty quickly since
it’s only coming from one hop away. Is there a short time value we can
re-use from somewhere else in this spec?
6. Check RREP_Ack in MRMT. Why isn’t this the right place, thought this
was now the working space for routes before they go live into the kernel?
7. (What does this mean? How would one determine a link to a neighbor to
be broken….suggest removing it JWD TODO) need some clarification. We do
discuss how to detect links are broken, and what is it that he is asking
to be removed?
8. Page 24 sect 6.6 the table for waiting routes is the MRMT, is it not?
That’s all for now. Lotte, you are owed a very significant number of beers.
+1!!!
I'll also try to take a look at the TODOs ASAP, but by all means also tell
MANET "we haven't fully addressed these comments yet". Are there any
comments we need to send a point by point response to at the moment? I think
you already did for Justin's comments?
Kind regards,
Vicky.
Cheers
John
On 4 Apr 2016, at 20:59, Ratliff, Stanley <sratliff@xxxxxxxxxxx
<mailto:sratliff@xxxxxxxxxxx>> wrote:
Go!
Regards,
Stan
Sent from my iPhone
On Apr 4, 2016, at 4:56 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx><mailto:lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx>>> wrote:
Hi all,
since we're allowed to submit Drafts again now (I think) and we decided
to publish asap, I thought I'd give you a quick status update and wait
for your Go/"Wait a minute, let's fix this first" signals.
DONE:
----
* All JWD!s are resolved now
* out of 90 JWD and JWD! comments, 64 are done (I've attached my copy of
Justin's review if you want to look for the remaining 26 TODOs, it's the
file called "draft-ietf-manet-aodvv2-13 (2).txt")
* added revised security considerations
TO DO:
----
* Most notable of the 26 JWDs that are yet to be resolved:
+ (is there some table that lists routes that are being waited on? JWD)
We decided to add a separate
RREP table that lists them and I've volunteered to write text
for that, but every time I set out to do that,
I got more confused... I'm starting to worry about the amount
of tables AODVv2 needs by now, and
I've been picking Vickys brain on how to achieve storing that
info without having to add another table,
but it's an ongoing process.
+ the approaching the limit thing we're currently discussing in
"[aodvv2-discuss] Re: Justin's review"
* some TODOs in security considerations (see github)
* still waiting for Chris' feedback regarding the revised 5444
multiplexer wording, so that hasn't changed yet
* Make it more clear that AODVv2 currently doesn't support RREQs for
prefixes to make Thomas happy (I'm planning to do that tomorrow
afternoon)
What do you think?
Regards,
Lotte
<draft-ietf-manet-aodvv2-13 (2).txt>
<draft-ietf-manet-aodvv2-14d-from-c.diff.html>
<draft-ietf-manet-aodvv2-14d.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.
_____________________________________________________
