USER LOGIN

The redirection of a user to a configured login page when the user first accesses the provider’s network. This can be via a wireless connection or via a fixed LAN (Local Area Network) connection.

The login page can provide appropriate field validation and user authentication based on an administration interface. For instance, the Mediation Device / Unit could be connected to a Radius server (Remote Authentication Dial In User Service) as configured by ITL, for authentication purposes (after stripping leading and trailing whitespace).

Users can bypass the login page based on an IP (Internet Protocol) address and/or URL (Uniform Resource Locator) details, e.g. the user device IP address is in the privilege IP address list or the user is accessing an URL which is in the privilege URL list. If the user enters an URL which is not in the privilege list, then the user could be automatically redirected to the nominated login page.

The user is allowed to read the Terms and Conditions (stored and editable by the provider) and accept these before logging into the provider’s network.

Access control logic can be provided by ITL to ensure that only one login per user across the whole of the provider’s network is possible (including the telephony system). This could be achieved by communicating with a Radius server, for instance.

After login, the user can be redirected to an URL that the provider specifies, on a unit by unit basis. The Mediation Device will enable privileged users to be registered so that they are ‘optionally’ able to bypass the login page. The device could also support 'walled-garden' system logic, enabling users to have access to certain web pages without requiring login.

USER AUTHENTICATION AND SERVICE ENTITLEMENT LOGIC

Users supply a valid user name and PIN to enable the provider to ascertain their service entitlement and their upload and download credit (Megabyte allowance).

The mediation device could have an interface to a central billing platform to obtain the details above and log off the user when either the upload or download credit is spent.

Note: if required, if the user has met all the above listed criteria, the user may not be allowed to use the service if the Fair Usage Policy (FUP) for the subnet decides to auto logoff the user, as the user has reached the FUP limit for the day.

The user could be alerted when their ‘free’ entitlement is over and they are now paying for the service and are about to be logged off the system due to no more available credit.

FAIR USE POLICY FUNCTIONALITY IMPLEMENTED BY ITL

A Fair Use Policy (FUP) can be implemented to handle system limitations such as user contention and limits on satellite bandwidth. The mediation device is capable of invoking scripts when a user logs on to the provider’s network.

The Mediation Device could be configured to apply FUP based on each user on the subnet. The fair use limits for the user have a common start time and are valid for 24 hours before being reset.

The system can be configured to allow for all the variables in the fair use policy to be set by the Administrator user for the device.

These per subnet FUP variables could be, for example:

• Number of concurrent users
   
• Upload bandwidth limit
   
• Download bandwidth limit
   
• Total bandwidth limit
   
• Max session time
   
• Timeouts (see management settings below)
   

Should any of the bandwidth limits be set to zero then that particular bandwidth limit is deemed to be disabled and does not need to be checked as required by the provider.

• Check for user inactivity: the device supports an inactivity timeout setting
   
• Check for excess login time: the device enables this to be configured as part of user allowance settings
   
• Check for excess download: again, the device enables this to be configured as part of user allowance settings
   
• Check for excess session time: can for example, be a Radius server setting – max session time. The device also supports a session timeout setting for hotspots
   
• Check for logout candidates: when the network is oversubscribed – the device includes a feature called Quality of Service (QoS), where users can be bandwidth throttled when they hit a threshold.
   

Example Variables:

• T = Total daily login time
   
• SUM B = Sum of all bandwidth used in that day
   
• ST = Current session time
   

Example Switches:

• MTF = MaxTimeFlag <Hard | Soft>
   
• MBF = MaxBandwidthFlag <Hard | Soft>
   
• MSF = MinSessionTimeFlag <On | Off>
   

Example Management Settings:

• MaxTime = Daily login time allowance
   
• MaxBandwidth = Daily bandwidth allowance
   
• MinSessionTime = Minimum login period (min) (Active in soft limits)
   
• MaxIdleTime = Max period (min) with no user activity
   
• WaitTime = Update period (sec) for T, Sum B and ST
   

