A free C++ implementation of NSIS protocols

Opened 8 years ago

Closed 8 years ago

#128 closed defect (invalid)

Timing issues with Refresh_QNode and multicast

Reported by: stud-lenk Owned by: bless
Priority: minor Milestone:
Component: GIST Version: 0.97
Keywords: multicast Cc: micha.lenk@…


Currently a Querying Node receiving a Response in state Established restarts the timer Refresh_QNode (see ntlp/src/ntlp_statemodule_querier.cpp, rev. 4487, Line 760). This is okay for unicast.

For multicast this is an attack vector for malicious Responding Nodes. Such a malicious Responding Node can try to send a Response in advance of having received a corresponding refreshing Query. With the current implementation this causes the Refresh_QNode timer on the Querying Node to be restarted and no refreshing Query to be sent before the new timer expires. Hence other concurring Responding Nodes will not receive a refreshing Query in time and will expire their routing state, which causes them effectively to unintentionally drop out of the signalling session.

An obvious fix for this particular issue would be to simply not re-start the Refres_QNode timer in this situation. But if you do so, you have to keep in mind that the peer's RS validity times are not granted to be equal. So in case the peer being handled has a lower RS validity time than the previous peer (the one causing the last state transition), the code must ensure that it sends a refreshing Query before this lower RS validity time expired.

Change History (2)

comment:1 Changed 8 years ago by bless

I don't think that this is correct. One cannot send a Response in advance to Query, because the Query Cookie validation will fail. Only "fresh" responses will be accepted.

comment:2 Changed 8 years ago by bless

  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.