[aodvv2-discuss] Re: Final sprint

  • From: John Dowdell <john.dowdell486@xxxxxxxxx>
  • To: AODVv2 Discuss <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Wed, 27 Apr 2016 22:23:40 +0100


On 25 Apr 2016, at 18:01, John Dowdell <john.dowdell486@xxxxxxxxx> wrote:

Hey Lotte

On 24 Apr 2016, at 16:05, Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx 
<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:

Hi John,

Am 23.04.2016 um 09:13 schrieb John Dowdell <john.dowdell486@xxxxxxxxx 
<mailto:john.dowdell486@xxxxxxxxx>>:

All

Sent from my iPhone

On 22 Apr 2016, at 23:36, Victoria Mercieca <vmercieca0@xxxxxxxxx 
<mailto:vmercieca0@xxxxxxxxx>> wrote:

Hi Lotte,

Did I mention you're brilliant?! 

+ infinity to that

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? 

I'll take a look at BCP on Sunday morning. I know people who do key 
management for a living. However also good to plead ignorance to the list 
and ask for help.

I think that’s the way to go. Did you hear back from your key management 
specialists yet? In any case, could you maybe craft a reply that says “We’re 
not experts on this, I’m asking experts right now and would also love to get 
your help” so we can move this off aodvv2-discuss? 
(https://mailarchive.ietf.org/arch/msg/manet/A9w-8Dq3FaR2u4qi8hhSDgdn2_o ;
<https://mailarchive.ietf.org/arch/msg/manet/A9w-8Dq3FaR2u4qi8hhSDgdn2_o> is 
the thread) I think you’d be the best person to do this since you’re the one 
with experts to ask :)

Best regards,
Lotte

I haven’t asked yet, but I did read BCP107 which is (thankfully) not a long 
read. It basically guides you in choosing automatic or manual key management, 
and for us it’s pretty cut and dried that it should be automated management. 
I’ll write that up when I get a moment and file it on manet list (BTW I agree 
that we should now show our working there). Is there anything else 
security-wise we need to be looking at?

Regards
John

Just to update, I’ve now posted a review against BCP107 on the manet list.

If there’s anything else security-wise that causing an issue, please feel free 
to push it in my direction.

Cheers
John


Regards
John




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: