- What are 'read/write' vs. 'read-only' privileges for members in a contact role?
- What are Group Contact Roles used for?
- What are Service Provider Contact Roles and how do they work?
- How are security notices routed?
- Does the application support IPv6?
- Does the application support DHCP registration?
- What is the process if another contact is non-responsive when I want to claim or transfer something immediately?
- Security contact X and my security contact used to both claim subnet A. Why can't we still do that?
- Why can I see the name of another security contact that claims an individual IP address on some subnets but not on others?
- Can you display the email address of the other security contacts so I can contact them directly?
- What are the different types of email generated by NetReg? Can I opt out from receiving any/all of them?
- I've received an "IP address to transfer" message. Can you explain what it means and what I need to do.
- Can I self-register Fixed IP address assignments?
- Can I self-register Dynamic DNS hostnames?
A member of a contact role can be 'read-only' within the contact role, which means he or she cannot edit anything. A 'read-write' member on the other hand, can approve or deny requests, make additions and edits to the contact role itself or any registered network assets.
A Group Contact Role (GCR) is created by a Department Contact Role (DCR) when a separation of responsibilities is needed. Each DCR will have an org node set, and the GCR will be associated to the department via its parent, the DCR.
A Group Contact Role can be used to help departments separate devices into sets that receive (or do not receive) IT support from a Service Provider Contact Role (SP CR). Additionally, when responses to security incidents is the responsibility of different groups (e.g., a research lab within a larger department, a student systems vs. an admininistrative one) a DCR can create a GCR to receive targeted notices.
Service Provider Contact Roles (CRs) are a special purpose contact role. As a service provider, they don't have registered network assets, but they are flagged within NetReg as providing support for another CR. For example, the Service Provider CR might register devices for the Client CR. Service Provider CRs have "device-based" privileges with the Client CR; they can create, edit and delete devices from the Client CR.
Service Provider CRs can be grouped or departmental. Notifications about security events (compromises, vulnerabilities, etc.) will go to members of both Service Provider and Client CRs.
Security notices are routed based upon the most specific registration information available in NetReg.
For example, if an IP address has a registered security contact, the security notice is sent to that contact. If there is no specific IP address registration then the notice is sent to the security contact that claimed the subnet. Notices will also be sent to:
• the registrant contact role's service provider if any
• its departmental / parent contact role if any,
• and any contact roles that have 'CC CR' status for the IP address
OR, if the IP addresses is for a DHCP device (in the LIPs subdomain) the security notice will go to whomever was using the address at that time (to CalNet ID).
DHCP registration was added to NetReg in Oct 2015. For instructions on how to use NetReg to register devices for use with the Campus DHCP Service, please visit the "Register Devices" page in the NetReg documentation.
Overlap is not allowed in NetReg. If two departments share a subnet, during the data conversion the department who claims the most IP addresses for that subnet will get the entire subnet. The other department will get individual IP addresses.
Additionally, one CR will own and be primarily responsible for an IP address, although other CRs may be provided shared notification..
For complicated situations, e.g., where two different groups are responsible for systems on a subnet, a Contact Role created just for that shared responsibility might be the best solution.
NetReg is designed to facilitate communication between security contacts for the purpose of keeping network registration information up-to-date, without revealing private security mailing list addresses or allowing out-of-band communication between security contacts on other issues.
If you claim the entire subnet you can view the names of the security contacts that claim individual IP addresses on that subnet. If you only claim an individual address then you cannot see the names of the other security contacts.
No. Requests for IP addresses, CC IP Address status are handled via the request/approve/deny process. Any other communication issue can be handled by contacting ISP.
There are three types of email generated by NetReg:
- FYI emails: These emails are rolled up into a single digest which is sent once per day. Users can opt out of receiving the digest by setting "Receive FYI digest" to off. However, at least one CR member should continue to receive them.
- Notices of "requests to approve or deny": These are sent within 5 minutes from when the request is made via the NetReg application, and are sent to all members in the CR. Users do not have the option to opt out of receiving these.
There are 4 kinds of "requests to approve or deny" which users may receive:
- Request to transfer an individual IP address. (Note: the request can be initiated by either the CR that currently claims it (request to give), or by the CR that wants it (request to take).)
- Request for CC CR status for an IP address
- Request for membership within a CR
- Request to create of a group CR within a department CR
- Notices to "outside" entities (i.e., ISP RT ticketing system, Hostmaster, or IT Policy): These are initiated by NetReg backend processes or sometimes by NetReg users and are cc'd to any relevant CR's membership.
For example, when a request is made for a new departmental CR the request will go to Information Security and Policy (ISP). ISP will conduct an intake process and will create the DCR.
You've received the message because Netreg has encountered a mismatch between the security contact that claimed an IP address (individually or by subnet) and the security contact that registered a subdomain.
(Note: In Netreg the assignment of a subdomain enables the transfer of IP address responsibility to the right party, but does not assign security contact responsibility).
For example, if security contact A registers a subdomain xyz.berkeley.edu and another security contact B claims subnet a.b.c.0/24 and there is a set of hostnames defined in DNS:
security contact A and B will each get a message suggesting that the IP addresses be transferred from B to A.
Either security contact can initiate the transfer: Security contact A can 'request to take'; B can 'request to give'.
If the other party agrees and approves the transfer then B ends up with the subnet and A has 3 individual IP records out of that subnet because of its subdomain registration.
Remember: NetReg does not automatically make the transfer because there may be alternate solutions to resolve the discrepancy. In the above example, security contact A could relinquish the IP addresses, or have their DNS hostname changed to something not in the xyz subdomain.
You are receiving this "IP address to transfer" message so that you can choose the best solution.
Department and Group Security Contact roles can register devices for Fixed IP address assignment – where a device always gets the same IP on its primary subnet, but a Dynamic IP on any other subnet – provided that the contact role has a registered subnet, with available IP address space, and a registered subdomain.
For details about registering devices for Fixed IP address assignment, please review the "Register Devices" page in the NetReg documentation.
Yes. Security Contacts can assign a Dynamic DNS (DDNS) hostname to a device when using Dynamic IP addressing (DDNS is not available for devices registered with a Fixed IP address assignment). Please review the "Register Devices" page in the NetReg documentation for details.
Note: Dynamic DNS hostnames will be reviewed by the campus hostmaster and changed if inappropriate.