SDN for Dummies – Part Drei

The fun is about to begin. Let’s look at a definition of SDN and some of the major components that make it unique.

Dreez Definition: Software Defined Networking (SDN): The ability to co-manage both the network and security components of a Cloud Infrastructure from a single centralized management platform through the use of automation (software scripting / orchestration).

I know…pretty deep….Let’s go through it one step at a time:

1. Co-Manage both network and security of a Cloud infrastructure from a single centralized management Platform SDN is a layer of software that gives its transparency. SDN allows virtual guests to float between physical platforms with neither the guest nor the end user knowing what physical platform it is on. SDN will merge network management with security management. You see that a bit now in vCenter Security Manager. So imagine in the future if you click on ‘Security’ and an MDS/Security Management Station pops up and all the VMware objects exist in that view.
2. Through the use of software scripting (orchestration)EVERY!!! SDN platform has APIs that enable scripting tools to do whatever you can do in the GUI. If there is an SDN that does not, then it is NOT SDN. What does this mean. Massive unemployment for most of you reading this.Think of what happens now if you have to move a subnet from Chicago to New York. The routing geeks have to touch several routers and switches one at a time. The firewall people have to redo their routing and rulesets on two firewalls. The Load Balancing people have work magic.In the future with SDN this subnet move will occur with scripts. One person will write and execute a script making this whole move happen transparently.

Security  and Network Tags

So what is the mechanism that keeps keeps the security world organized? The glue is called Security and Network Tags. Each virtual guest has a tags that contains security and network information such as policy, encryption keys, IP information. When you ‘orchestrate’ your virtual world and create policy and encryption keys for the guests, the information gets stuck into these tags. Now notice it doesn’t matter where these virtual guests are running…no one knows except VMware and the administrator. These tags are what I call the operation context of a virtual guest. They allow the guests to float between physical platforms and maintain their current state and environment.

VMware Security Groups

Now for the best part with regards to security. This next image is so innocuous but yet is the heart of SDN that will ravage networking as we know it and could be CheckPoint’s/Tufin’s strength if they could swing it politically. This will make most of you reading this unemployed boat anchors, Cisco routing geeks bankrupt, network gear makers bankrupt….I think you get the picture.

[ crickets….]

So in VMware you can gather hosts into security groups based on characteristics of the hosts – and not just IPv4 addresses. Not really a big deal, you can do that on almost any management platform. But in a virtual orchestrated world grouping is the glue that keeps the management station from self destructing exponentially. Imagine 10 scripting manics generating 10000000000’s of objects in seconds – and then they quit and you get a new batch of 20-year-old scripting maniacs, et al. After a couple days your management environment will be out of control. You HAVE to use groups to keep the virtual world manageable. Now in the future groups will also change and be enhanced to manage the scope creep. There will be tagging, labels, etc. just like you see in CheckPoint’s R80 and Google gmail. But in the end, there will be several forms of grouping. I know, I know….Doesn’t look so powerful does it? So this is the crux of my rant. Currently both network and security geeks provide separation (grouping) via subnets. Once we created a subnet, we then can create a firewall rule to protect it. Notice below that all firewall rules are based on networking.

Now I was never sure how a subnet alone prevents Himachi/HeartBleed/etc from spreading throughout your network, but that’s what we do because that is what we have always done since the dawn of time (aside: subnets only stop broadcast storms). Like lemmings walking off a cliff we are planning our future based on what we have done in the past. But I claim in the future we will provide separation based on SECURITY GROUPS. (and not networking). A DMZ Security Group will be made up of DMZ machines and NOT a subnet. Remember from my Part Eins rant about how networking will change and routing will become less important. Well this is another nail in the coffin. We won’t need routing because the world is becoming L2 Ethernet (no IP addresses) and security groups (no IP addresses) and so without IP addresses who needs routing? And if The Cloud is hosted on a big Borg Cube, why do we even need classic IPv4 networks to transfer packets, it might just be some combination of virtual guest UIDs (instead of IPv4 addresses) and distributed shared memory communication. For example, in the old old days an operating system called Multics all communications were performed via distributed shared files. Everything was a file, even networking.

Next Gen Firewalls

Now start thinking about NGF. Policy rules are based on USERs/Machines and Services. So the rule looks like:

• “John Adams” – Do you see any IP addresses? Does it have to be an IP address?
• HR – Is this a subnet or a group of people or a group of machines? In SDN – who cares? Could be UIDs.
• Facebook – Is this  a IPv4 port or a network protocol? In NGF it is a network protocol on ANY port

So even in NGF, you are starting to see the disappearance or the REQUIREMENT for IPv4 constructs.  People can be AD credentials, Facebook is a protocol not a port, HR could be a group of VMware objects imported from VMware and could be MAC addresses, could be UID’s or VMware security tabs created by NSX – Basically you don’t care what is underneath.

 Service Chaining/Traffic Steering.

Yet another nail in the Network coffin. In the virtual world, you don’t always depend upon IP routing to direct the flow of traffic. You can use Traffic Steering. Right now if packet X has IP 1.1.1.1 it will always go to router next hop 1.1.1.2.

In the virtual world, you can build rules that say “Traffic from Security Group X to Server Y, will always go through FirewallZ”. Do you see any IPv4 routing in that statement? What if FirewallZ is in Siberia on not on the direct subnet – doesn’t matter NSX will direct it to Siberia somehow.

TUNNELS

Notice that they are on the same subnet but in two different physical locations? How is this done? VXLAN!!!

VXLAN is the magic tunneling protocol SDN uses to make virtual guests float. In the physical world subnets usually are in 1 physical location (e.g. DMZ is physically located connected to firewall). With VXLAN tunneling, you can have virtual guests all over the world on the same subnet, so they can float and maintain their same network/operational context.

How does it work? Well in the above, you can see 4 virtual guests in different geographic locations all on the same subnet 1.1.1.X. NSX keeps track of where the subnet is by a VNID (Virtual Network ID). In this case it is VNID 12345. NSX uses VXLAN tunnels by encapulating VXLAN packets inside UDP port 4789 packets.

Now tunneling is not the most efficient way of transporting network packets. If you have 2 high bandwidth applications talking to each other over a 4000 mile encrypted tunnel, chances are there will be lots of latency. But technology moves on and in time network bandwidth will be almost as free as water so latency will scale. Historically it always has.

What will blow up????

Let’s review a couple things…

1. The CLOUD is not SDN and SDN is not The CLOUD. The Cloud is where virtual guests are floating through time and space not knowing or carrying what physical platform they are on. SDN is the underlying infrastructure that magically allows them to float…securely. In the above picture SDN is NSX in vmWare land and ACI in Cisco land.
2. SDN will change: In my definition in today’s technology ‘network infrastructure’ you might assume we will have routers, switches, IP addresses, load balancers, etc 25 years from now. WRONG. 25 years from now the ‘network infrastructure’ might be the backplane of an enormous gyrating Borg Cube with lights (aka ‘War Games’) with no network. All the virtual guests will be running in the Borg Cube and use distributed shared memory (vs. IPv4) to share data. Who knows? But those communication channels still exchange packets hence I use the term ‘network infrastructure’.
3. The Cloud  – 10 years out I am trying to decide what The Cloud will look like 10 years out. If we go the Google route with 1000000’s of generic Linux servers, then you have to transport packets between systems. If you pack it all into a gigantic Borg Cube, you’ll have a pica-sec latency backplane with oodle’s of terabit/second throughput….but you will be wedded to an evil OEM. I’m will guess a enterprise will buy multiple Borg Cubes for redundancy because they want to be able to call 1-800-xxx-xxxxx and scream at someone if it blows up.
4. Rapid Deployment – Rapid Destruction Kelman from CheckPoint’s quote. Scripts can deploy quickly and just as quickly destroy the whole environment. In addition you now have an even more concentrated group of employees with super uber admin privileges administrating the Borg Cube. One bad apple and your enterprise is gone.
5. Single Point of Failure – The Borg Cube – Any failure in SDN internals or Cloud management will bring down the whole Borg. You know how firewall clusters only fail over in the perfect world? Same thing here.
6. Orchestration – See Rapid Deployment Rapid Destruction
7. Staffing – Need to know networking, security, scripting.
8. Licensing – Will be interesting how licensing models will change. Currently licensing is based a lot on IP addresses. Also licensing is based on the physical world..deploying 400 firewalls is a big deal now but imagine deploying 1000000000’s of firewalls with scripts. In addition, retiring 400 firewalls takes years but now you can do it in a second. So what will licensing look like in this IP-less dynamic world? It is a nightmare now with many products.
9. Compliance – Remember application weenies want to just fire and forget. The CIO will want you to deploy a 600 server farm today and worry about security later. So how do you ensure that these dynamic environments maintain a security compliant profile? Not sure what products can adapt to this dynamic environment at this point.
10. Debug vs Deploy – Debugging will be a nightmare in this dynamic environment created by scripts. Have you ever debugged in a load balanced environment when packets are never following the same path? This will be even more fun with encrypted tunnels, floating guests, scripted deployments….
11. VMware security architecture issue – Rumor has it (I heard this through the grapevine, have not verified details) that VMware based firewalls (Palo, CheckPoint, etc) are not totally embedded within the hypervisor. When the hypervisor sees traffic that needs to be processed by a firewall, it forwards it to a virtual guest that is a firewall. So while the abstraction is that every virtual guest has a mini-firewall running inside of it, the reality is that there could be only 1 virtual guest firewall that manages security for all the virtual guests. So this means a Borg cube with 10000000 virtual guests might have 1 actual firewall managing security for 1000000 virtual guests.

    So when talking to vendors ask them explicitly how firewall processing works and how it differs from VMware native firewalls. I will too.

Summary

1. Classic IPv4 networking will go away away over time as network speeds, bandwidth, latency all improve. Will be replace by The Borg, UIDs, share file systems or similar.
2. Orchestration/Scripting/Automation will replace people, outsourcing
3. Security will be an afterthought…always is in new technology
4. Failures will be catastrophic and really cool to talk about over beers
5. If CheckPoint/Tufin play it right, their management framework could win in this virtual world. Ideal would be if VMware bought CheckPoint for their management environment  intellectual property.

SDN For Dummies – Part Zwei

So Jacob and all the router geeks are still shaking their heads from Part Eins “Who needs routing”. “You’ll have to pry my Nexus 7000 out of my cold dead hands” they say. In fact routing is becoming more important they point out as we have to tunnel L2 virtual world traffic over L3 (to make a subnet look geographically neutral) and for VLAN separation.  (hold on to these thoughts, old school)

Before we dive into SDN, let’s review what the server side of the equation looks like and start defining some terms.

Back in 1991, this Dreez dinosaur use to play a Macintosh game called SpaceHO! I only had a Sun Workstation at the time, so to get this game running we had to use a Macintosh emulator software package. Space Ho was a multi player game so it was able to network to other players. To get to the network there was a virtual network cable that attached to the host’s physical network cable and used the host’s real IP address. This virtual network cable was Version 1 of SDN. And this Macintosh emulator was the forerunner of The Cloud…but it only hosted 1 virtual guest…a Macintosh environment.

Everyone is probably familiar with VMworkstation (damn I should of bought stock in them). The Mac Emulator above had babies and now can run multiple guests in a virtual world and they could all network with each other over virtual switches – all inside a single computer.

Enter today’s Vsphere. Now you can have multiple physical hosts and the virtual guests can run on any of them and you don’t even know where the virtual guest is running at any giving moment. Virtual guests can even move between physical hosts (vMotion).

[begin music]

Enter THE CLOUD

Dreez’s Cloud Definition: The ability of a virtual guest to execute on any piece of physical hardware without the application nor the end user knowing where it is executing.

[end music]

So in the diagram below The Cloud is Vmware’s Vsphere…the total package that makes virtual guests execute and float throughout The Cloud. A portion of Vsphere is NSX…the underlying SDN software that makes it all transparent to the physical world……

Enter Vmware’s version of SDN…NSX….

In this virtual world VMware’s NSX is distributed across each VMware Hypervisor running on each physical platform…but it runs as though it is a single piece of software.  NSX is the NETWORKING portion that supports The Cloud. NSX knows how to emulate switches/routers/routing protocols/spanning tree/etc/support/etc….all in software. But most importantly…. when a guest moves between physical hosts NSX makes sure that the IP address, security context, peer communications, VPN, etc will never change – The Operational Context – Vmotion. NSX keeps track of all this inside NSX and when the guest moves, NSX keeps contextual info floating with it.

Think of Google. Thousands of Linux PCs out there and you never know or care which one you are executing on…and it may change moment to moment. All possible with their version of SDN.

Next up SDN…….

SDN for Dummies – Part Eins

I’ve been researching SDN, interviewing routing geeks, going to presentations and the one thing they all have in common is the blah blah. Like a bunch of music majors (FYI – I’m a music major)  turned SDN marketing geeks that can’t find a job and heard about SDN and now they have learned to use big words like ‘ecosystem’, ‘hypervisor’, ‘virtualize’, ‘east-west’, ‘tenant’, ‘orchestration’ and want to make a name for themselves. Ask them what SDN, Cloud, Hypervisor, mean and you will get 100 different blah-blah 2 hour speeches. Cisco ACI is really complex I still don’t understand it even after taking a class. Vmware seems to make it simple via their GUI. Tufin’s Ruvi Kitov has had the best perspective to date on how to manage this beast.

So I decided to decode the SDN blah-blah into my own Dreez blah-blah that maybe my mom (The Italian Tornado)

would understand.

In my previous rant on SDN I talked about how this baby will scale massively because scripts can generate 1000’s of objects/rulesets/firewalls in seconds, so the problem is who will manage this beast? CP and Tufin could capitalize on this next big hit.

But first let’s do a primer on SDN and compare were we are today to where we will be in 10 years.

Here is your basic boring enterprise network environment. Let’s start at a a ‘campus’ type environment. A PC is connected to a 3800 Cisco switch in the campus building and that has a leased dedicated 10g fiber to the datacenter 1 or 2  miles away to a Cisco 500 switch. At the campus, there is a firewall with max blades turned on. There are several geographically co-located buildings setup this way in a ‘campus’ network – high speed 10g (expensive) fiber connecting them together. Data is routed between the campus sites and data center (this is key remember this).

Remote sites have MPLS connections. What is MPLS you ask (this is key remember this):

1. Buy dedicated guaranteed bandwidth to remote sites
2. If you want you could run Layer 2 over these links . So in theory you could get rid of internal L3 routing (this is key) but current limitations on hardware and bandwidth to handle broadcasts restrict this ability.

So remote sites are connected on this dedicated bandwidth MPLS network with speeds of 52K dial-up line to the netherland like Zambia to Ethernet over Fiber 100 Mb at more civilized locales like England. These are connected with Cisco 6X00 routers.

My point of this discussion will be that you can predict the evolution of SDN based on network speeds and prices to remote locations. Just watch…..

Let’s go back in time…waaaay back…to when I had hair. Ethernet was at 1-10Mb 10BaseXXX 1/2 duplex and because of hardware limitations it could only support 10-100 devices all within 500 ft of each other (OK, my numbers might be off but you get the idea). One misbehaving PC sending out too many broadcast messages would bring the network to its knees. Ethernet broadcast storms are like a Wall Street trading floor, 100’s of people all yelling at the same time just slowing the whole thing down and you can’t hear anything. Because of advances in technology today you can have hundreds of devices on 10g Ethernet around the world (if you had enough money) and there is more technology to handle broadcast storms.

With that in mind let’s look at today’s remote sites. Today in Zambia the network link is so slow and unreliable that we have to have some of our servers (file, database, Active Directory) based locally in Zambia or else production would stop. Now what will happen as network speeds increase and become more reliable (Fiber All Around)?

You guessed it, we will then localize those servers back to the data center so they are easier to manage. Many companies already have remote sites with decent low latency bandwidth connectivity so those sites so you will not find any servers, just overpaid whining employees.

So let’s look at the campus infrastructure. This should look like remote sites 2025. They have high bandwidth low latency reliable connectivity to these campus buildings so no need for servers. So by 2025, the only real change will be faster connectivity of both fiber and wireless between my PC and the data center. No big change.

Now the fun part. Let’s look at the data center. Today the data center is filled with OEM equipment. OEM firewalls, database servers, file servers, etc – tied together with via this behemoth Nexus switch(s).Yes we have dramatically started to virtualize this world into VMware and so it is slowly reducing its footprint. As remote network speeds increase and the price of bandwidth decreases and applications migrate back from remote sites to the data center this evolution into the centralized virtual world will hasten linearly?? No I will say exponentially. (stay tuned, its all about the scripts).

Datacenter 2025 will look like this. Either a room filled with 1000’s of $100 gray market PCs running Linux Virtual Systems/VMware OR one big Borg Cube that has 1000’s of CPUs in it tons of memory running VMware or something similar. You can see this now with some of Ciscos products (talk more about this). (I won’t talk about public/private cloud services at this time). Why?

Think of google. Their datacenters are all generic Linux systems. Google and companies are DONE being wedded into the greedy hands of a single vendor. Technology is changing so fast, deployment times are reducing, and prices are dropping so dramatically in the virtual world that being wedded to a OEM is like an Carrie Fisher married to Attila the Hut, just not pretty (She was hilarious in that one Big Bang episode).

(sidenote: If you believe in The Borg, sell your Cisco stock….minimal need for network ports and routing…all done inside The Borg)

So basically, the network infrastructure is headed to fiber and fast wireless all around, 255 TB/sec check it out.

Ok, enough rambling get to the point. L3/routing is currently required because of:

• Router geeks seem to feel that there is some security advantages to subnetting.
• Firewall technology requires us to subnet so we can protect ‘zones’ of IP addresses
• Limit broadcasts to a subnet, if all systems in an enterprise would arp network would stop
• Route across WANs to remote sites (because you can’t arp to find a peer system)
• Networking’s legacy is based on L3. DNS and embedded IP addresses in apps.
• Available network address space. IPv4=2**32   <     EUI-64 MAC 2**64   <    IPv6 2**128

But sorry to say L3 people, notice how L2 is getting bigger and and L3 is becoming smaller as network bandwidth/speeds/latency improve? Notice how L3 diminishes as you virtualize onto a single Borg Cube? No WAN routing is required in a Borg cube. No IP ‘zones’ required if every virtual guest has a firewall and grouped by virtual host (say tuned more on this later). Fewer arp issues as backplanes get faster and broadcast dampening technology mature inside a virtual host.

Sorry to say L3 people, routing is slowly disappearing. Imagine an enterprise with only L2 worldwide! Imagine being able to fire all your L3 router geeks!

• What will happen to firewall rules? How do we separate networks?
• What will happen to L2 broadcast storms?
• Where does this leave Cisco/Juniper/Alcatel

IP addresses exist because of routing, what happens if we don’t need routing?

Oh yes, I can see all you Cisco and Security geeks roll your eyes. How can your comfy little world disappear from under your feet when you have mortgages to pay and boat loans to pay off?

[music stops]

But we still have mainframes

[music continues]

Well, you can relax IP addresses will be around for a long time just like COBOL is still out there….but you might want to think about sprucing up your resume.

In 2025, a CIO will wake up and decide he/she wants to spin up a 1000 server big data mining site to find aberrations in health care pricing. You get the phone, what do you do? Do you call India and start hiring deployment geeks for $2/hour? NO! You write a Python/PHP/Perl script.

for server= 1 to 1000 DO{

server_farm[server] = windowsserver.create_new; # create new server
assign_networking( server_farm[server] ); # assign networking template to server
assign_security_controls(server_farm[server] ); # assign security template to server
assign_application(application_ptr, server_farm[server]); # load application on server
start_server( server_farm[server] ); # start the server

}

Deployments will be like writing software…generate and destroy objects and constructs at line speeds. On you management station you group these 1000 servers into a group, create a firewall and build a policy that says:

# Allow users to connect
FROM: user_pc TO: server_farm ACTION: ACCEPT
# Nothing leaves the server farm
FROM: server_farm TO: NOT server_farm ACTION: DENIED

Do you see any IP addresses? Do you see teams of overpaid IT people running around plugging in cables and entering Cisco commands?

Welcome to 2025 Software Defined Networking……..

2015 CPX – R80 and CapsuleH

Summary: 2015 CPX was like a continuation of 2014 CPX. No big announcements, usual rah-rah. R80 and Capsule were the focus. As always highlight was talking directly with developers. Lunch was great.

---

R80: Dorit says its out now, techies say Q3. MDS version is still up in the air. R80 firewall in EA. So basically I can’t say when its coming out but I hope to god the QA people are busy. I actually bought some CP stock based on R80 release.

Capsule: Funny: Gil says “How many people have threat prevention on your mobiles?” about 2 people out of 1300 raise their hands. “See, we can’t even get CP people to use it…that’s why its a 5 year plan”. Crowd roars. (not direct quote but something like that).

True Story: I was in Costa Rica on guided tour on steep path on sheer cliff. Guy ahead of me asks his wife to take a picture of him with his iPhone. Wife steps back and almost falls off cliff. He yells “MY IPHONE!!!!”

My read of Capsule is that people care more about their mobile phones than they do their partners. Reduce their battery usage, screw up texting, block mobile data access and they will hunt you down and burn you in your bed. I agree with Gil. Until the bad guys trash your phone and the pain is worse then the impact of the security software, the market has yet to develop. Technology needs to catch up to support the additional load  on the device.

I spent most my time tracking down their progress on Software Defined Networking which I think looks exciting and hopefully will be CP’s next ride to the top with R80 management.

The tofu and quinoa warm dish was fantastic. The tofu had a bit of crunch to it.

So the rest of the show was a 2014 repeat telling you to turn on more security stuff, the end of the world is near,  the cemeteries of full of people that had computer viruses, we are all going to die.

Random Details in Random Order with Random Comments:

---

CP Strategy over the years:

• 2012 CP as security company vs product company- history
• 2013 3D security rah rah- that’s all history
• 2014 Software Define Protection
  • Management
  • Control
  • Enforcement
• 2015 Software Define Protection – 2 years in a row

I actually saw SDP described in several talks 2 years in a row by some of top management…so maybe it will stick. I just don’t get how the title has anything to do with the content and how it makes CP standout from the rest of the hoard. Everyone has management, control, enforcement. CP’s edge is Great Centralized Management.

So my frustration with Gil is he does not set CP’s strategy as “Centralized Security Management” and then follow up to say “Last year we said we’d do X, Y,Z and we did X and Y. By 2017 we will do 1,2,3,4. Capsule is good example, everyone and their mothers will have mobile protection…but imaging trying to centrally manage security on 100,000 mobile phones. Who is going to do that best? Why is CP better than competitors? By when? What does it look like? What do the analyst think? What kind of revenue numbers? What is the sales strategy?

(To be fair Dorit did some of this, but from a operation point of view not a visionary point of view)

But then again he does have a private jet and I drive a 2006 Scion.

Who is Check Point this year.

Some guy gave talk trying to prove with statistics that CP is the best.

• Best prevention software – Everyone says this, software is still maturing.
• Best management platform – Agree: but competitors are very close. Needs quality R80 release
• Best security DNA – Everyone says this but he was right – most people in CP have military backgrounds with the enemy 20 miles from your child’s bed so they do have a security mindset.

Featured Speakers:

• Michael Morell – FBI director: End of world is near, Chinese hacked his email and wife figured it out, he saw scary stuff
• Michael Chertoff Former Homeland Security Guy:End of world is near, he saw scary stuff

Threat Prevention: 

• AV is now useless, too many zero day attacks
• IPS going the way of AV
• Threat Emulation is the rage….until hackers put a “sleep(till Tuesday)” in their code
• AntiBot is OK, but using encrypted channels so look for known DNS and IP addresses
• Threat Cloudiness is a must to stay on top of zero-day attacks
• They bought Hyperwise and Lacoon because the above are pretty iffy, but no one could tell me what they do.

My read: CP’s blades are still maturing but their edge is single pane of glass centralized management. Threat Prevention is not a technical problem, its a people management problem. When the sh*t hits the fan, you want all silo’s in the organization looking at a single pane of glass…not 10 different “Best of Breed” solutions. Single pane of glass security management increases detection rates because people are familiar with a single product, reduces response times, and lowers TCO.  This is the value CP brings to the security marketplace.

R80

• Everyone I spoke to has a different release date. I’m OK with being late, it just has to have the quality this time. I even bought some stock betting on R80.
• I can’t get 2 people to give me the same picture on R80 MDS. Latest speech is it will be 1 executable, but you can sign into either MDS or SmartDashboard. Last year they said it was all merged…we’ll that ain’t merged. MDS is long on the tooth and needs more integration with SmartDashboard. Only 2 big differences are
  • you are suppose to be able to have multiple sections of global policy instead of just top and bottom.
  • global objects are broken into chunks instead of one big database
  • you can import chunks of objects into the domains
• Hit counts on objects
• Logging integrated into Dashboard
• I couldn’t get an answer if you can seamlessly copy between domains
• They realize the future is all about scripted access, so REST API and associated tools is huge
• Software Defined Networking integration looks cool

Dorit – President

• Roadmap – Nothing really new just bigger faster
• I thought this was impressive. A person in our group asked a question about some innocuous technical point on Amazon cloud. Dorit hunted her down 1 hour later to give her an answer…and there were 1300 people at the conference.
• Dorit also was very responsive to my issues. I heard from internal people that she was pushing buttons trying to make things happen.

Developers

• As always one goes to CPX to talk to the developers. The afternoons are were you really can connect with the muscle of CP and get the real story. And they can see your pain and try and make a difference.
• I spoke with several developers from Threat Prevention, SDN, R80, They really want to hear your pain and make a difference which is a  great feel.

SDN, Clouds

• Spent 1/2 the show tracking down SDN demos which I am excited about.
• R80 will integrate into SDN products. Saw some cool demos
• Separate blog coming

Tufin – Talking the Right Talk

• Tufin gave a pitch on Cloud Security Management and how big an issue it will be.
• They are dead  on with identifying the problem, Rubin was great
• In cloud and SDN objects/rules are created by scripts so the scalability and speed of deployment will be mind boggling. Imagine having a script that deploys 1000’s of servers and firewalls and rulesets in seconds. Next there is a network problem and you have to go find it.
• I’m not sure what their solution is about but they are only ones that can talk about management complexity we are weaving for ourselves.

Making LDAP/Identity Awareness SmartDashboard User Picker Go Faster…And even Fix it

So our SmartDashboard user picker keeps breaking. So turns out for Yet To Be Determined Reason (YTBD) the User Picker gloms onto an LDAP server specified in a random LDAP AU. I haven’t figured this part out yet. So if the LDAP server goes down or is in SIBERIA, your user picker experience will make you want to switch to Cisco ASA. Remember, the UserPick in Dashboard is making queries from YOUR PC!!!!!   So you need to find a LDAP server closer to your PC. The User Picker is pretty darn sensitive to latency so you won’t know if its broke or tired, it just randomly works. It took me forever to figure out how to make the UserPicker wire into an LDAP server that is faster. This is it

1. 1) Note what LDAP server the UserPicker is currently using by expanding the user list. In the example below it is going to the SIBERIA-DC.
2. .Now you have to go through all your AUs and figure out which AU points to the SIBERIA LDAP server. Hopefully you are able to change it to a DC that is more local to your UserPicker. You might have to duplicate this UA and assign the new one to the SIBERIA firewall and keep this one for the UserPicker.
3. If you have multiple DCs in your list, you have to pick the lowest latency one here. This is what decides what DC User Picker will use.
   

Yeah, I know its a hassle but I PROMISE you its fixed in R80. PROMISE!!!.

LDAP OUT!

dreez

Identity Awareness started to fail, Captive Portal broke – Certificates changed

This weekend our captive portals just stopped working. This obvious error told me a lot (not).

tcpdump was equally confusing..

.

Took me a while, but turns out AD certificates changed and no one notified us. I just happen to notice that the fingerprint changed when  I fetched it.

One of those “Thank god it wasn’t the firewall” days.

dreez