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!
On Fri, Apr 22, 2016 at 11:15 PM, Stan Ratliff <ratliffstan@xxxxxxxxx
<mailto:ratliffstan@xxxxxxxxx>> wrote:
Lotte,
On Fri, Apr 22, 2016 at 5:53 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx <mailto: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.
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.
2- re-adding hopcount and/or(?) hoplimit to the draft
Hopefully a simple case of finding the text that got removed and 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“,
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?)
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?
Same....but once we sort out the regeneration issue, hopefully it will be
easier to all work together to iron out the remaining security issues? Let's
tackle 1-3 first?
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
