NAT Model, Act I

[lukasjuhrich]

Child of #73.

Goal

The schema's hard relations plus constraints (not including constraint triggers which call functions!) should be implemented as intended in shreyders POC:

Tests are required. Target branch is nat_schema.

Tasks

• Consolidate Changes from 72c0fc7
• Include remarks from @sebschrader made in private conversation (something something ISID-Information is missing)
• Add a primitive Test and a suitable test fixture
• Add tests for every constraint
• Add tests for Delete cascades

[lukasjuhrich]

We have to cover the following use cases:

• Legacy/Wired: Access-Switch is configured to ask Hades, Hades responds with 666 or the /Dorm-VLAN/.
• NAT/Wired: Access-Switch is configured to ask Hades, Hades responds with 666 or the /User-VLAN/ (corresponding to his ISID)
• NAT/Wireless: WLAN-Controller gets 802.1X auth (⇒User.login), needs corresponding ISID(?)

[sebschrader]

Our current and future switches, access points, and WLAN controllers don't support dynamic I-SID assignments via RADIUS. Only VLANs can be assigned dynamically via RADIUS. VLANs can be associated statically with I-SIDs on the switches however. So users can be indirectly assigned dynamically to an I-SID via RADIUS through the use of VLANs.

The VLANs have only local significance on the particular switch. So the VLAN ID to use depends on the NAS (Network Access Server) in RADIUS parlance, the user tries to connect to. We need at least a wired VLAN ID on their home switch and wireless VLAN ID on the WLAN controller for each user.

In summary:

• Each user has a layer 2 domain
• The L2 Domain has an I-SID associated with it
• The L2 Domain has multiple NAS-specific VLAN IDs

[lukasjuhrich]

I would argue that not every user „has“ a layer 2 domain – instead, layer 2 domains (internal_network) can be associated to a user. Remember that only a subset of our users will join the new network model, others may still be oblivious to that information.

Proposition

Okay, so I propose the following changes:

• Add a isid(int isid, string? name) relation representing the pool of all available isids
• Add an FKey internal_network.isid → isid.isid
• Add a translation isid_wired_vlan(int isid, int nas_id, something vlan) (isid, nas primary, FKey isid → isid.isid)
• Add a relation isid_wireless_vlan(int isid, something vlan) (primary&&fkey isid, vlan unique)

Left to decide

• Do we want a constraint that every isid must have a complete set of mappings with every nas?
• Do we want hard FKeys to the vlan relation? The latter is currently used for the per-dorm-vlans only, now the „NAT wired“ and „NAT wireless“ use cases would be added
• If yes, do we want a constraint checking that each vlan is exclusively associated to either
  • a subnet (legacy-model) or
  • an isid_wired_vlan (nat-model) or
  • an isid_wireless_vlan (nat-model)?

I'd argue that the third point is overkill, but the second might be useful. By having nullable possibly empty backrefs VLAN.subnets, VLAN.isids, the UI can easily inform about which „kind“ of vlan this is (see #334).

[lukasjuhrich]

Since I repeatedly lost the overview about which checks etc. to implement, I reconstructed the feature list of the model in this .org-gist (update: see this expanded PDF version).
Also interesting for #331.

I'll try to split those features up to get a precise definition of what has to be done for an initial deployment of the (unfinished) model.