Internet DRAFT - draft-shet-opsawg-firewalls-interconn
draft-shet-opsawg-firewalls-interconn
Operations Area Working Group C. Sheth
Internet Draft TCSL
Intended status: Informational R.Thakker
Expires: May 2016 VGEC
November 10, 2015
Dynamic Routed Network for Interconnection of Firewalls at Multiple
Geographic Locations
draft-shet-opsawg-firewalls-interconn-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 10, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Sheth & Thakker Expires May 10, 2016 [Page 1]
Internet-Draft Network to Interconnect Firewalls November 2015
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
Firewall performs resource intensive filtering of traffic based on
set of rules. A single firewall becomes a traffic bottleneck
depending on network expansion, number of connections and the
throughput required. This document describes a method of
interconnecting the firewalls at multiple geographic locations
through standalone network. It will enable firewall to dedicate its
full processing capacity to perform task of packet filtering. The
tasks of encryption, dynamic routing and anti-spoofing of traffic are
taken care outside firewall function. The placement of firewall and
routing device along with protocols to be used will form the proposed
system to improve overall network security and scalability.
Table of Contents
1. Introduction ................................................ 2
2. Conventions used in this document ............................ 3
3. Firewall Placement .......................................... 3
3.1. The Core Network ........................................ 5
3.2. Routing ................................................ 5
3.3. Proposed rules for inter site metrics ................... 6
4. High Capacity Site .......................................... 7
5. Dynamic Network Extension .................................... 7
6. Security Considerations ...................................... 8
7. IANA Considerations ......................................... 9
8. Conclusions ................................................. 9
9. References .................................................. 9
9.1. Normative References .................................... 9
9.2. Informative References .................................. 9
10. Acknowledgments ........................................... 10
1. Introduction
A firewall protects one or more inside networks, connects inside
protected network to the internet and also connects to other internal
geographically separated firewalls for access to the rest of the
network. Today, with growth and expansion, most companies are
geographically spread all over the world. There is a need for
increased network security when connecting one inside protected
network with another inside protected network in different
Sheth & Thakker Expires May 10, 2016 [Page 2]
Internet-Draft Network to Interconnect Firewalls November 2015
geographical location, specifically over internet. One of the known
approach to avoid sending data in plain text over internet is to
establish site to site virtual private network (VPN) using firewall
at both locations. VPN will ensure data security by encrypting the
traffic. However, major challenge with site to site VPN is that it
provides static network routing. In case of multiple sites, each site
needs dedicated site to site VPN connectivity with all other sites.
This increases network complexity and bottleneck in case of any site
or link failure. Considerable amount of work has been done to study
encryption algorithm on site-to-site IP Security (IPsec) VPN, Border
Gateway Protocol (BGP) and Multi-Protocol Label Switching (MPLS)
performance comparisons and setup of virtual cluster cloud for inter-
site connectivity. This document describes system design of
interconnection of firewalls to achieve dynamic routing. Apart from
increased security, it also helps in improving scalability.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Firewall Placement
The document is for global or wide area network that interconnects
all sites at different geographical location and also interconnects
all the networks within the same site. The way connectivity is
achieved between the sites is irrelevant to the site firewalls.
Firewalls only need dedicated network interfaces to connect to
different networks as shown in Figure 1.
Sheth & Thakker Expires May 10, 2016 [Page 3]
Internet-Draft Network to Interconnect Firewalls November 2015
---------
/ \
| Internet |_
| |
\_________/
---------
^
|
|
V
--------- +-----------+ +-----------+
/ \ | | | |
| Core |__ | Routing | | Firewall |
| Network |<---> | Device | <---> | Device |
\_________/ | | | |
--------- +-----------+ +-----------+
^
|
|
V
---------
/ \
|Protected |_
| Network |
\_________/
---------
Figure 1 Single Site Setup
Direct communication between devices at separate sites requires a
network that connects the sites without translating addresses. The
network provides connectivity between internal networks. It does not
provide internet connectivity. For internet connectivity, firewall
will use dedicated internet interface to route all internet traffic.
Depending on performance needs, same firewall could also act as
routing device, if there are no high performance requirements.
Sheth & Thakker Expires May 10, 2016 [Page 4]
Internet-Draft Network to Interconnect Firewalls November 2015
A standard firewall has the following setup.
1. Internet interface for connecting to internet.
2. Interface for connecting to routing device of proposed network.
3. Inside interface(s) for connecting to protected network.
All communication to internal networks that is not behind the local
firewall is routed via the core network interface. It does not matter
how the remote internal network is connected. It could be in the same
datacenter in nearby rack, on the other side of the internet, behind
a multiprotocol label switching (MPLS) virtual private network (VPN)
or connected via a squad of synchronized yodelers. Remote network
connectivity is irrelevant to the firewalls as that part is handled
by the core network. Scaling the network becomes a simple process of
connecting new devices to the proposed network.
3.1. The Core Network
The core network does not perform any detailed filtering of traffic.
It performs below.
1. Encrypt all traffic between sites
2. Anti-spoof all traffic entering the proposed network
The standalone network consists of the device used for routing and
the links connecting them. For inter-site connectivity the links
between routing devices will use internet protocol security (IPsec)
encapsulated generic routing encapsulation (GRE) tunnels. Within a
site, it will be direct links or VLAN sub-interfaces. Inter-site
traffic is always encrypted, no matter if the carrier is the internet
or a dedicated data service. Inside the core network there is no
filtering of traffic. It is a dynamically routed network that uses
Border Gateway Protocol (BGP) for routing. Also, the network is split
up into multiple autonomous systems (AS) to stabilize the routing.
Stabilization of traffic will help preventing BGP breakdown. It uses
one backbone AS and multiple leaf AS. The leaf AS connects the
backbone AS for connectivity to the rest of the network.
3.2. Routing
The backbone Autonomous System (AS) advertises all prefixes to leaf
AS. A leaf AS only advertises its own prefixes on peering with other
AS. A leaf AS may have peering with other leaf AS, but it does not
provide transit between AS. All traffic between AS in the network
will go either via the backbone AS or via a direct peering between
the AS.
Sheth & Thakker Expires May 10, 2016 [Page 5]
Internet-Draft Network to Interconnect Firewalls November 2015
Inside each AS a BGP-only setup is used, with the Multi Exit
Discriminator (MED) attribute used for path selection. The MED
provides a dynamic way to influence another AS in the way to reach a
certain route when there are multiple entry points for that AS. Below
are some of the characteristics of core network for path selection.
1. All routing device should have internal BGP (iBGP) peering with
only directly connected peers.
2. All routing device iBGP peers are configured as route-reflectors.
3. All routing device will re-write next-hop in iBGP peering so it is
reachable via connected routes.
4. All routing device increment MED on received prefixes. The value
used to increment MED should be the same on both sides of a
peering.
3.3. Proposed rules for inter site metrics
Some of the proposed rules for adapting inter-site metrics are as
below.
1. Traffic between directly connected backbone sites should be routed
via the direct connections.
2. Traffic from leaf AS to directly connected backbone sites should
be routed via the direct connection.
3. Inter-site metrics should never be lower than +1k.
4. Within a site, metrics should either be +100 or +127, depending on
if it is a primary or standby path. The general idea is that the
cost within a site always should be lower than that between sites.
5. Each non-backbone site is configured as a leaf AS and connects to
the backbone AS in two or more locations.
6. The backbone AS sites are high-speed, high availability sites.
The firewall or firewall cluster connects to the routing device
through dedicated edge interface. Two separate firewall edge devices
should not be installed on the same subnet. Communication between
firewalls devices always traverses the proposed network. All traffic
entering the proposed network is subjected to anti-spoofing, using
strict reverse path forwarding (RPF). The routing between routing
device and firewall device can be either dynamic routing or static
Sheth & Thakker Expires May 10, 2016 [Page 6]
Internet-Draft Network to Interconnect Firewalls November 2015
routing depending on what the edge device supports. Static routing
has management overhead as the devices may need to be manually
updated as prefixes are added and removed from the network. When
dynamic routing is used, route-filters are applied to only permit
specific networks to be accepted into the routing protocol. The
firewall edge device is only responsible for protecting the networks
behind it. It is allowed to have a rule set that permits any from its
inside networks to the proposed network. Traffic routed via the
proposed network should not use network address translation (NAT). If
it does, it will be subjected to the network policy for the firewall
device range.
4. High Capacity Site
A standard site contains routing device which connects all the
firewall edge devices and other routing devices. It also connect to
other sites using IPsec encapsulated GRE tunnels. At backbone sites
the routing devices also need to process traffic between remote
sites. The IPsec processing is a lot more CPU intensive than just
forwarding. When the device needs to handle IPsec traffic, local
forwarding performance is greatly reduced. To increase the capacity
of the site, a new type of device is proposed. This device is
dedicated to routing traffic inside a site. It takes over the task of
interconnecting all the network core and edge devices at a site from
the routing device. With this new device installed, the routing
devices are no longer need to process traffic between local devices,
they only need to handle VPN traffic. As a result, VPN capacity will
be increased by adding additional routing devices to the site. The
new devices will take care of the routing between all devices. As a
bi-product, the capability to add additional routing devices at a
site also provides a way to overcome the issues with link handling.
If a site with firewall edge devices that require static routing and
the site layout cannot support routing device with a single physical
VLAN trunk interface, additional site routing devices could be added
to the site to handle such firewalls.
5. Dynamic Network Extension
This section specifies how to connect the core network to other
networks using dynamically routed interconnections. This allows
interconnections in multiple locations to achieve redundancy and also
improve routing between the networks. It supports both local and VPN
connectivity between networks. It will also enable routing device to
have dynamically routed interconnections with other networks. The
Interconnection is possible over below.
Sheth & Thakker Expires May 10, 2016 [Page 7]
Internet-Draft Network to Interconnect Firewalls November 2015
1. Direct physical interconnect
2. Encrypted VPN over Internet or other third party network.
The Interconnections support source address verification. The
Interconnections also support filtering of prefixes in the routing
protocol.
To handle the interconnections, interconnect routing device is used.
It is dedicated to the task of interconnecting with other networks.
This setup is used when we need to connect the network to other
networks in more than one location using dynamic routing. It also
means that any form of address translation is not supported. Internal
networks use the same address space, as a result, interconnecting
them always requires some form of address translation. Most networks
have a VPN interconnect design to address these issues. BGP is the
routing protocol supported for network interconnections. There are
two types of Interconnects.
1. LAN Interconnect - It is used in the cases where both networks
exist at the same location, like the same data center.
2. VPN Interconnect. It is used in the cases where we want to have an
interconnect between the networks using Internet or another third
party network as carrier.
From a routing perspective there is no difference between a LAN and a
VPN Interconnect. Under normal conditions, the proposed network will
advertise the same networks at all interconnect locations and the
other network is expected to do the same towards proposed network.
Interconnect routing device connects to the routing device for
connectivity to the proposed network. The interfaces used are core
interfaces and filtering of traffic is not done on either device.
The physical connectivity of the Interconnect routing device depends
on the situation. Direct physical connection to peer network is done
on dedicated physical interface. For routing, each side advertise all
their prefixes at all locations with the same metrics and BGP
attributes.
6. Security Considerations
No additional security risk is introduced by using the mechanisms
proposed in this document.
Sheth & Thakker Expires May 10, 2016 [Page 8]
Internet-Draft Network to Interconnect Firewalls November 2015
7. IANA Considerations
No requirements for IANA.
8. Conclusions
This document proposes system and method comprising a network for
interconnection of firewalls at multiple geographical locations
connected through wide area network and also interconnection of all
the networks within the same site. It applies to all communication to
internal networks that is not behind the local firewall. All such
communication will be routed through proposed network which is
connected to firewall via dedicated interface. Network design for
sites which needs higher capacity as compared with other network
sites is also proposed. Extension of the design is also proposed in
order to connect the proposed network to other external networks
using dynamically routed interconnections.
9. References
9.1. Normative References
[RFC793] Postel, B., Bradner, S., "Transmission Control Protocol",
STD 7, RFC 793, September 1981.
[RFC4026] Andersson, L., "Provider Provisioned Virtual Private
Network (VPN) Terminology", RFC 4026, March, 2005.
[RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks", RFC 4364, February, 2006.
9.2. Informative References
[Att2006] Attebury, G., Ramamurthy, B., "Router and Firewall
Redundancy with OpenBSD and CARP". IEEE ICC, 146 - 151,
2006
[OpenBSD-PF]OpenBSD, "pf(4) manual page: pf -- packet filter", 2015,
<http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man4/pf.4&query=pf>.
[RFC3511] Hickman, B., Newman, D., Tadjudin, S., Martin, T.,
"Benchmarking Methodology for Firewall Performance", RFC
3511, April 2003.
[RFC2979] Freed, N.,"Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000.
Sheth & Thakker Expires May 10, 2016 [Page 9]
Internet-Draft Network to Interconnect Firewalls November 2015
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet
Transparency", RFC 4924, July 2007.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and
P.Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
10. Acknowledgments
TBC
Sheth & Thakker Expires May 10, 2016 [Page 10]
Internet-Draft Network to Interconnect Firewalls November 2015
Authors' Addresses
Chirag Sheth
TCSL
Garima Park, Gandhinagar - 382421, India
Email: chirag.sheth@tcs.com
Rajesh Thakker
VGEC
Motera, Chandkheda, Ahmedabad, India
Email: rathakker2008@gmail.com
Sheth & Thakker Expires May 10, 2016 [Page 11]
