Rethinking Routing Security in Named Data Networking

JACOB ZHI’S CAPSTONE PROJECT

​

presented by Lixia Zhang

The existing implementation

• NFD keeps the following state:
• List of faces
• FIB
• RIB
• Control commands, implemented as signed Interests, are used to set and modify the state; NFD verifies Control commands using some trust policy.
• The prefix registration control command adds entries to NFD’s RIB.
• All control commands share the same name prefix, followed by the command type and wire-encoded parameters to form the Interest name.
• Inflexible encoding, making it hard to write a trust schema that defines policy over the space of registration parameters.
• Easy wat out: resort to simply allowing anyone with a valid network certificate to register a prefix.

NDN routing: another application built on NDN

• Security support are/should be intrinsically built into all apps
• Like all other application, routing as an app runs on top of forwarding
• all routing announcements are named, secured data: producers sign, and receivers verify
• Producers announce their prefixes, routing daemon authenticate and authorize
• Forwarders should not be involved in handling routing requests/updates.
• What do current NDN routers do?
• Data producers talk to the local NFD directly through control commands
• The local NFD authenticates and authorizes the request by its signature, accepting and storing the prefix
• The NFD “readvertises” the prefix to NLSR
• NFD does not know routing policies; the above involves back-and-forth communication between the two parties

​

​

​

Separation of Routing and Forwarding

• A routing entity is concerned with receiving, propagating, verifying, and applying policies for route information
• Data producers logically should talk with the routing entity if they want their prefix to be reachable in the network rather than just locally
• Forwarder (ideally) only needs a FIB, exchanges management info with the routing entity only.
• The routing entity may be remote; we should not require all forwarders running a routing daemon

The basic difference existing and new designs

• Eliminated the complexity of involving the forwarding module in routing functions
• The Forwarding module does not inherently depend on the routing module. There should still be forwarding management, which authenticates/authorizes the control, either from a router or a local app
• Making routing an app on top of forwarding enables flexibility in routing security
• Systematically define trust policies as any other apps

NFDc package unchanged?

NDN autoconfigu issue?

The new design

• 2 steps for routing info to propagate through a network
1. Producers pass their prefixes to routing
2. Routers propagate prefixes

This work focuses on step-1; step-2 is determined by the routing protocol in use

• Producer-Forwarder Security: local prefix insertion interest, no security checking
• Producer-Router Security: Prefix Insertion
• Implemented for ndnd
• Move away from signed interests with control command in the name (Difficult to write a trust schema for this)
• Utilize ApplicationParameters field to carry signed data

​

​

• The name of the prefix to add to the RIB
• Validity range of the prefix insertion encoded as a relative duration and/or absolute timestamp.
• The cost of reaching the data producer from the router.

​

Making prefix insertion request as versioned data simplifies (compared to tracking signed Interests)

To address the initialization-order problems (if certificates are unavailable until their prefix, and all other required prefixes in the verification chain, are added to routing, data producers can attach certificates to the prefix insertion

​

​

prefix registration protocol’s control command (signed interest)

prefix insertion protocol uses Interest to carry the insertion request as named, secured data

Prefix insertion

• The routing daemon dv informs its local forwarding module of a well-known keyword prefix /routing/insert.
• prefix insertion packet (an interest) sent to the router’s node reaches routing.
• When a data producer sends an interest with prefix /routing/insert to the local forwarding module, it will reach the co-located routing module if it exists.
• If no routing module is running locally, a default route will be used to forward the interest to the next hop router, which should have a co-located routing module.
• Another option is to forward the insertion interest to all out-faces

New routing security design gives ISPs flexibility

• Routing is more flexible because we are moving towards an understanding that routing is just an NDN application with a systematically-defined trust policy
• Systematically-designed trust policy over the desired prefix enables various ISPs to more easily encode trust models for who is allowed to claim what name

Examples:

• Role-based: Nodes with certificates matching a certain name or on a certain list are allows to announce names matching certain patterns
• E.g., standard users cannot announce any prefix, other users are allowed to announce certain names after requesting authorization out-of-band through a domain certificate challenge
• Application hierarchy-based: Nodes can only announce names corresponding to their certificates’ identities
• The router will use the hierarchical rule to trace back to the ISP-issued certificate for the application
• This assumes applications are authorized by an ISP, and applications are issued a certificate with ISP as signer