NetReg

Update 10/10/11

NetReg update

• Project Status and Timeline• Background• Design choices• Use cases• Public wiki coming soon

Status and Timeline

• Data model and design issues finalized• Back-end, house-keeping and conversion

scripts tested by January. • Finalized UI design by January.

Background

• Combining existing Security Contact, DHCP registration and RDM applications

• NetReg models reality but does not change it– Except for DHCP service

• Contact role (CR) can– Claim IP Addresses (for security notices)– Register devices (for DHCP service)– Register Restricted Data (RD) systems

Types of Contact Roles

• Department Contact Role (DCR)– Are at a node in the org tree

• Group Contact Role (GCR)– Have a parent DCR

• Service provider (SP CR)– Have ‘provides-service’ flag = true

• Individual Contact Role (ICR)– Person registering device(s) for DHCP

Design choices – Contact Roles

• Will allow more than one DCR at org-node– But will encourage use of GCRs

• New DCR creation– Individual has job unit that matches unit of

proposed DCR– If other DCRs at that org-node then choice of

requesting membership or GCR creation, or proceeding w/ DCR. And notify other DCRs.

• Individual contacts (ICRs) cannot be, nor have service providers.

Design choices - IP addresses

• Conversion of overlapping IP address claims:– CR with majority of IP addresses will get

subnet– Others are claimed subnet exceptions– Will issue report to CRs, for review, prior to

conversion

• ICRs cannot claim IP addresses– Can register devices, RD Systems

Design choices -Subdomains

• Can claim IP addresses via subdomains– No. However CRs can register subdomains

so that notification can be sent when IP address in CR’s subdomain is claimed by another CR

– Do you want to:• Rename host?• Or initiate IP address transfer?

Design choices - DHCP

• Department converting to DHCP registers all IP addresses into LIPS.berkeley.edu– (possible new Dept. DHCP service)

• CR cannot claim IP address space in LIPS.berkeley.edu– Security notification by registered device in those

cases.

• Device has one interface.– If it has two wired interfaces then registered as if

two devices.

Design choices - RD systems

• RD Systems comprised of devices– not other RD Systems

• RD partners can add/remove component devices– Cannot change restricted data category on

device

Design choices – Notification

• Can I get security notices of another CRs IP addresses on the same subnet as mine?– No – security contact has responsibility to respond.– Ask to be a member of the other CR.– Ask to be on other CRs email list.

• CR that claims a subnet can get courtesy notice of security incidents involving device using LIPS.berkeley.edu IP address.

Use Cases: GCR

• DCR and GCR have same privilege• When responsibility for responding to

security incidents is separate• Use to segregate devices for receiving

service provider support• Organize membership to provide service• For registering a RD System

– The RD registrant is not the same as the DCR

Service Provider CR

• DOCS, others provide management service to Departments

• Pointer to service provider puts its email address and member list into the client CR.

• Service provider members have ’device’ privileges in client CR

• Notices to both• Security incidents count for both

– Distinguish between ‘your systems, your systems managed by others’.

• Can be a service provider OR a client, not both.

RD Partner

• RD registrant ≠ CR• CR should know of RD on its devices• RD registrant builds RD system out of devices

– By MAC, IP address, hostname– If device registered, or IP claimed by another CR, that

CR becomes RD Partner in RD System

• RD Partner can add/remove devices to RD System

• Notifications will go to RD registrant and RD partners.

Public wiki

• Coming soon to SNS wiki– https://wikihub.berkeley.edu/display/sns/

System+and+Network+Security

• Other comments: Saskia Etling– saetling@berkeley.edu