Note that the MinSessionTime > MaxTime is not a valid setting and should be rejected.

ADDITIONAL DATA USAGE LOGS

The data to be collected in the device logs could be available from an Accounting server, e.g. RADIUS.

Disk-based logging can be configured to store a fixed number of lines in each log file and the number of logs to retain.

Log files stored on disk are accessible via the device’s FTP server and can be downloaded to a central repository.

Log data containing user sessions and data usage could be stored in a RADIUS Accounting database rather than in device logs.  In addition, the logs could be transmitted to an offline server or retrieved from the server using File Transfer Protocol or secure shell (SSH) commands.

The Mediation Devices could include, for example:

• Monitor the upload, download and total bytes used per user on a per session basis
   
• Each open user session could have the following information: 

o   Date

o   Session start time

o   User ID

o   User IP address

o   Upload bytes

o   Download bytes

o   Total bytes

• Each closed session could have the following information on the mediation device: 

o   Date

o   Session start time

o   Session end time

o   Session time in hours and decimal which is not stored in the database but calculated when required to be displayed

o   User ID

o   User IP address

o   Upload bytes

o   Download bytes

o   Total bytes which are not stored in the database but calculated when required to be displayed

o   Log off reason

 

Each of the closed user sessions can be stored on a central database server.

 

Note: There could be approximately 400,000 closed user sessions per month per mediation device. Scripts can also be written to access individual counter values on a per-user basis.

 

A maximum of 60 days logs could be retained on the unit for example. All log data older than 60 days could be automatically removed from the unit.

MULTI SUBNET SUPPORT

The mediation device could support a minimum of 400 concurrent users across up to 5 subnets, for example.

With a contention ratio of 1:15, the user population wanting to access the service could be as high as say 6000.

The mediation device can support a minimum of say 5 subnets which may vary in size between twenty hosts up to a class ‘B’. It is not expected that the mediation device will be required to support more than one class ‘B’ network per unit.

The Administrator user of the device should be able to configure the Fair Use Policy options on a subnet by subnet basis.

Each subnet can be defined by an authorised user as to the type of service (e.g. Fixed, Wi-Fi, Fulgora); this information can be passed to the central billing system as part of the session authentication process.

The Fair Usage Policy algorithm can enable settings to be configured on a per subnet basis. It is possible to pass the type of service to the RADIUS server as part of the session authentication process.

PRIVILEGE LISTS

 

The IP and URL privilege list could allow the user to:

• Bypass the login process and Terms and Conditions to access the service.
   
• The Fair Use Policy (FUP) is not applied for the duration of the session to the privileged URL or IP address.
   
• The data counters are not incremented during the session to the privileged URL or IP address.
   

If a user decides to go to a non-privilege URL or IP address, then the user should be redirected to the user login page after which the normal authentication and FUP directives apply.

The admin user(s) of the device could be able to input the IP and URLs into the list.

Privilege list functionality can be handled by the Mediation Device’s Walled Garden for URLs and the Walled Garden IP List. The Walled Gardens allow a set of rules to be created to define URLs / IPs that should be accessible without authenticating with the provider’s network.

The Terms and Conditions and SyOPs will need to be defined in the Walled Garden for URLs.

For Walled Garden URLs the following fields could be defined as part of a rule. Multiple rules can be defined. Any field that is left blank will be ignored by the rule.

• Action: Allow or Deny
   
• Server: Allows rules to be defined on a per-hotspot / subnet basis (or to all hotspots if left blank)
   
• Source Address: Source address / range of the user (Hotspot client)
   
• Destination Address: destination IP address / range of the web server
   
• Method: HTTP method of the request (GET / HEAD / POST / PUT / DELETE / TRACE / CONNECT)
   
• Destination Host (accepts wildcard): domain name of the destination web-server
   
• Destination Port: TCP port number on the Destination Host / Address
   
• Path (accepts wildcard): the path of the request. Path comes after http://destination_host/ e.g. http://destination_host/somepath/*
   

For the Walled Garden IP List the following fields can be defined as part of a rule. Multiple rules can be defined. Any field that is left blank will be ignored by the rule.

• Action: Accept, Drop or Reject 

o   Accept – allow access to the resource without authorization

o   Deny – the authorization is required to access the resource

o   Reject – the authorization is required to access the resource. ICMP (Internet Control Message Protocol) reject message will be sent to the client, when the packet matches the rule

• Server: Allows rules to be defined on a per hotspot / subnet basis (or to all hotspots)
   
• Source Address: Source address / range of the user (hotspot client)
   
• Destination Address: destination IP address / range of the server
   
• Protocol: IP protocol number (e.g. ICMP, TCP)
   
• Destination Port: TCP port number
   
• Destination Hosts (accepts wildcards): domain name of the destination server

FAILURE CONDITIONS

Under the following failure conditions, the mediation device could behave as follows, for instance:

• Power failure 

o   The Ethernet Bridge can fail to wire and allow all traffic to pass.

• If communications to the billing platform are lost then 

o   Existing users should continue to use the system until the currently allocated units are fully utilised

o   No new users should be able to logon onto the system

• HW or SW failure
   

Network cards that ‘fail to wire’ in the event of power failure can be used.

In the event of a loss of communication with say the RADIUS server, existing users would be able to continue using the system, but new users would be unable to be authenticated, so would be restricted to accessing privileged web pages only.

As the mediation device will be acting as a router, not as a switch, having the Ethernet interfaces ‘fail-to-wire’ and allow traffic to pass in the event of a power failure is not assumed to be a requirement (as any traffic which passes would require the router’s functionality).

For the mediation device, ITL would propose using standard Ethernet network interface cards rather than cards with Active Bypass network capability.

INTERFACE TO A CENTRAL BILLING PLATFORM

The mediation device can interface to a central billing platform to carry out the following example functions:

• Validate username and PIN
   
• Validate service entitlement
   
• Check credit of download and upload bytes
   
• Update download, upload and total byte counters to the billing platform during and at the end of each user session
   

The platform supports RADIUS and Diameter protocols amongst others.

The unit can behave as a NAS device (Network Attached Storage).

The device can interface to a RADIUS server for username and password validation.

Retrieving data from a device for sending to a billing platform is easily achieved using FTP and SSH commands.

FILE REPLICATION

The unit is capable of replicating files from a central repository. This can for example, be used to provide updates to the login pages.

The mediation device has an FTP server configured which allows and permits access to all the files stored on the device’s internal hard drive.

By default the FTP server only accepts connections from the provider’s LAN network (it is not accessible from the client side). Access can be further restricted to a specific subnet on the provider’s Local Area Network (LAN).

Tools such as FTPSync from Cyberkiko can be used to automate the synchronization of files stored on the device.

The mediation device incorporates an FTP server and includes support for Secure Shell (SSH) commands. This enables HTML files to be uploaded to it from a central management repository.

SECURITY

The device can be configured to use HTTPS as a method of encrypting the username and PIN fields before they are sent to the device from the client browser.

A Private Key and SSL Certificate should be imported into the device before the HTTPS method can be selected to secure the hotspot login process.

The device requires the Private Key and Certificate to be in the .PEM (Privacy Enhanced Mail) format. OpenSSL provides methods for converting various Private Key and Certificate formats into the required PEM format.

The passphrase for the Private Key is also required to allow the device to decrypt the Private Key.

ITL have tested HTTPS / SSL using internet test certificates.

WEB CACHE / PROXY

The unit is capable of working as both a transparent and explicit web proxy.

The explicit proxy functionality can be available when the unit is being utilised as a bridge or ‘bump in the wire’.

Proxy Access Rules:

The web proxy access rules specify a set of rules defining what traffic the web proxy will handle. The rules allow the following criteria, for example:

• Action: Specifies whether to Allow or Deny matching packets
   
• Destination Address: Destination address of the IP packet
   
• Destination Host: IP address or DNS name used to connect to the target server
   
• Destination Port: List or range of ports the packet is destined for on the target server
   
• Local Port: Specifies the port of the web proxy via which the packet was received.
   
• Method: HTTP method specified in the request
   
• Path: Name (or part) of the page / path on target web server
   
• Redirect To: If this rule denies access, the user will be redirected to this URL
   
• Source Address: Source address of the IP packet
   

In testing we defined three rules which allowed the web proxy to handle the two most common traffic types: HTTP, port 80 and HTTPS, port 443. The third rule was used to deny all other traffic types (FTP, GOPHER and SOCKS).

Cache:

The web proxy can store up to 6GiB of cached data on the internal hard disk. The cache can be configured to prevent certain resources from being cached, if required. The cache can be flushed using the Winbox application.

Windows Messenger:

Windows Messenger (aka Windows Live Messenger) requires port 1863, which is not a standard web proxy port and is not supported by the device’s web proxy. As messenger provides no interface to handle the provider’s network login pages, the data consumed by Messenger could not be deducted from a user’s credits if it used port 1863.

Since before 2003 Messenger has been able to use port 80 if port 1863 is not available. The Windows Messenger client that comes with Windows and the latest version (Windows Live Messenger 2011) both work with the web proxy configured to only allow port 80 and 443.

The device will not be configured to allow port 1863. Messenger will use the default web proxy ports instead. Users will be required to login to the provider’s network prior to using Messenger.

Other Information:

The device can support a maximum of 5,000 client-side connections, and 5,000 server-side connections.

It is possible to monitor web proxy sessions via Winbox. One or more sessions can also be terminated if required.

DNS – DOMAIN NAME SYSTEM

The unit can support DNS and dynamic DNS. Administrators are able to easily configure a minimum of:

• DNS Caching
   
• Cache clearing
   
• Authoritative Zones(s)
   
• Hosts
   

The DNS server can support the delivery of a proxy configuration (WPAD – Web Proxy Auto discovery Protocol) file via DNS.

The device can act as a DNS server to its clients. The device requires at least one external DNS server to resolve external addresses. The device can be specified as a primary DNS server for its DHCP clients. Any requests that the local DNS server cannot fulfil from its local DNS database are forwarded to the external DNS server. The results are then cached and returned to the requesting client.

DNS Caching:

The device can cache up to 10MiB of DNS information.

Cache Clearing:

The cache can be cleared using a single command via SSH. It can also be cleared via the Winbox interface.

Authoritative Zone:

The device does not act as an authoritative server for any zones. Host records can be created for any zone / domain, providing DNS for zones that don’t exist in the external DNS, or overriding entries in external zones.

Hosts:

The device supports the creation of static host records. The TTL for the records can also be specified.

The device can store DNS host records as ‘friendly names’ for its hot spots. If you create a hot spot on 10.1.1.1 and would rather, when users are redirected to the provider’s login page, that http://<preferred web address> should appear in the browser address bar rather then http://www.10.1.1.1, the device will create a DNS entry for <preferred web address> pointing to 10.1.1.1 to allow this.

WPAD (Web Proxy Autodiscovery Protocol):

The device supports the delivery of a WPAD.DAT file via DNS.

The DHCP Server should allocate a connection-specific DNS domain for each subnet (e.g. mediation.local). A static DNS record is then created for a WPAD host (e.g. wpad.mediation.local), pointing to the IP address of the hotspot for that subnet. The WPAD.DAT file is stored on the device in the directory containing the hotspot HTML files.

DHCP – Dynamic Host Configuration Protocol:

The unit is able to be a DHCP server with the ability to support multiple concurrent scopes. All DHCP attributes are easily configurable on a ‘per server’ and ‘per scope’ basis with the ability to add DHCP options that are not currently listed (e.g. Web browser proxy configuration).

The device can be configured as a DHCP server to allocate IP addresses to connected client computers. One DHCP server can be configured for each network interface in the device.

The following settings are defined on a per-scope (interface / subnet) basis:

• Lease Time
   
• Address Pool
   
• Default Gateway
   
• Netmask
   
• DNS Servers (recommended to be set to the device’s internal DNS server only)
   
• DNS Domain
   
• WINS Servers
   
• NTP Servers
   
• Domain (this is required for the Web Proxy Auto Discovery to work)
   
• DHCP Options
   

Active leases can be monitored and terminated via the WinBox interface.

SNMP – Simple Network Management Protocol

Support for SNMP V2 traps and MIBs is provided.

Administrators are able to easily configure a minimum of:

• SNMP V2 community strings (multiple RO and RW strings are required)
   
• SNMP trap destinations
   
• Which traps are enabled for sending and which for logging on the unit
   

The unit supports SNMP MIBs to allow Paradigm to query the current system information e.g. CPU load, Ethernet port performance.

The device can be configured to point at several trap destinations by IP address with the option to specify different trap communities. In addition read access can be configured for each SNMP community to allow SNMP OIDs to be queried remotely, providing valuable system information.

‘The Dude’ application has a built in SNMPwalk tool which allows the administrator to a view a column separated of all the OIDs and values located on the device. The SNMPwalk tool provides almost 270 OIDs to read from, create chart data sources and probe data at set intervals. Mikrotik’s MIB is built into the ‘The Dude’ application by default and requires no further configuration.

Currently the device has a few options when firing SNMP traps. It can be configured to fire a start-trap when the router is rebooted. Another option is to send it when the interface changes its state.

‘The Dude’ application is capable of monitoring the current system information and performance without any further configuration.

The device is also able to support query of SNMP variables. The device supports the following MIBs: RFC1493, RFC2863, RFC1213, RFC2011, RFC2096, RFC1213, RFC2790. Partial support is also provided for CISCO-AAA-SESSION-MIB.

SYSLOG

The unit is able to send its logs and SNMP trap information to one or more Syslog servers with definable levels of granularity for each log and the ability to enable the sending of SNMP trap information additionally to one or more Syslog servers.

Logs can be stored locally and the device can be configured to forward the logs to a remote syslog server.

The device can be configured to forward log messages to a Syslog server – defined by specifying the IP address and port number of the Syslog server.

Logging can be configured with rules combining log locations, message severity and device feature. When a log message matches all the criteria in a rule, the message is written to the location specified by the rule.

Locations define where the log message will be written to: echo to console, local disk, Syslog, email or device memory.

Severity defines the class of the log message: debug, info, warning, error and critical.

Features define which part of the system logs the message. Account, System, Hotspot, Firewall, Script, Backup, DHCP, SSH, Web-Proxy.

For example, all Critical messages could be sent via email. All Error and critical messages could be forwarded to a Syslog server. All Warning, Error and Critical messages could be written to a local log file. All informational messages from Script and DHCP could be written to a separate log file.

WEB SERVER

The mediation device provides a web server function. The web server supports delivery of HTTP and HTTPS pages.

The web server is able to deliver both static HTML and ASP. Various scripting languages can be supported. A minimum of VBScript, Java and PHP can be supported for delivery of active content.

The device ships with a number of default HTML pages, which can be configured to change their appearance. These are listed below:

• redirect.html – redirects a user to another URL (for example, to a login page)
   
• login.html – login page shown to a user to ask for username and password
   
• status.html – status page, shows statistics for the client. It is also able to display advertisements automatically
   
• logout.html – logout page, shown after the user is logged out. Shows final statistics about the finished session
   
• error.html – error page, shown on fatal errors only
   

The above pages would be modified to suit the provider’s requirements. There are a number of other pages that may also be configured. These are listed below:

• rlogin.html – page, which redirects the client from some other URL to the login page, if authorization of the client is required to access that URL
   
• rstatus.html – similarly to rlogin.html, only in case if the client is already logged in and the original URL is not shown
   
• radvert.html – redirects client to the scheduled advertisement link
   
• flogin.html – shown instead of login.html, if some error has occurred (invalid username or password for example)
   
• fstatus.html – shown instead of redirect, if status page is requested, but the client is not logged in
   
