F5 BIG-IP MQTT protocol support and use cases in an IoT environment
The Internet-of-Things is a system of physical devices, vehicles, buildings, and any other items each provided with a unique identifier allowing them to communicate with one another without any human intervention. MQTT is a widely-used machine-to-machine connectivity protocol that helps these devices communicate and exchange messages. The wide adoption and popularity of the MQTT protocol led to its support in the BIG-IP version 13.0. MQTT is a publish/subscribe messaging protocol. A device such as a camera, heat sensor, lP-enabled light bulb, etc. can publish data to an intermediary module using the MQTT protocol. An application can then subscribe to this intermediary module and retrieve the published data. Intermediary modules are also known as message brokers. The BIG-IP with MQTT awareness can sit in front of the MQTT message brokers to provide scalability, security, visibility, and availability. Fig. 1 – Basic architecture of using the BIG-IP platform in an IoT environment. In an MQTT configuration, clients publish messages and the BIG-IP system parses those MQTT messages based on which it invokes MQTT specific iRule events if defined and performs connection based load balancing on the MQTT messages to a pool of message brokers. The message brokers then transport and route the messages to subscribing servers A typical BIG-IP MQTT configuration includes: MQTT pool of message brokers Are grouped together to receive and process traffic. After the pool is created, associate the pool with a virtual server. Some common open source message brokers examples are Mosquitto and VerneMQ iRules for MQTT Use iRules to exercise MQTT functionality, for example to log the messages that the BIG-IP system passes, or to pass the client certificate's common name in the CONNECT message Client SSL profile Use a Client SSL profile when you want the BIG-IP ® system to authenticate and decrypt/encrypt client-side application traffic Virtual server configured to use MQTT functionality For more details please refer to: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-iot-administration-13-0-0/1.html BIG-IP natively supports the MQTT protocol. BIG-IP has a full proxy architecture which makes BIG-IP itself an endpoint and an originator of the MQTT protocol. iRules take advantage of the deep understanding of the protocol and can be used at different events (specific moments within the session flow of a network connection, such as MQTT_CLIENT_INGRESS, MQTT_SERVER_INGRESS) to intelligently parse the MQTT protocol and make traffic decisions. Let’s explore some of the use cases using iRules such as load balancing and steering traffic based on a unique identified present within the MQTT protocol, preventing attacks based on TOPICS/LENGTH of a PUBLISH message, client authentication based on CN name present in the client certificate. Use Case: prevent MQTT DDoS attacks based on the below parameters Topic validation Validate the ‘TOPIC’ of a PUBLISH message and if it does not fit the validation criteria then drop the connection. This will prevent messages with bogus TOPICS from reaching the message brokers. And help in preventing MQTT DDoS attacks based on TOPIC. when MQTT_CLIENT_INGRESS { log local0. "CLIENT [MQTT::type]" if {[MQTT::type] eq "PUBLISH" } { # Check against a allowed topic. if { [MQTT::topic] eq "bogus/bogus" } { # Invalid topic log local0. " Topic is Invalid. Potential DDoS Attack -> Dropping Topic: [MQTT::topic]" drop } } } The above iRule can be enhanced to use data groups where the data groups will have the entire list of TOPICS and the [MQTT::TOPIC] can be checked against the data group MQTT PUBLISH message length validation An application will typically have knowledge about the size of the data that is being transmitted. Taking advantage of that knowledge the length of a PUBLISH message can be validated and if it does not satisfy the expected length then drop the connection. This will prevent large messages from reaching the message brokers and not overload the broker. when MQTT_CLIENT_INGRESS { log local0. "CLIENT [MQTT::type]" if {[MQTT::type] eq "PUBLISH" } { # Check length of message. if { [MQTT::length] > 100 } { # Invalid length log local0. " Length is Invalid. Potential DDoS Attack -> Dropping message: [MQTT::topic] : [MQTT::length]" drop } } } Use Case: pool selection/load balancing based on username as a unique identifier Use the username as a unique identifier to steer traffic to a message broker. This enables stickiness between an end user and a message broker by mapping a device/end user to a pool in the load balancer. The mapping helps in conditions where in a device needs to reconnect to the message broker on which the active client session lives and can use the state information present on the message broker to make decisions. when MQTT_CLIENT_INGRESS { log local0. "CLIENT [MQTT::type]" if {[MQTT::type] eq "CONNECT" } { # Select pool based on username, example license ID if { [MQTT::username] eq "D1111111" } { log local0. "Load balancing to pool MQTT-BrokerPool1" pool MQTT-BrokerPool1 } if { [MQTT::username] eq "D1111112" } { log local0. "Load balancing to pool MQTT-BrokerPool2" pool MQTT-BrokerPool2 } } } The above iRule can be enhanced to use data groups where the data groups will have the list of unique usernames. Multiple data groups can be defined, each one representing users for multiple Pools. The [MQTT::username] can be checked against the data group and based on that the pool selection can be made. Use Case: client certificate authentication over TLS BIG-IP can terminate MQTT encrypted SSL/TLS messages and then send the un-encrypted traffic to the backend Broker. This allows the Broker to scale as it can offload all SSL/TLS functions and configuration to the BIG-IP. In addition to terminating SSL/TLS the BIG-IP can use iRules to perform Client Certificate Authentication. The BIG-IP can embed the client CN name from the client certificate into the backend connection along with the username for authentication by the back-end Broker. when CLIENT_ACCEPTED { set cn "" } when CLIENTSSL_CLIENTCERT { log local0. " Parsing X509 Info for SSL Client Cert CN Name" set cn [findstr [X509::subject [SSL::cert 0]] "CN=" 3 ","] log local0. "Found Client Cert Common Name (CN) : $cn" } when MQTT_CLIENT_INGRESS { log local0. "MQTT Client MmessageTtype [MQTT::type]" if {[MQTT::type] == "CONNECT"} { log local0. "Connecting to Broker" if {$cn == ""} { # if we didn't see a client cert, return an authentication error MQTT::drop MQTT::respond type CONNACK return_code 5 MQTT::disconnect } else { log local0. "Passing Username and CN to Backend for Authentication" log local0. "MQTT Username: [MQTT::username]" log local0. "Username: [MQTT::username] CN: $cn" set mqttuser [MQTT::username] MQTT::username "$mqttuser $cn" } } } Conclusion Bookmark this page if you are interested in learning more. We will be update this blog with new compelling IoT features developed by F5 for the upcoming BIG-IP releases. Do you have a suggestion for an IoT related topic that you would like for us to cover? Please leave a comment on this post if you do. References https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-iot-administration-13-0-0/1.print.html https://devcentral.f5.com/s/articles/lightboard-lessons-iot-on-big-ip-24923?tag=lbl https://devcentral.f5.com/s/articles/the-iot-ready-platform https://f5.com/resources/white-papers/tmos-redefining-the-solution https://devcentral.f5.com/s/articles/the101-irules-101-events-amp-priorities https://en.wikipedia.org/wiki/MQTT https://mosquitto.org/Our Five Senses on Sensors
Aristotle (384 - 322 BC) is credited as the first person to classify our five sense organs: sight, smell, taste, touch, and hearing and Immanuel Kant, a famous philosopher from the 1700s said that our knowledge of the outside world depends on our modes of perception. Our highly developed organs of the eyes, ears, nose, tongue and the skin on your hand provide the sensing equipment necessary to send that information to the brain. In some cases, one of the sensors might not work properly in the case of the blind or deaf, yet the four other senses are heightened and exceed normal operation to make up for the missing information. Daniel Kish, for example, uses echolocation like a bat to see the imprint of the sound waves as they bounce back. Pretty cool, eh? Today, we're building gadgets that are used in conjunction with or completely taking over the the tasks of the eyes, ears, nose, tongue and hands. Things that were always part of our body are being replaced with micro-chipped things that act like, attach to - or better yet - integrate with our body. Sight: Of course there are security cameras to help us see our homes when we are away and most of us have heard of Google Glass but there are now eyeglasses being prototyped by BMW’s Mini division. They are combining the wearable with the connected car. These glasses communicate with the car via WiFi and offers a heads-up display like no other. While you can still see the real world, the glasses offer an overlay of speed, navigation, backup cameras and more. You can see just how close you are to the curb from the wheel's point of view. You can also look at a street sign and have it come to life with other overlays or additional info. While most of the data is just telemetry for now, engineers are looking to possibly incorporate driving features within the view. This is where IoT gets interesting - where one is used to compliment another. Also, Swiss engineers have developed a camera based on the human retina. Understanding the biology of the real thing, they've made a more efficient camera. Smell: Although there were attempts earlier, in the 1940-50's, Hans Laube created a system called Smell-O-Vision which would emit odors during the movie so the audience could smell what was happening in the movie. It was only used once. GE also developed a system in 1953 that they called Smell-O-Rama. Now you can get a smell app on your phone. ChatPerf is a thumb-drive-sized atomizer that plugs into your mobile device so it can be triggered to release specific odors on command. But those are scents out. Machines that can whiff stuff in have been around awhile. Think of your smoke, carbon-monoxide or radon detectors. Today we have wearable vapor sensors that can smell diabetes. Scientists have figured out how to use a sensor to identify the odor from melanoma to detect this form of skin cancer. Those human skin cells give off an odor that doctors can pick up with a sensor. And scientists in Israel who have already developed a nanotechnology breath analyzer for kidney failure are working on one that can distinguish between the breath of a lung cancer patient verses a healthy exhale. Crazy! Hearing: According to U.K. firm Wifore Consulting, Hearable technology alone will be a $5 billion market by 2018. Roughly the size of the entire wearable market today. Ears are able to capture things like oxygen levels, electrocardiograms, and body temperature. While sound drives the bulk of technology within this space, those ear buds could soon have technology that not only sends sounds but also captures some of your body information. And it is small enough and discrete to wear everywhere rather than carrying a mobile device. Initial uses trend with fitness. Ear buds that play music but also give you feedback on your workout. There are also smart earrings that monitor heart rate and activity. I've always said that there will come a time when we all have IPv6 chips in our ear and we'll just tug the lobe to answer a call. Carol Burnett would be proud. Touch: Want to give a robot the ability to feel? Done. Researchers have developed a flexible sensor able to detect temperature, pressure and humidity simultaneously and a big leap towards imitating the sensing features of the human skin. While still in the early stages, future sensors could be embedded into the "electronic skin" of prosthetics, allowing amputees sense environmental changes. Another is BioTac, a fingertip that can sense force, temperature, and vibration—in some cases better than a human finger. With laser 3D printing, some orthotics can be delivered in hours rather than months. Taste: Sweet, sour, salt and bitter used to be the domain of the tongue. Soon, electronic 'tongues' could be used to monitor the quality control of bottled water. Using chemical sensors, researchers in Texas have demonstrated that the electronic tongue can 'taste' different solutions. The sensors responded to different combinations of the four artificial taste elements with unique color combinations of red, green and blue. This enabled the device to analyze for several different chemical components simultaneously. I've written about smart chopsticks that can detect oils containing unsanitary levels of contamination, a fork that monitors how many bites you take and a smart cup that counts the amount and calories you drink. This is the Internet of Food. Wearables make technology personal and our five senses are what helps us navigate life, gives us perspective. Who would have thought that an individual's perspective would someday become embedded within coded software. ps Related: Wearables + Connected Cars = IoT Heaven Five ways retailers can start using IoT today Lesson: How Do Human Sensors Work? Hearables - the next big thing in wearable tech Human Touch: Sensor Lets Robots 'Feel' They've Got It Licked - Artificial Sensors Can Taste What's In A Complex Mixture Innovative Technology Powers the Wearables Movement My IoT Articles Technorati Tags: iot,wearables,senses,sensors,things,humans,hearables,sight,sound,smell,touch,taste,silva,f5 Connect with Peter: Connect with F5:Wearing Emotions on Your Sleeve...Literally
Imagine if your emotions and feelings could be measured, tracked and included in a data graph. I'm sure you've heard the saying 'wearing your heart on your sleeve' to indicate that someone expresses their emotions freely or exposes their true emotions without caution. This can be good in that you become open and vulnerable when showing your true feelings but can jade areas like composure in situations where you might be frustrated or irritated. I tend to be fairly open with my emotions. There are a few stories about the origin of the saying going back to the Middle Ages. Emperor Claudius II felt unattached men make better warriors so he outlawed marriage. To alleviate some of the grievances, every year during the Roman festival honoring Juno, he'd allow temporary coupling where men drew names to determine who would be their lady friend for the year. The man would wear her name on his sleeve for the festival. Around the same time, when knights performed jousting matches, they'd dedicate their match to a lovely lady of the court. By wearing her hanky around his arm, he was signaling that he was defending her honor. And in Shakespeare's Othello, Iago confesses, For when my outward action doth demonstrate The native act and figure of my heart In complement extern, ’tis not long after But I will wear my heart upon my sleeve For daws to peck at. I am not what I am. – Othello, Act 1, Scene 1, 61–65 Whatever the origin, humans are emotional creatures. We typically make choices based on emotion, even though we'd like to think it was a rational decision. We may try to hide our emotions as to not upset or reveal something to another person. Often called a Poker Face. But imagine if your emotions and feelings could be measured, tracked and included in a data graph. Other than a polygraph. Daydream no more. There are now wearables that track your emotions. This is not your father's old-skool mood ring but devices that read your current emotional state and attempts to sooth and lower stress levels by encouraging deep breaths and relaxation techniques to get you through the haze. Sensors that gather skin temperature, sweat gland activity and blood pulse along with movement gauge your activity level. From that, it generates a graph on your mobile phone so you can see when your stress levels peaked and the mood at the time. You can see real time or over the course of the day. Emotional analysis in your pocket...or sleeve if you got one of those runner's arm band things. I'm sure someone will create a shirt that has color changing sleeve threads depending on a person's emotional state. The Iagonaut. This is not the future but today. A Fitbit captured the moment of a broken heart during a relationship ending phone call. This man was wearing his Fitbit when the unexpected call came and his daily graph tells the whole story: Koby (@iamkoby) shared his heart wrenching moment (and graph) on Twitter and it saturated the internet. The red arrow indicates the moment that the news hit him. Instantly, his heart rate jumped from 72 to 88 beats per minute and stayed high for the rest of the day. Clearly this healthy, athletic person was under duress and if you couldn't tell by the yellow peak marks, he had trouble sleeping that night. Talk about exposing your emotions with technology. Would you share your sleeve with the world? ps Related: Fitbit captures exact moment man's heart breaks The Origins of Wearing Your Heart on Your Sleeve Forget fitness, this wearable tracks your emotions Connecting the Threads The Digital Dress Code Wearables Head to Tail Gartner Says Worldwide Wearable Devices Sales to Grow 18.4 Percent in 2016 Technorati Tags: iot,wearables,emotions,humans,stress,sensors,silva,f5 Connect with Peter: Connect with F5:Is 2015 Half Empty or Half Full?
With 2015 crossing the half way point, let's take a look at some technology trends thus far. Breaches: Well, many databases are half empty due to the continued rash of intrusions while the crooks are half full with our personal information. Data breaches are on a record pace this year and according to the Identity Theft Resource Center (ITRC), there have been 400 data incidents as of June 30, 2015. One more than this time last year. And, 117,576,693 records had been compromised. ITRC also noted a 85% increase in the number of breaches within the banking sector. From health care to government agencies to hotel chains to universities and even Major League Baseball, breaches and attacks are now a daily occurrence. Cloud: Who would've thought back in 2008 that this cloud thing would now be half full? Over the last couple years, the 'cloud' has become a very viable option for organizations large and small. It is becoming the platform for IoT and many organizations such as Google and GE are now moving critical corporate applications to the cloud. While hybrid is the new normal remember, The Cloud is Still just a Datacenter Somewhere. DNS: While IPv4 addresses are now completely empty, DNS seems to be half to almost full in 2015. DNS continues to be a target for attackers along with being an enabler for IoT. It is so important that Cisco recently acquired OpenDNS to help fight IoT attacks and the courts got a guilty plea from an Estonian man who altered DNS settings on infected PCs with the DNSChanger malware. I think of DNS as a silent sufferer - you really don't care about it until it doesn't work. Start caring this year. Internet: Full but still growing. As noted above, IPv4 addresses are gone. Asia, Europe, Latin America and now North America have run out of IPv4 addresses and have exhausted their supplies. If you're wondering how to handle this glass, F5 has some awesome 4to6 and 6to4 solutions. IoT: Things, sensors and actuators are all the buzz and are certainly half full for 2015. At this time last year, IoT was at the top of the Gartner Hype Cycle and it has certainly not disappointed. Stories abound about Internet of Things Security Risks and Challenges, 10 of the biggest IoT data generators, the Top 10 Worst Wearable Tech Devices So Far, The (Far-Flung) Future Of Wearables, along with the ability to Smell Virtual Environments and if We Need Universal Robot Rights, Ethics And Legislation. RoboEthics, that is. Mobile: We are mobile, our devices are mobile and the applications we access are now probably mobile also. Mobility, in all it's connotations, is a huge concern for enterprises and it'll only get worse as we start wearing our connected clothing to the office. The Digital Dress Code has emerged. Mobile is certainly half full and there is no empting it now. Privacy: At this point with all the surveillance, data breaches, gadgets gathering our daily data and our constant need to tell the world what we're doing every second, this is probably bone dry. Pardon, half empty, sticking to the theme. That's what I got so far and I'm sure 2015's second half will bring more amazement, questions and wonders. We'll do our year in reviews and predictions for 2016 as we all lament, where did 2015 go? There is that old notion that if you see a glass half full, you're an optimist and if you see it half empty you are a pessimist. Actually, you need to understand what the glass itself was before the question. Was it empty and filled half way or was it full and poured out? There's you answer! ps Related: It's all contained within the blog. Technorati Tags: f5,breach,security,cloud,dns,iot,mobile,2015,silva,empty or full Connect with Peter: Connect with F5:Internet of Food
For those of you who like to post food pictures, this is something I can see being a benefit. Smart Chopsticks! Yup, you heard that right. Soon you'll be able to poke that dim sum and know if the food is tainted. Baidu, China's internet giant, unveiled them at their annual conference last week. While not ready for the mass market, Baidu says the chopsticks can detect oils containing unsanitary levels of contamination. They predict that you'll be able to detect the origin of oil and water and other foods...and whether they’ve spoiled and their nutritional content. You can hook them up to a smartphone to capture the content. They have a video which shows them dipping the chopsticks in olive oil and getting a 'good' reading and then doing the same with recycled oil and getting a 'bad' reading. As of today, the chopsticks only measure the freshness of cooking oil but future chopsticks also will be able to measure PH levels, temperature and calories. Of course I did a little digging to see what other utensil type things have gotten smarter. At CES 2013, Hapi Labs shared their Hapi Fork. A little bigger that your regular fork but after a charge, it'll monitor how many bites of food you take and at what rate. If you try to stuff your mouth with more than 1 bite every 10 seconds, the fork will vibrate to tell you to slow down. With USB, you can upload the data to track your eating or share with friends along with the plate in front of you. How about an instrument which tells you when you're about to bite the inside of your mouth? Then we got the Smart Cup, which counts the number of liquid calories you are two-fisting. Vessyl is a cup designed to automatically determine what’s been poured into it and track what you’re drinking in real-time. Whatever you pour into it, coffee, soda, juice, the sensors break it down to the molecular level to identify the beverage. It can even differentiate brands. Imagine the Pepsi Challenge in the one of these. It gives calorie count plus total grams of sugar, fat, protein, sodium and caffeine. You then connect to the app and it stores the drink along with making suggestions on healthier choices. Bad Bourbon...but so good. I know there are already smart refrigerators but I wonder what they'll be in the future. I was thinking about a fridge that had Rubik's cube type inside and based on whatever the sensors pick (smelly, past date, UPC, recall, whatever), those cubes move to the front so you can see what's about to spoil or needs to be eaten. How many times have you pulled a few things out and suddenly seen the science experiment covered in plastic wrap? This Internet of Things is branching in so many directions and it's interesting, at least to me, just how many items are starting to get sensors. The food supply has had it's share of recalls, contaminations, cover ups and other challenges and smart utensils really could be a life saver for some people, especially with food allergies. For me, it would be pretty cool to stick some food to find out if there is any lactose in it and then predict how soon I'll be bending over in stomach pain. That's smart. ps Related: 'Smart Chopsticks' Can Detect Bad Food Is Your Food Safe? New ‘Smart Chopsticks’ Can Tell Vessyl: A Smart Cup That Counts Liquid Calories CES 2013: Smart Utensils Remind You to Chew Your Food Is IoT Hype For Real? Internet of Things OWASP Top 10 Welcome to the The Phygital World Technorati Tags: iot,things,chopsticks,utensils,smart,sensors,nouns,silva,f5,food Connect with Peter: Connect with F5:Intelligent DNS Animated Whiteboard
DNS will become even more important as additional sensors, monitors, actuators and other 'things' connect to the internet. It helps those devices like refrigerators and automobiles get their updates and helps us people find those things in our digital world. Here is a short Whiteboard explaining how F5 can help solve DNS challenges. And check out our Intelligent DNS Scale Reference Architecture which delivers the peace of mind that comes with knowing that your web applications will respond to all DNS queries—keeping your content and applications available to your users wherever and whenever they want to access them. ps Related CloudExpo 2014: The DNS of Things GartnerDC 2013: Intelligent DNS Scale Reference Architecture The DNS of Things DNS Does the Job A Living Architecture Technorati Tags: dns,f5,iot,things,reference architecture,availability,silva Connect with Peter: Connect with F5:Using F5 BIG-IP and Solace Open Data Movement technology for MQTT message routing and delivery
The "Internet of Things" (IoT) has the potential to not just impact the way we live and work, but to disrupt entire industries. Some of the major industries that are driving innovation in IoT include manufacturing, transportation, and utilities. In this post I’ll talk about an example of how digital manufacturing is helping automobiles be more intelligent. There are millions of connected automobiles that have software running on them: from programs that keep GPS maps up to date to sensors sending vehicle speeds or temperature information. This information typically is being sent to a centralized management system that enables intelligent decisions, and those back-end systems also need to send data, instructions, and updates to the cars. We are actively working with a leading multinational automotive company. In this deployment the management system uses MQTT to send notifications to cars that a new software update is available for download. It is critical that these messages are received by the connected cars, but message delivery can be delayed if the car can’t be reached because it’s out of range, or driving through a tunnel, or even if cellular networks are congested. Using the Solace message broker To ensure eventual delivery in such situations, you can have the management system send messages to a message broker that in turn distributes them to intended recipients. This decouples your architecture so the many elements of the management system don’t need to worry about the specific destinations to which each message must be delivered, nor track delivery status. They simply send a message to the broker which A) takes care of routing it to requisite destinations, and B) stores a copy of it until every vehicle that needs it has confirmed receipt. Basic IIoT architecture for connected automobiles Before diving deeper, let’s look at the architecture that is used in the above use case. The idea is the same, but to support the numbers of connected vehicles and volume of data involved, it’s necessary to implement multiple message brokers. This architecture is provided by Solace which uses a novel architecture that enables efficient publish/subscribe distribution of data and can scale to millions of connected devices. (see Fig 1.). Back-end applications connect to a single broker (core message broker) to send a message to any vehicle, and can use messaging techniques preferred by IT applications such as JMS, AMQP and Node.js. The core message broker is communicating to several edge message brokers through internal messaging. The data for a particular vehicle is routed through one edge message broker and delivered to the vehicle in the matter conducive for it, in this case MQTT. In the diagram, Vehicle 1 connects to Message Broker 1. That means that messages sent from the management system to the core message broker that are intended for Vehicle 1 only need to go to Message Broker 1 Fig. 1 – Basic IIoT architecture for connected automobiles This two-tier approach provides a simple and powerful scaling architecture for north-south communication, since more connected cars can be added by adding more edge message routers without affecting the existing system. BIG-IP and persistence For this architecture, we’re aiming to achieve two things: First, we want to relieve the management system of the burden of keeping track of message delivery to potentially millions of vehicles. The Solace message broker uses MQTT QoS Level 1 which guarantees that a message will be delivered at least once to the receiver. The message is persisted in the edge message broker which allows the backend IoT application to publish messages with confidence that they will eventually reach their destination, but without needing to keep track of message delivery status. Second, we need to make sure that the vehicle connects to the right message broker so it can receive its messages. This can be achieved by managing a 1:1 mapping between the edge message broker and the vehicle. Fig. 2 – F5 BIG-IP in the IoT architecture BIG-IP version 13+ helps to achieve the 1:1 mapping with support for MQTT message parsing. It sits in front of the message broker and parses the MQTT messages – using iRules – exchanged between the vehicle to the message broker. Data groups on the BIG-IP are used to map a vehicle using a unique Identifier to a pool of message brokers. Using iRules every MQTT message is parsed, then the data group lookup routes the data to the correct pool of message brokers. This helps to achieve a “sticky” load balancing solution so that when a vehicle comes back online it will always get routed and connected to the correct message brokers where the connection state for that vehicle is known to be maintained. We say a “pool of message brokers” in order for the brokers to provide a highly-available service. Here is some sample code of an iRule that helps with achieving persistence or sticky load balancing: when MQTT_CLIENT_INGRESS { log local0. "CLIENT [MQTT::type]" if {[MQTT::type] eq "CONNECT" } { # Select pool based on vehicle ID if { [MQTT::username] eq "D1111111" } { log local0. "Load balancing to pool MQTT-BrokerPool1" pool MQTT-BrokerPool1 } if { [MQTT::username] eq "D1111112" } { log local0. "Load balancing to pool MQTT-BrokerPool2" pool MQTT-BrokerPool2 } } } Conclusion IoT use cases which benefit from having a guaranteed delivery of messages can take advantage of F5’s persistence capabilities. The architecture described above means that specific edge broker instances will maintain 'state' for specific connected vehicles. This requires the MQTT load-balancing to be sticky across sessions. BIG-IP version 13+ supports MQTT message parsing using iRules and thereby provides a key functionality in achieving the end-to-end goal of the solution for this type of architecture. The industries that are embracing “Internet of Things” applications are still in the early stages of innovation, but market leaders are architecting now for scale and resilience so they can automate more and more processes with a single infrastructure. The automaker in this example has chosen F5’s BIG-IP solution for 1:1 mapping of cars to message brokers, and Solace’s Open Data Movement technology as the MQTT infrastructure for message routing and delivery. The combination provides an elegant solution that can scale to millions of connections to support an increasing number of message exchanges between the vehicles and back end systems as their telematics and in-car services get more sophisticated.Internet of Things OWASP Top 10
The Open Web Application Security Project (OWASP) is focused on improving the security of software. Their mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks and their OWASP Top 10 provides a list of the 10 Most Critical Security Risks. For each risk it provides a description, example vulnerabilities, example attacks, guidance on how to avoid and references to OWASP and other related resources. Many of you are familiar with their Top 10 Most Critical Web Application Security Risks. They provide the list for awareness and guidance on some of the critical web applications security areas to address. It is a great list and many security vendors point to it to show the types of attacks that can be mitigated. Now the Internet of Things (IoT) has its own OWASP Top 10. If you've lived under a rock for the past year, IoT or as I like to call it, the Internet of Nouns, is this era where everyday objects - refrigerators, toasters, thermostats, cars, sensors, etc - are connected to the internet and can send and receive data. There have been tons of articles covering IoT over the last 6 months or so, including some of my own. The OWASP Internet of Things (IoT) Top 10 is a project designed to help vendors who are interested in making common appliances and gadgets network/Internet accessible. The project walks through the top ten security problems that are seen with IoT devices, and how to prevent them. The OWASP Internet of Things Top 10 - 2014 is as follows: 1 Insecure Web Interface 2 Insufficient Authentication/Authorization 3 Insecure Network Services 4 Lack of Transport Encryption 5 Privacy Concerns 6 Insecure Cloud Interface 7 Insecure Mobile Interface 8 Insufficient Security Configurability 9 Insecure Software/Firmware 10 Poor Physical Security You can click on each to get a detailed view on the threat agents, attack vectors, security weaknesses, along with the technical and business impacts. They also list any privacy concerns along with example attack scenarios. Good stuff! ps Related: The Icebox Cometh The Applications of Our Lives Standards for 'Things' Securing the Internet of Things: is the web already breaking up? 4 things that will happen in the Internet of Things space in 2014 Tech's brightest unconvinced by internet of things OWASP Internet of Things Top 10 Technorati Tags: iot,things,owasp,security,top10,privacy,silva,f5,nouns Connect with Peter: Connect with F5:Is IoT Hype For Real?
It is only fitting that the 20th anniversary of the Gartner Hype Cycle has the Internet of Things right at the top of the coaster. IoT is currently at the peak of Inflated Expectations. The Gartner Hype Cycle give organizations an assessment of the maturity, business benefit and future direction of more than 2,000 technologies. The theme for this year's Emerging Technologies Hype Cycle is Digital Business. As you can see, being at the top really means that there is a ton of media coverage about the technology, so much so that it starts to get a little silly. Everyone is talking about it, including this author. What you can also so is the downward trend to follow. This is the trough of disillusionment. Gamification, Mobile Health Monitoring and Big Data all fall into this area. It means that they already hit their big hype point but doesn't necessarily mean that it's over. The slope of enlightenment shows technologies that are finally mature enough to actually have reasonable expectations about. Each of the technologies also have a time line of when it'll mature. For IoT, it looks like 5 to 10 years. So while we're hearing all the noise about IoT now, society probably won't be fully immersed for another decade...even though we'll see gradual steps toward it over the next few years. Once all our people, places and things are connected, you can also get a sense of what else is coming in the Innovation Trigger area. Come the 2025 time frame, things like Smart Robots, Human Augmentation and a Brain Computer Interface could be the headlines of the day. Just imagine, instead of having to type this blog out on a keyboard, I could simply (and wirelessly) connect my brain chip to the computer and just think this. Hey, Stop reading my mind!! ps Related: Gartner's 2014 Hype Cycle for Emerging Technologies Maps the Journey to Digital Business Chart of the Week: The hype cycle of emerging technologies The Internet of Things and DNS F5 Predicts: Internet of Things Drives Demand for 'Social Intelligence' Internet of Things OWASP Top 10 The Icebox Cometh Technorati Tags: iot,things,sensors,nouns,gartner,hypecycle,media,silva,f5
Gating the IoT
Your car. My toaster. Our lights. The neighbor’s thermostat. With an average of 7.8 connected devices per home, according to recent surveys, there are twice as many “things” in the house as the average 3.14 people per household in the US in 2015. And all of them are “talking”. Not all talk to each other, yet, though the foundation for that is clearly laid out. But all of them talk to apps which talk to them over the Internet. When you or I interact with that app, we do so via HTTP (hopefully secured). Whether it’s via a native mobile app that uses APIs or a modern web app is irrelevant; it is safe to say that both do so via HTTP. But when things report in, it’s not so clear that they do so using HTTP. Oh, some do, certainly. But as the form factor for these things decreases it becomes increasingly difficult to manage power and compute in a way that’s supportive of heavier frameworks and protocols, like HTTP. That’s why IoT specific protocols have emerged. Protocols like MQTT (MQ Telemetry Transport) and AMQP (Advanced Message Queuing Protocol) that eliminate reliance on HTTP (but remain TCP/IP based) and even those like CoAP (Constrained Application Protocol – RFC 7252), which seek to minimize the impact of HTTP by optimizing a subset specifically for machine-to-machine (M2M) communications. Publish/subscribe (usually simplified to pub/sub for brevity) models are nothing new in the world of applications. Message queuing is one of the ways that applications have always shared data, long before the days of the Internet became popular. Back then we implemented using C/C++. Then Java took the world (and the Internet) by storm and we learned how to use JMS (Java Message Service). All pub/sub based protocols can be distilled down to a single, underlying concept: messages are “routed” based on “topics”. This should sound familiar to those of you who have to “route” URIs. Page routing, app routing, content switching. We call it many different things but ultimately, it’s the same concept. Given a unique identifier in the application layer, requests are routed to the designated endpoint. With pub/sub protocols that is a message broker. For URIs, it’s generally an app or API hosted on a web server. The difference with IoT protocols is that they are not HTTP-based, for the most part. They ride atop TCP/IP but are purposefully designed to be lightweight. This means that the (growing) data originating from the 7.8 devices in your home is being transported via something other than HTTP. The thing is that the receiver (the message broker) needs to be scaled and secured, too. One of the complications, as it were, is that “things” like to have persistent connections. That’s because communication is bidirectional and asynchronous. Setting up connections via TCP is well-understood, and it’s a laborious chore that consumes CPU cycles that introduce latency into the equation. Latency that today’s consumers don’t tolerate. A persistent connection enables things to constantly communicate if necessary, and to receive updates with the immediacy that is not only desirable to some consumers, but necessary for others (industrial IoT relies on immediacy). This puts pressure on brokers in terms of capacity, because every connection counts against their total capacity to handle things. That generally means some sort of load balancing-capable proxy in front of the brokers to ensure messages are delivered to their destination. Devices generate a lot of data, after all, and they’re expected to work 24/7. That, in turn, puts pressure on security ops to ensure that every connection counts. You don’t want to waste resources on a connection to a thing that isn’t valid. You don’t want to use up CPU cycle processing messages that aren’t valid. While most attacks today have focused on harnessing the power of millions (literally millions) of compromised devices around the Internet, like any public-facing service, the IoT message brokers in the data center (cloud or on-prem) are vulnerable to attack, and in particular, to DoS attacks. That’s because they rely on the concept of topics as a core processing trigger. Topics might include “house/temperature” or “/house/temperature/alerts” or simply “house/#”. Those topics inform the message broker what to do and how to handle the data. But what happens if it receives a topic it doesn’t understand? And what if that happens a lot. Like, more than the broker can handle? Exactly. Resources are needlessly consumed and the broker might become overwhelmed and unable to process legitimate messages. It’s the same old story – exhaust the endpoint and deny service. So like most web-based, public-facing services, an IoT broker – whether speaking MQTT or CoAP or some other pub/sub protocol – needs some level of protection against malicious attempts to confuse and confound it. Hence, you’re going to need to gate the IoT. This is where I note that this will be an emerging market. Like XML and SOA and APIs before it, there will be IoT gateways. They will be built with the premise of protecting and scaling message brokers, and they will speak the language of the IoT. To do that, however, the gateway will need to speak “secure” protocols, too, like TLS. Inbound data might be malicious, but it’s hard to tell under all those encryption. Gateways, then, will need to the visibility to peer inside messages and inspect topics to ensure validity before passing them on to message brokers. We might not call them IoT gateways. We might call them IoT proxies, or tack on a specific protocol and call them MQTT proxies or gateways. But at the end of the day they will operate on the same principles that have long defended and scaled the protocols that enable communication over the Internet. Whatever they are called, these solutions will need to be able to “speak” the language of IoT, namely protocols like MQTT, CoAP, and AMQP. That’s because they must be able to understand how to identify topics and execute logic to determine the validity of those topics, to prevent brokers from needlessly wasting precious resources on processing and dealing with those that are not legitimate, and may in fact be malicious. If we’ve learned anything from the application and messaging protocols of the past, it’s that they can and will be manipulated and exploited for nefarious purposes. Whether it’s to exfiltrate data or to cause a denial of service, attackers will be targeting the systems on which this rapidly growing market of IoT is dependent. An ounce of prevention is still worth a pound of cure. Stay safe out there.
