Multi-port Firewall Service Proposal

Points to be Addressed in a Proposal for a New Service:

1. Why is the proposed service believed to apply to the case at hand (what is the purpose for wanting to add the service, what are the user issues, what deficiency is thought to exist)?

   High-level authorities within Penn State have recently made strategic changes to the network firewall philosophy, dramatically increasing the demand for the ITS Firewall Service. In addition, changes to the Private Fiber policy have changed some of the design assumptions of the existing service, since departments can now collapse multiple buildings and subnets to a single physical backbone connection point. Coincidentally, the devices providing the existing service provide multiple interfaces. ITS could modify the existing firewall service to support these existing interfaces to create a new service that maps well onto these new conditions.

2. Would this service apply or be beneficial to others at UP?

   Yes. This service would apply anywhere multiple networks home to a single physical location. Many colleges and campuses already have this network topology or will shortly with private fiber requests.

3. Would this service apply to all University locations?

   This service applies to any University location served by a 100M or 1000M Ethernet Integrated backbone connection from the PSU core.

4. What are the benefits to this service over existing offerings, or does this service provide something completely new (from a global perspective, not a single case perspective)?

   Under the existing service, the firewall is a two-port device with one interface connecting to the router and the other connecting to the local area network. A unit could place an aggregation device — a switch — in front of the firewall to combine separate local networks, but they would share a single set of firewall rules. Units desiring separate firewall rule sets for each network would require multiple firewalls. This approach consumes more University resources, both from the standpoint of the cost of the firewalls themselves and the router interfaces they use.

   Under a modified service, the firewall is a multi-port device. While one interface still provides the router connection, the others would all be available for use on the local area network with the ability to apply a separate firewall rule set to each. The University would save by not needing multiple firewall devices and by using only a single router interface.

5. From a strategic standpoint, what are the long-term benefits/drawbacks of providing the service?

   The firewall devices can support a multi-port configuration. They provide more throughput in that configuration than with a two-port configuration. However, they do not provide as much throughput as multiple standalone firewalls would. Even if this were not the case, the multi-port configuration is naturally limited by using a single router interface, as opposed to multiple router interfaces with multiple standalone firewalls.

   On the other hand, the multi-port configuration would reduce the routers processing load for any traffic between the local area networks. By definition, these devices tie together networks within an organization. As such, it is likely that much of the traffic would remain within the local networks. This traffic would not be rate limited by the router interface. The organization might see improved performance while reducing the load on the core routers.

   In addition, when used in this configuration, the firewall can only support eight subnets per interface.

6. Can the service be provided by another University group or by an outside third party?

   Any organization within Penn State is free to implement their networks in any way they desire. However, in order to have TNS maintain a network behind a firewall, the network must use the ITS Firewall Service. ITS has recently added an option to the TNS local area network Installation and Maintenance policy. The new option has made TNS support available for the LAN behind a customer’s firewall if specific criteria are met.

7. What options does the user/customer have if TNS does not provide the service?

   The customer could use an aggregation switch behind the firewall but this would not provide any firewall capability between the networks. The customer could purchase multiple firewalls which increases cost significantly. The customer could procure a multi-port firewall from another vendor. However, TNS will not provide maintenance for a network behind a customer provided firewall since it violates the concept of “contiguous maintenance.” ITS has recently added an option to the TNS local area network Installation and Maintenance policy. The new option has made TNS support available for the LAN behind a customer’s firewall if specific criteria are met.

8. What are the proposed one time, recurring and usage rates for the service, and how do they compare to other available options (assuming there are any)?

   Assuming only the existing interfaces on the firewall, the existing price structure could apply.

9. What are the operational support issues — do spares need to be carried and how many are suggested, does it use proprietary equipment, what are the delivery (lead) time issues?

   Assuming only the existing interfaces on the firewall, no additional firewall spares would be required.

10. What are the training issues for operations, ITS user training staff and user training

    Very little additional operational training would be necessary as the existing ITS Firewall Service components would be used. We would have to educate users on the additional level of complexity involved with multi-port interconnections. That is, they need to be concerned about firewall rules between ports, as well as between the local are network and the backbone.

    Because of these added rule complexities, we do not believe it is feasible to provide an equivalent of our “Basic Firewall Service.” We believe that any customer asking for the multi-port firewall service would have to get the “Custom Firewall Service” where they define the rules.

11. What are the start-up costs (including operational support and training costs) for TNS

    Startup costs would be minimal. We could start assuming that only the existing firewall interfaces would be available. If customer demand for additional interface types and numbers was sufficient, we could consider adding them in the future.

12. What are the technical issues — will technology changes make the service unnecessary in the future, is it a mature technology or prototype, has it been proven (tested) to work in the applications suggested (and what was the process for testing), what are the expectations regarding reliability, can it be applied to the existing infrastructure, etc.?

    This enhancement to the ITS Firewall Service will use the existing hardware and software which we have been using for the last four-plus years. Although ITS has not used the equipment in this way, most non-PSU deployments use the devices with multiple ports. NP&I will conduct testing of each firewall offering chosen for this service to determine expected throughput for various configurations.

13. Will new equipment be required?

    We would be willing to offer this service on any firewall we have deployed that has additional ports available. Some of the smaller, early devices only had one extra port. The remainder had two extra ports.

    • If applicable, what exactly is the proposed equipment (manufacturer and model numbers)?

      Current offerings are:

      • Nokia IP560 Base System (Large Firewall)

      • Nokia IP390 Base System (Medium Firewall)

      • Nokia IP260 Base System (Small Firewall)

    • If applicable, what is the expected life cycle of the equipment (is it stable or will it require frequent change-outs until the technology stabilizes)?

      There has been rapid evolution in the hardware platform to date. However, the vendor made these changes to bring their manufacturing processes in line with Europe’s green manufacturing laws. We believe the product line should be more stable from now on.

14. What is the projected start date for this service?

    The only efforts I believe are required to place the new service into production are:

    • Document test results showing actual performance of the existing hardware in the proposed configuration

    • Create the internal ITS pre-announcement

    • Inform TLT Training Services

    • Review TNS workflows

    • Determine rates and billing procedures — although, I would recommend the existing structure

    • Deploy an “Operational Trial.”

    • Announce the new service

    Of these, the length of the Operational Trial will largely determine when the service will be generally available. We believe this service could be offered within 90 days.

Share: Delicious | Facebook