NetReg

1. NetReg Update 10/10/11

2. NetReg update • Project Status and Timeline • Background • Design choices • Use cases • Public wiki coming soon

3. Status and Timeline • Data model and design issues finalized • Back-end, house-keeping and conversion scripts tested by January. • Finalized UI design by January.

4. 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

5. 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

6. 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.

7. 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

8. 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?

9. 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.

10. 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

11. 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.

12. 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

13. 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.

14. 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.

15. Public wiki • Coming soon to SNS wiki • https://wikihub.berkeley.edu/display/sns/System+and+Network+Security • Other comments: Saskia Etling • saetling@berkeley.edu