• flogout.html – shown instead of redirect, if logout page is requested but the client is not logged in
   

The device supports HTML. Support is not provided for ASP, PHP and VBScript. However, the HTML pages can include URL links to external web servers that can support these technologies.

LOCAL SYSTEM SECURITY

• Add users
   
• Delete users
   
• Change a user’s password
   
• Suspend a user
   
• Control which group(s) a user is a member of
   
• Password expiry
   

• Minimum password length
   
• Upper case required
   
• Lower case required
   
• Special characters required
   
• Maximum password age
   
• Minimum password age
   

• Administrators
   
• Operators
   
• Monitor
  

TIME

Local System Time:

The unit has the ability for its system clock to be set to any worldwide time zone and to correctly track daylight saving time for the selected time zone.

The device allows the selection of the current time zone by country, including automatic daylight saving adjustments. The device also supports manual time zone settings should any custom settings be required. Manual time zone settings allow for GMT offset, DST offset and DST start and end dates to be configured.

The time zone settings use the TZ Public Domain database.

Time Synchronisation:

The unit is able to synchronise its internal clock with one or more configurable NTP servers. The interval between synchronization attempts is also configurable by an administrator.

Synchronization can be forced to occur immediately.

The device can operate as an NTP (Network Time Protocol) client in broadcast and unicast mode.

In unicast mode primary and, optionally, secondary NTP servers can be specified. The poll interval can also be configured: the default setting is to poll every 16 seconds. If the device receives a valid response from the active NTP server and syncs the device time with the server, the poll interval is doubled, up to a maximum of 15 minutes.

In broadcast mode the device does not send requests to specific servers but listens for broadcasts sent by an NTP server.

The device displays the Active NTP Server, the Last Update time, and the Last Adjustment. It will also display details about bad packets received.

Disabling and re-enabling the NTP client effectively forces the device to synchronise its time immediately.

The device can also act as a time server.

CENTRAL MANAGEMENT

There can be multiple instances of the mediation device.

The mediation solution has the capability of managing multiple mediation devices through a centralised Management Platform.

The Central Management Platform at a minimum provides the following functionality:

• List all Mediation devices under management
   
• Add / Delete mediation devices to be Centrally Managed
   
• Ability to login to the Mediation Device under management
   
• Able to create / edit FUP policies which can be named and versioned and ‘pushed out’ to selected Mediation Devices.
   
• Monitor the status of the EP devices e.g. CPU, Users on-line etc.
   
• Status / Receipt of the Syslogs
   

The device is capable of being managed remotely from a central location. Users can access the device via Telnet, FTP, SSH and WinBox (a Mikrotik program). Programmer interfaces also exist to enable bespoke remote management solutions to be written in C#, PHP and C++. Mikrotik also provide an excellent free centralised management console known as DUDE. This enables a user to access and manage multiple mediation devices, plus other devices such as routers, from a central console.

The management tool enables Fair Use Policies to be uploaded via FTP or SSH. The device also supports backup and restore configurations, plus import and export. The export utility saves the entire device configuration as a text file, which can be modified offline and imported back to the device. This will significantly reduce the time taken to create tailored configurations on a device-by-device basis.

 
OPERATIONAL PROCEDURES, e.g. Conditional Service Suspend

The unit automatically checks the connectivity to an IP address or FQDN (Fully Qualified Domain Name) that the provider defines on a unit by unit basis as a method of checking if Operational Procedures have been called to temporarily suspend the service.

Operational Procedures to suspend a service should only be assumed to be in place after a configured consecutive failure of the check.

If PING is utilised to check the connectivity then ten pings should constitute a check and a failure rate of 70% or higher should be deemed to be a failed check.

The device is capable of performing a ping of an external IP address. A script is available to issue ping requests on a scheduled basis. The script is configured to modify some of the HTML pages (i.e. rename login.html to login_save.html, and rename oper_minimise_login.html to login.html), if the ping request fails after a number of attempts. The modified login page would inform users who are attempting to login that operational procedures to suspend the service, are in operation.