[aodvv2-discuss] Re: Hangout in progress?

  • From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Sun, 3 Apr 2016 14:35:56 +0200

Hi Charlie,

Am 02.04.2016 um 17:54 schrieb Charlie Perkins 
<charles.perkins@xxxxxxxxxxxxx>:

Hello folks,

Please excuse my absence from these emails over the last day or so, but it's 
been hectic.  I'm on the way to the airport, and I will try to make further 
reviews and send them from Houston airport.


I figured you (and Vicky and Stan and Justin) are busy with IETF95-related 
stuff, so I’m not expecting any replies… 
I hope I’m not spamming too much! :(

What is the current resolution for the TODOs in the Security Considerations?

Well, we’ve resolved he DoS TODO with the help of your comments (see 
https://github.com/Lotterleben/AODVv2-Draft/commit/92b1815c01975c72cf3bdf8bf658feb3b5ce15f7),
 but other than that, they’re still there :) I’m inclined to publish asap, with 
or without resolving them. (I’ve commented them out for now, though, so they 
won’t appear in the Draft)


Is it important to update the E2E security draft?

Regards,
Charlie P.


On 4/2/2016 6:28 AM, Lotte Steenbrink wrote:
Hi all,

Am 04.03.2016 um 19:21 schrieb Lotte Steenbrink 
<lotte.steenbrink@xxxxxxxxxxxx <mailto:lotte.steenbrink@xxxxxxxxxxxx>>:

Hi all,
for those who couldn't attend, a quick summary of what we've talked about 
(and what I remember, so please add stuff that's missing...):

* Lotte is currently writing up a response to Justin's review send to 
[manet] which will contain some clarifying questions, comments & also 
suggestions to improve things to check if that's what the WG had in mind
* Editorial pen has ben passed to Lotte
* we went through Justin's comments that were marked as JWD! since we 
figured those were the urgent ones and decided:

(AODVv2_INTERFACES isn’t defined before now it should be. Also what does 
this configuration consist of? Also is the list empty if there is  only one 
interface? JWD!)
Charlie will propose some text


Regarding this one (all other JWD!s are resolved now, yay :) ):

(How does one know which outgoing interface is the neighbor associated 
with?  This seems like a very LARGE missing piece of required information 
JWD!)
That's a big one. I think we've decided to  add an entry Neighbor.Interface 
to the neighbor table and add an instruction to 6.3.  Neighbor Table Update 
that says: 

   o  Neighbor.Interface := Interface on which the RREQ or RREP message was 
received

(plus add checks for Neighbor.Interface being correct everywhere Neighbor 
is used) ?
I'm guessing we'll also have to link this to AODVv2_INTERFACES once we've 
defined that one properly.

I’ve made the following changes so far:

in 4.3.  Neighbor Table:
add 

   Neighbor.Interface
      The interface on which the link to the neighbor was established.

in 6.2.  Next Hop Monitoring:

change from:

 When an RREQ or RREP is received from an IP address
   which does not already have an entry in the Neighbor Table, a new
   entry is created as described in Section 6.3.

to:

When an RREQ or RREP is received and the Neighbor
   Table has no entry where:

   o  Neighbor.IPAddress == IP address from which the RREQ or RREP was
      received

   o  Neighbor.Interface == Interface on which the RREQ or RREP was
      received.

   a new entry is created as described in Section 6.3.  

in 6.3.  Neighbor Table Update:
add 

   o  Neighbor.Interface := Interface on which the RREQ or RREP was
      received.  MUST equal Interface.Id of one of the entries in the
      InterfaceSet (see Section 4.1).

and

   If the message is one of the following:

   o  an RREP which answers a RREQ sent within RREQ_WAIT_TIME over the
      same interface as Neighbor.Interface

   o  an RREP_Ack which answers a RREP sent within RREP_Ack_SENT_TIMEOUT
      over the same interface as Neighbor.Interface


…But I’m wondering if that’s enough? LocalRoute.NextHopInterface is never 
actually used, and it should be. But I can’t find the right section where 
LocalRoute.NextHopInterface and Neighbor.Interfaceshould be „tied together“… 
I’ll continue my search, but if anyone has a pointer that’d be great! :)

Regards,
Lotte



(There wasn’t any text above and it’s not clear how this is enforced.  I 
have an idle route and an unconfirmed route, the unconfirmed route is 
updated to confirmed, I now have two valid route entries and no way to 
demote/decide or otherwise purge one of them but I’m not allowed to do 
that.  Setting the worse and previously idle route to unconfirmed seems 
wrong and broken. JWD!)
Another big one, Vicky said she thinks there is some text in the Draft that 
actually solves this and said she'd look it up, in case that's not enough 
I've written this down in an unsent e-mail:

Ouch again. Unless I oversaw something, the Neighbor Table updates never 
actually "travel back" into the routing table, do they? I would've expected 
section 6.3. to say something like

   When the link to the neighbor is determined to be
   bidirectional, the Neighbor Table entry is updated as follows:
   
   [...]
   for all routes in the Local Route Set with this neighbor as 
LocalRoute.NextHop, the following changes must be applied:

   o  if LocalRoute.State := Unconfirmed, set LocalRoute.State := Idle

   o  if LocalRoute.State := Invalid, set LocalRoute.State := Idle [<== Is 
this a good idea though?!]

and

   When a link to a neighbor is determined to be broken, 
   o  the Neighbor Table entry SHOULD be removed.
    o  for all routes in the Local Route Set with this neighbor as 
LocalRoute.NextHop, LocalRoute.State MUST be set to Invalid

... Would that resolve the issue? (also, why do we have neighbor *tables* 
but local route *sets*? aslo, I'm thinking we should define what a "broken 
route" is.)

(perhaps I’m missing a table or something but I don’t remember any RREQ 
table or list being described which i can check if a RREQ has been recently 
sent with associated timers. If there is such a table then it should be 
mentioned here. If there isn’t aon there should be. JWD!)
Fix: add reference to multicast route message table

(What are we checking! What table or timer is there to check? JWD!)
Fix: add reference to multicast route message table: if no RREP matching 
our RREP_Ack is found there, no actions are required (as the RREQ was 
unsolicited and should thus be ignored).
Buuut, as I'm typing this, I'm wondering– some RREPs are unicast and would 
thus not be in the Multicast table– is this a problem? I'm thinking it 
wouldn't because neighbors whose bidirectionality is unconfirmed get their 
RREPs via multicast, but then the document shouldn't say:

"and RREP messages may be multicast when the link to
   the next router is not known to be bidirectional.
"
in section 4.6, should it? I think we should change the "may" to "will".

(How is this done?  There is no table with recently sent RERR messages to 
check. There needs to be though. JWD!)
Fix: since RERR are always unicast, they're not in the multicast table, so 
we need to track them separately.
Charlie will write some text for such a RERR table. Note that the existence 
of this table (or not) is not an interop issue.

   3.  Check if there are unreachable addresses which MUST be reported
       in a regenerated RERR
(How do we check? It’s not at all clear how this is done. JWD!)
Fix: a few paragraphs earlier, the draft says: 

       If any of the above are false, a matching LocalRoute MUST NOT be
       made Invalid and the unreachable address MUST NOT be advertised
       in a regenerated RERR.

We figured the word "Check" is a bit misleading here, so we'll change that 
to "If there are UnreachableAddresses identified in step 2,..."

   4.  For each LocalRoute that needs to be reported:
(it’s not clear how we know which localroutes need to be reported JWD!)
Similar to the issue above: add "as identified in section 7.4.2."

Regards,
Lotte



Other related posts: