Why SSL Inspection is needed?

Having SSL Inspection has been always a matter of IT and Organisation fight.
In an architecture project, the only objection to my design was SSL Inspection and I had to bring some convincing reasons for that.

First of all, without SSL Inspection, basically there is zero visibility into what’s happening inside an encrypted traffic like HTTPS, SMTPS, POP3S, etc. Just imagine an attacker popping a machine, tunneling command and control via a HTTPS tunnel. Or an unfortunate employee, exposing confidential data by uploading them to some random cloud service… 0 visibility!

Second business driver I can think of is related to Data Loss Prevention; If a breach is detected tomorrow, there’s hardly any ways to detect what has been lost.

Benefits aside, a noteworthy drawback to SSL Inspection would be administrative overhead; you should distribute the CA cert to all nodes. That being said, in case of a Directory environment like Microsoft AD, it’s not a big deal, although Linux machines or some browsers need special configuration; beside, some web applications have to be excluded from inspection, mainly the ones utilizing Java.

Not really a drawback, but the administrators should be liable and trusted as they can easily intercept the traffic, unencrypted. This not only applies to the Proxy admins, but to a Mail admin, System admin, etc; which makes it an HR matter.
Note that any product which does MITM has the opportunity to expose data, and so its admins.

Here, you have to see the tradeoff; I believe the gained visibility worths it!

Sometimes CxOs might say that SSL is sacred! Yes, it is, but they have to decide how sacred they want SSL to be versus how interested they are in what information might be leaving the environment without authorization; or how much malware command and control (C&C) they might want quietly going out via SSL without being torn open for inspection.

Note that you have to design a way that all egress web traffic (both users and servers) must be enforced to go through the proxy, otherwise the whole proxy plan is pointless. Besides, you have to follow some practices:

  • Know the business and business processes and demands. Every sector has its own limitations or requirements where might be against SSL inspection.
  • Plan some whitelisting policies to disable inspection in specific cases where needed.
  • Know your traffic and the percentage of encrypted requests.
  • Make sure that your appliance supports the amount of traffic; SSL Inspection means decrypting the connection, inspecting it and then re-encrypting it.

P.S. Yes, my drawing skills are awful! 🙂

Share this!

Enterprise Core Routing Design Models with BGP

Reading through the well-written CCDE Study Guide book by Marwan Al-shawi, came to a section about having BGP as the Enterprise Core Routing Protocol and its possible Design models.

To make it a little bit brighter to myself, I’m gonna explain them in a different way with different diagrams and matrix based on my own design experience with these models.

Disclaimer: Please have in mind that the number of routers drawn, doesn’t reflect the reality of the design, and is just been this way for the sake of simplicity; obviously there would be redundant routers in real World, and also the Core could span different PoPs.
Besides, the bigger border routers could reflect two separate ones, one on Core, and one on Branch side.

Design Model 1

BGP-as-Enterprise-Core-Routing-Design-Model-1

This model is suitable when least Administrative Domain Control is required; though it still overcomes an end-to-end IGP design, providing better management between remote campuses.

Core IGP is mainly used to provide Next-hop reachability for iBGP speakers. Please note that this is applicable to all models where iBGP is used in the Core.

The downside to this design is moderate operation complexity; which could arise i.e. by IGP-into-BGP Redistribution and iBGP full-mesh/RR/Confederation management in the Core. Continue reading “Enterprise Core Routing Design Models with BGP”

Share this!

Network Design Project Initial Questions

I have been always thinking of creating a set of questions-to-be-asked for Network design projects. Though, it’s really hard to have the same template for every project, but usually there some general questions applying to all.

Skimming through the web, I came to an interesting article on Cisco Learning Network : Unleashing CCDE. I am pasting the questions list here, but with my own text marking:

Listed are some of the initial questions to ask your customers at the onset of a new network design project:

1. Business objectives, pain points and perceived constraints
  • Who are the key stakeholders, sponsors, end users?
  • Why is there a project in the first place? What are the drivers for the redesign of your existing network?
  • What are the current pain points?
  • Which business outcomes the customer expects to achieve?
  • What is the business growth plan 3-5 years, capacity planning, scaling requirements?
  • Are there any regulatory constraints such as HIPAA, PCI, Fed, and Local Government that affect the organization and industry? Other known constraints?
  • Is there specific equipment, vendors, or protocols preferred or are absolutely out of the question?
  • What are the implementation timelines and milestones?
  • What are the key success factors? Are there known barriers to success?
  • What is the customer tolerance to risk? Conservative or bleeding edge?
2. Desired characteristics and capabilities
  • What is the current state of the network (baseline), to compare after the implementation of the new design?
  • Are there any documentation available, features in use, versions, is standardization consistent?
  • What is the financial investment (cost/budget, cost-benefit analysis) x desired business, operational, and innovation outcomes, followed by a technical translation of these needs/goals to a technology environment?
  • What are the desired characteristics of the new network: redundancy/resiliency/convergence, speed, security, cost, application performance, simplicity, manageability, capabilities? Load balancing, load sharing?
  • Public, private or hybrid cloud?
3. Footprint, policies, method of access and traffic patterns
  • What is the geographical distribution, connectivity options/capabilities on the branches?
  • Where do the servers reside in the network, their known vulnerabilities and how the services align with the security policies?
  • What are the current and future traffic patterns, north-south, east-west, or both?
  • What are the current and future applications’ requirements and tolerance to delay, packet drop, and jitter?
  • What is the company security, infrastructure policies? Do you have specific design/architecture principles to adhere to? Any project management methodology or tools? Network management?
  • What are the established SLA’s if any, and the level of success achieved for these SLA’s?
  • Does the network support the business, the network is the business, or both?
  • Are there best practices?
  • Will there be a test lab or group, a prototype, a development area?
Share this!

Cisco ACI – 2 – Provisioning a fabric

As mentioned in the last post, let’s make the first step happen: Making an online fabric!

Turn on the UCS server which you have chosen for the APIC role!
It’s presumed that we start with CIMC utility to setup the APIC. As it is with all other Cisco CLIed products, we get a simple wizardish script as below:

I’m sure you have the Cisco ACI Fundamentals open, but let me take a look into some of the parameters which was asked:

  • TEP Address pool: Every leaf and spine node in the fabric, will be automatically assigned at least one Tunnel End Point address.
  • Multicast Address pool: will be used for multicast traffic through the network
  • VLAN ID: is used for communication inside the fabric infrastructure network

After a while, the APIC would be up and accessible via the web management interface using the OOB IP address. Now, we have to discover the physical switching nodes.

I never like to go through GUI, so I just name the steps and mention the more important parts.

  1. From the GUI go to: Fabric tab >> Inventory sub-menu
  2. Click on Fabric Membership (left)
  3. Hence your APIC is at least connected to one Nexus switch, you should see a single leaf node. LLDP is the magic which makes this happen. But we have not yet registered the switch, so there is no ID, name and IP listed.
  4. Double click on each field and simply assign a node ID. After a short break, you will see an IP address for the node. Notice that the IP is assigned from the range we specified for TEP pool during the wizard.
  5. The switch is registered!

Now, we have officially a leaf node, the rest of network will be discovered and you can see the spine nodes appearing on the Fabric Membership page. As you guess, we have to register these nodes the same as the leaf switch. As the result, the remaining switches will pop up and available for membership.

Once all the switching topology –including other leaf nodes– is discovered, we can initialise the same setup procedure for other APICs and form an APIC Cluster. Keep in mind that we have to use different controller ID, management IP, etc.

By the time all APICs are running, the fabric is almost ready and we can see a graphical topology via Fabric | Inventory section in the APIC GUI.

One more thing to do would be to configure the switching nodes with management IP so they can be managed directly. This is done inside Tenants tab and then the Mgmt tenant, where on the left there is Node Management Addresses which let us to configure management IPs for every single fabric node. The next step is to configure at least an Out-of-Band Contract under Security Policies menu, in order to permit traffic into OOB management interfaces. Finally, under Node Management EPGs, we should assign the OOB contract to our OOB EPG.

Share this!

A brief introduction to FabricPath

FabricPath is a technology which combines the benefits of Routing protocols, here will be Intermediate-System-to-Intermediate-System (IS-IS), and Layer 2 Network Ethernet environments.

To list some of FabricPath advantages:

  • MAC Address scalability by Conversational Learning
  • No spanning-tree anymore, hurray! Each switch will have its own view of Layer 2 topology and calculates the L2 topology using SPF calculation.
  • Equal cost multipath forwarding for Unicast Layer 2 traffic!
  • Makes any kind of topology possible!
  • Configuration/Administration is not a hassle anymore
  • Loop prevention/mitigation by having a TTL field in the frames

Switch-ID

We can refer to FabricPath as “Routing MAC Addresses” or “Layer 2 over Layer 3”, but it doesn’t mean that FabricPath ports have an IP Address! In a FabricPath topology, each device is dynamically assigned a “switch-id” via Dynamic Resource Allocation Protocol (DRAP), and L2 forwarding table is populated based on reachability to each switch-id.

Function types in FabricPath

  • Leaf: This is where Classic Ethernet devices are connected to. It’s the point of “MAC to switch-id” mapping. Traffic is looked up in the L2 forwarding table and then encapsulated into a MAC-in-MAC frame whose destination switch-id is the switch which the destination host is connected to. FabricPath is only supported on Cisco Nexus 5500 with NX-OS 5.1(3)N1(1) and higher as the edge (access) device in FabricPath topology.
  • Spine: Cisco Nexus 7000 is supported as the aggregation device in FabricPath topology with NX-OS 5.1(1) and higher, but only based on F1 line cards. Layer 3 forwarding could be gained by adding M1 series cards.

Continue reading “A brief introduction to FabricPath”

Share this!