NetReg Update Project Status and Design Choices

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/Syste m+and+Network+Security Other comments: Saskia Etling saetling@berkeley.edu