SDK Your Net Corporation Policy Manager Example: Captive Portal Daemon (cpd) Documentation

1.0

Introduction

The Policy Manager sample application composed of two daemons on the routing engine (RE), the Policy Server Daemon (PSD) and the Policy Enforcement Daemon (PED). Both daemons will be added to the sync-policy-manager-mgmt package, which for the fictitious company SDK Your Net Corp. (SYNC), demonstrates how to use the correct naming conventions in developing a package to hold RE-SDK daemons. As of the 8.5 package release, the sample application also contains two daemons running on the MS-PIC or even separate PICs optionally. There is the Packet Filtering Daemon (PFD) running as a data application and a Captive Portal Daemon (CPD), which is a simple HTTP server running as a control application. The whole application containing all four daemons is contained in the sync-policy-manager-bundle package.

The goal of this application is to demonstrate the use of some JUNOS SDK APIs. It covers the use of DDL and ODL, respectively, to manage configuration and commands, and to control the output of operational commands. It uses event control from the eventlib API in libisc2 (a library provided by the Internet Software Consortium) to exemplify its use with sockets to provide asynchronous communication services. It demonstrates the use of libjunos-sdk in several ways: Kernel Communication (KCOM) is used to listen for protocol family changes on interfaces, and tracing and logging happens using the APIs exposed in the junos_trace module. This application also demonstrates the use of libjipc for inter-process communication to and from the PSD. Libssd, a major SDK library that communicates with the SDK Service Daemon (SSD), is used to manage routes associated with policies and install service routes to MS-PICs. Lastly, the application demonstrates writing control and data applications for the MP-SDK using libconn and libmp-sdk, performing PIC-PIC and RE-PIC communications.

The Captive Portal Daemon (CPD)

The CPD is, in essence, just a very simple HTTP server. It is a control (or server-style) MP-SDK application. Unauthorized users have an opportunity to "authenticate." However, no real authentication is performed. A subscriber will simply have the option of clicking a button on a web page to authorize traffic and one to revoke such authorization. The list of authorized users is updated based on such actions. This list will only be kept in memory and not remembered, although future versions could place it in persistent storage with KCOM GENCFG.

Initialization and Configuration

As described in Section 2.2.10, the PED originally must act as the intermediary between the PFD and the CPD, so the CPD first connects to the PED. This way the PED will have the CPD's connection information. The CPD receives the address for its HTTP server, which is also it's (IFL 102) IP address. It also receives the address that the PFD uses in NAT. This way it knows all connections to the HTTP server from this address are in fact from the PFD having performed NAT on some client's packets.

At this point the CPD initializes its HTTP server on port 80. It also awaits a connection request from the PFD. The PFD requests the list of authorized subscribers, and the CPD replies. Furthermore, the CPD keeps this connection open, and sends updates of this list to the PFD.

Managing Authorized Users

When a subscriber (a user's source IP address) is unauthorized, its traffic is directed to the CPD by the PFD; however, the CPD will also be directly accessible by unauthorized (and authorized) users. When the CPD receives an HTTP GET request connection from the PFD's data interface, it will reply with an HTTP MOVED (response code 301) redirect message. This redirect URL will force the end user's browser to directly connect to the CPD bypassing the PFD's NAT because the PFD allows direct connections to the CPD from everyone. Thus, we simultaneously lower the load on the PFD. From the user's point of view, before the redirect the unauthorized user thinks it is talking to the HTTP server (on the internet/network through the outbound interface) that it originally requested communication with. After getting the redirect response the user knows that it is to target the CPD directly.

When the user connects directly to the CPD, the HTTP server presents a page with a button allowing the user to authorize himself. When clicked, the CPD will add the user's source IP to the list of authorized users and send an update to the PFD over the internal communication channel.

When a user becomes authorized, he can make connections through the router and through other outbound interfaces, and he must directly connect to the CPD to click the button to remove his authorization because the PFD will not be redirecting anything of his to the CPD.


2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:53 2010 for SDK Your Net Corporation Policy Manager Example: Captive Portal Daemon (cpd) 1.0 by Doxygen 1.5.1