Please PLEASE use the manet list....
On Fri, Apr 22, 2016, 6:55 PM Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
Hi Lotte,
On Fri, Apr 22, 2016 at 11:50 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky,
Am 23.04.2016 um 00:36 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi Lotte,
Did I mention you're brilliant?! Part of me feels defeated, but part of
me wants to give this a go and do as much as we can in this last week and a
half!
I feel the same way :D
On Fri, Apr 22, 2016 at 11:15 PM, Stan Ratliff <ratliffstan@xxxxxxxxx>
wrote:
Lotte,
On Fri, Apr 22, 2016 at 5:53 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi all,
so after the shitstorm has calmed down a bit, I hope your spirits are
still intact :/ I’ve been trying to just respond to the discussions as good
as I can for now. (Unless any of you take me aside and tell me I’m doing
the opposite of helping, I’ll try to do more soon)
You're doing FANTASTIC! I've been laying back a bit - the discussion is
turning positive, and that's great for both AODVv2 and for the WG in
general. It looks like people are trying to coalesce and advance the draft
instead of just hammering one another.
The remaining issues I can remember are:
1- figuring out the exact way we can say „before calculating the ICV,
set the metric value to 0“ and remove any mention of regeneration from the
draft
Yeah. Based on the discussion on-list lately, I wonder if some text
about AODVv2 "modifying the metric field" in the message, but leaving the
rest unchanged. In that case, your text exactly applies - "Prior to
calculating the ICV, and checking the received ICV value, the metric MUST
be saved, and replaced with '0'. After comparison, and prior to
transmission, the metric value MUST be replaced with the correct metric for
the next-hop transmission." Or words to that effect.
Brilliant, thanks Stan! I think the same applies if we're adding a
ValidityTime TLV at an intermediate hop. I think we can say "strip out any
ValidityTime TLV before calculating the ICV". That applies at the
originator too. Opens up to potential attack where validity time is
manipulated, just need to remember to add that in Security Considerations.
Oooh, right! Good catch.
Similarly, does it work the same way if an intermediate router adds the
AckReq address into the address block, and adds an extra value in the
AddressType TLV to indicate this is the AckReq address? Can we be sure that
removing the address and the extra value in that TLV will put the message
back to how the originator created it? This one feels wrong. I might have a
half-written email drafted for MANET to ask about this...I'll check later.
Oh, oof, that’s a good point. I agree that [manet] is probably the right
place to continue that train of thought.. :)
Hopefully a simple case of finding the text that got removed and
2- re-adding hopcount and/or(?) hoplimit to the draft
re-adding it? I'll figure this one out tomorrow.
3- fancy generic metrics like OLSR does it (see also RFC7185)
Is this worth the effort? I'm not opposed, I'm just worried that it
opens a pretty big rathole.
Is it? OLSRv2, as far as I understand, basically says "here's a metric
tlv, put whatever metric type you want in it, but you're only going to use
one metric type in this whole deployment, so you dont need to indicate the
metric type number itself".
I think we can do similar, effectively saying "use the type extension
field to indicate metric type" (like we do currently), "make sure you only
use additive strictly increasing cost metrics else LoopFree wont be
suitable“,
The point where I got confused was that we still need Cost(L), which is
easy for hopcount but I have no idea how we’d do that for other metric
types? I’m sure OLSR has the answer but I haven’t found it yet.
Good point. We never got that far with any other metric :/
Ok let's leave the rathole alone for now! lets get 1-2 done first hehe! :)
Kind regards,
Vicky.
and "make sure your entire deployment uses consistent numbers for each
metric type, (ideally we'd have a table of metric types so that people can
use the same type numbers.
Maybe that's the rat hole!!!? Or is it not so bad, now that we're looking
at the experimental space?)
Not sure about that, RFC7185 says:
In a well-designed network, all routers will use the same metric
type. It will not produce good routes if, for example, some link
metrics are based on data rate and some on path loss (except to the
extent that these may be correlated). How to achieve this is an
administrative matter, outside the scope of OLSRv2.
… So that might be fine? Maybe we should revisit this discussion on
[manet] :) If you can find the time & energy to write something along the
lines of what you’ve outlined (and run it by the manet list) that’d be
great, but if not I don’t think it’s an absolute must?
Same....but once we sort out the regeneration issue, hopefully it will be
4- Improving the security considerations? Especially considering BCP107
I think I can figure out 1 (might need help with the details), I’ll
probably get confused by 2 (but Vicky’s really good with that kind of
stuff?), I’ve noticed I’m in way over my head with 3 and regarding 4– I
think Key Management is too difficult of an issue for someone who is
learning about that kind of stuff in class just now, but I might be able to
contribute to other parts of the security considerations.
Did I miss anything? Does someone want to shepherd a certain task? (Do
you want to continue at all? ^^)
To be honest, I'm in something of the same boat you are with regard to
key management - I'm not a security expert, and I don't play one on TV...
;-) Maybe we should just admit we're novices here, and beg for help
on-list? Does anyone have other recommendations?
easier to all work together to iron out the remaining security issues?
Let's tackle 1-3 first?
I’m in :)
Kind regards,
Lotte
Kind regards,
Vicky.
(Yes, I want to continue. I'd like to see the draft published, and see
the WG break the logjam.)
Regards,
Stan
Best,
Lotte
