[aodvv2-discuss] Re: Final sprint

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Fri, 22 Apr 2016 23:36:21 +0100

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

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




Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 04-2016