Project

General

Profile

Bug #5047

Router should reject /localhost prefix registration

Added by Junxiao Shi 7 months ago. Updated 4 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
RIB
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Steps to reproduce:

  1. Connect to a testbed router over TCP.
  2. Send a prefix registration command for /localhost/nfd/rib.
  3. Disconnect.

Expected: the prefix registration command should be rejected because /localhost Interest cannot be forwarded to a remote router.
Actual: the prefix registration command succeeds; after disconnecting, HTTP status page stops working and shows 504 error.

History

#1

Updated by Junxiao Shi 7 months ago

Although the reason this registration could succeed is #2856, this issue is not a duplicate of #2856.
Management should prevent /localhost registration to a non-local nexthop.
Management should prevent its own prefixes from being registered to somewhere else or being unregistered.

#2

Updated by Eric Newberry 4 months ago

  • Status changed from New to In Progress
  • Assignee set to Eric Newberry
#3

Updated by Eric Newberry 4 months ago

One issue presenting itself as I work on this is determining the face scope from the RIB. Since the RIB manager runs in a separate thread from the rest of management, we shouldn't directly use the FaceTable from the RIB manager, as can be done in the FIB manager to get this kind of face information. Any suggestions on how to proceed? One idea I had was issuing a request for face scope information from the RIB manager to the Face manager and using this information to accept or deny the request.

#4

Updated by Junxiao Shi 4 months ago

The best solution to note-3 is to finish #4529 first, so that you can access list of faces directly from RIB management.

#5

Updated by Davide Pesavento 4 months ago

Junxiao Shi wrote:

The best solution to note-3 is to finish #4529 first, so that you can access list of faces directly from RIB management.

FaceTable is not/will not be in the mgmt thread, so I'm not sure how #4529 would help.

#6

Updated by Junxiao Shi 4 months ago

Reply to note-5:

Management thread can lock data structure of main thread and read it directly. FaceTable is lockable and readable through this mechanism.

#7

Updated by Davide Pesavento 4 months ago

Junxiao Shi wrote:

Management thread can lock data structure of main thread and read it directly. FaceTable is lockable and readable through this mechanism.

yeah, I wouldn't call that "directly accessing the table"... Also if you just want to add locking you can do that without #4529.

Also available in: Atom PDF