F5 LTM SNAT: only 1 outgoing connection, multiple internal clients
I have an F5 LTM SNAT configured: ltm snat /Common/outgoing_snat_v6 { description "IPv6 SNAT translation" mirror enabled origins { ::/0 { } } snatpool /Common/outgoing_snatpool_v6 vlans { /Common/internal } vlans-enabled } ... with a translation configured as: ltm snat-translation /Common/ext_SNAT_v6 { address 2607:f160:c:301d::63 inherited-traffic-group true traffic-group /Common/traffic-group-1 } ... with snatpool configured as: ltm snatpool /Common/outgoing_snatpool_v6 { members { /Common/ext_SNAT_v6 } } ... and finally, with the SNAT type set to automap: vs_pool__snat_type { value automap } The goal is to achieve a single Diameter connection (single source IP, port) between F5 and the external element, while internally multiple Diameter clients connect via F5 to the external element: However, what ends up happening with this SNAT configuration is that multiple outgoing Diameter connections to the external Diameter element are opened, with the only difference between them being the source port (source IP, destination IP and port remained the same). The external element cannot handle multiple connections per the same origin IP and the same Diameter entity (internal clients are all configured to use the same Origin-Host during the Capabilities Exchange phase). Is there a way to configure F5 to funnel all the internal connections into a single outgoing one?
diameter and ssl
Hi all, I have a question about diameter balancing with SSL client profile. I'm noticing that with diameter profile I'm not able to use SSL::disable and SSL::enable in irules. I tried this configuration for testing when CLIENT_ACCEPTED { SSL::disable } In http profile (I tried it just for test) it works well. In diameter profile it doesn't work. So my question is: Can I use SSL::enable/disable in diameter profile? I need this because my diameter client establish a no TLS connection with CER/CEA exchange and only after this exchange start the TLS handshake in the same session. So I'm looking if it's possible use irules to support this. Using a full TLS session or full no-TLS session everything is ok. Thanks, Davide
LBO or not, I want to break out...
This article was written by Peter Nas, Senior Solution Architect of F5's Traffix SDC solution For more than 10 years, the technology to offer local breakout (commonly known as LBO) exists, allowing the data use by roaming customers to be supported by the visited operator’s network. This is in contrast to the scenario in which data requests are sent back to the roamer’s home network, which of course, costs more. But despite the obvious fact that many people would like to get lower data roaming rates, a wish not limited to Europeans traveling in the EU, sadly it is not offered yet. I can definitely understand some key arguments why mobile operators are not inclined to offer LBO, particularly when it applies to their subscriber. I also understand (a bit) that visited networks don't want to offer LBO, but let's see if we are about to see a change. After all, roaming has been a significant source of revenue for operators on both sides for some time now. When I worked at a MNO over 10 years ago, I did some testing myself to see if and how LBO works. At the time, I became very enthusiastic and never expected it would take so long before this technology would be deployed on a large scale. In the early days of GPRS, indeed data roaming rates were also very high. However in those days, roamers used their mobile phones for data much more infrequently than when in their home network. And if you have been observing the investments that have been made by mobile operators and GRX operators (GPRS roaming operators) to allow good quality data roaming, I can understand that these investments need to be earned back before the business could consider offering LBO. In the meanwhile, I believe that many things have changed and surveys have shown that customers consider data roaming far too expensive. As a result, roamers typically switch off their data while traveling abroad (some recent figures show 73% of the roamers as silent roamers, meaning while abroad but disabled their device for data roaming). Now the EU Roaming Regulations, in effect since July 2014, is explicitly mandating EU citizens to have the right to use LBO (when offered by the visited EU network), and VoLTE (Voice over LTE) is expected to be available. Therefore, we are approaching the inflection point during which LBO will be a realistic option for roamers. If I was an IPX carrier how should I approach LBO? Today all users’ data is backhauled via IPX carriers to the home network. IPX carriers have various sources of revenues and transporting users’ data is one important source of revenues. Currently, the main advantage to use IPX carriers seems to be the ease of connectivity among MNOs. However, people expect prices for pure transport to decrease making new and differentiating services the way IPX carriers can stay competitive and valuable. It is simply a matter of time that IPX carriers will offer a wide range and the right destinations of roaming agreements that will bring prices down. So while anticipating that operators are willing to pay less per transported bit... and remaining confident in the escalating trend of high data growth in the future, would I advise MNOs to invest heavily in more transport capacity or try to be innovative by leveraging wide-scale LBO usage? Let’s look at it this way. Assume an MNO can achieve service differentiation by looking at what opportunities LBO would bring. Well similarly, there are opportunities around LBO for IPX carriers which must be looked at as LBO will reduce revenues from backhauled data. One interesting aspect of LBO is that the signaling for two additional Diameter interfaces, S9 for policy and Gy for charging, could be exchanged between visited and home networks, and if so, this will be done via an IPX network as per GSMA guidelines (IR.88). There are different views on whether or not using the S9 interface to exchange policy information between the visited PCRF and home PCRF, will be massively used once LBO is offered, but let's assume it will be used. In this case, an IPX carrier can offer various services around Diameter interworking, security and perhaps also screening, overload control, prioritization and potentially adapting policy rules and more. People who doubt the uptake of using the S9 interface might be more interested if IPX carriers could offer services that help visited networks control which policies can be applied in the home network or in the visited network. The offering around S9 signaling can be the same as what is currently offered for transporting and managing S6a signaling (for authentication and mobility management), but offers security, quality, and many more differentiating features. Another very interesting Diameter interface is the Gy, related to charging. Once LBO is offered, the visited network will have primary control of charging the visitor (for example to offer various ways how a customer can be charged, like per credit card, voucher, scratch card, loyalty points, other credits from OTT applications, etc.) but there is also interest by the home network to receive charging information. Again, an IPX carrier can offer various innovative services beyond just transporting Gy charging information between visited network and home network. As we discuss charging information, what comes to mind are the potential of services in the areas of security, priority, firewalling, interworking, overload control, enriching, for example. If you think about other creative services that a mobile customer like myself would like to have while roaming, there are more services that an IPX carrier is well positioned to offer. For instance, perhaps I’d like to choose the visited network that best fits to my needs (there could be static rules but also dynamic rules). For instance, intelligent steering in roaming could be a service offered by the home network, but perhaps might be offered by an IPX carrier, at least as an outsourcing partner for the various aspects of having a new Diameter based solution next to potentially existing SS7 steering. Some other ideas are in the area of OTT apps, such as enabling an IPX carrier to provide value add to the QoE of the apps that I am using while abroad. Also when looking at LBO, it might be an IPX carrier that hosts other parties who want to offer LBO, or the IPX carrier itself can provide its 'own' LBO services via a local breakout gateway that reduces the costs (in region or on the other side of the world). Also IPX carriers can start to offer MVNE services that enable MVNOs to operate in their specific niche by providing the infrastructure and other services around it. Much more value-add can be added by IPX carriers, and some will become a commercial success and others maybe not.... but if you don't explore, you'll never know. Let’s discuss some other value-add ideas in more detail in a next post, so stay tuned.
Sometimes a Hack is Not a Hack, but We Should Still Worry
#LTEWS #Security I was at a roundtable discussion recently talking about security in the mobile carrier networks. During the discussion the recently announced SS7 signaling hack was introduced as an example. I would propose that this vulnerability is not a hack, but just poor design where trust is poorly assumed. Before you scream that I have my head stuck in the sand and I am ignoring a real threat that exists today for all mobile users, let me explain. The ‘hack’ in question depends on an agent to pose as a carrier wanting to interconnect with another established carrier for roaming and message forwarding capabilities. This is where the trust is involved. Interestingly, this is not as hard to do as one might think. With all the small carriers around the world and the MVNOs popping up like rabbits, it is hard to validate an entity with a 100% certainty. Once the trusted connection is established, now it is possible to send SS7 messages that can gain information that one should not normally have access to. There have been NO cases where an agent with malicious intent has been able to establish themselves to be in a position to send and receive SS7 information without establishing a trusted connection via a wrongly trusted, but legitimate processes. The reason I do not call this a hack, is that there is nothing technical about the method to gain access. This is purely social engineering. I can pose as a hedge fund and potentially gain some access to a larger financial company’s network infrastructure through a dedicated partner connection, but is that a ‘hack’? There are no software bugs, buffers to overflow, root access to obtain, or any other technical function that one thinks of when hacking to accomplish this compromise. So far, there have been NO instances reported or claimed of someone consciously and maliciously hacking or gaining information via the SS7 protocol. Now that I have THAT out of the way, let’s talk about the security in the current and future generation mobile networks, LTE. LTE uses a completely different model which uses an all-IP infrastructure and new protocols including Diameter, and protocols like SIP for new functions such as VoLTE. And we have our favorite attack vector, DNS, pervasively within the entire control plane infrastructure. LTE has major security concerns that need to be addressed because the traditionally closed control plane network is becoming exposed to the external (and hacker) community. SIP messages can be generated from one’s smart device and forwarded directly into the IMS infrastructure. DNS is used to forward messages from service function to service function within this previously closed network. It is possible that Diameter messaging can be exposed since it is easy for a malicious agent to hide their identity so it is impossible to find the source of the compromise via a fake origin ID. I wrote an introduction to this problem in an earlier blog post, Mobile Service Providers are missing a Key Security Issue - And it is not DNS. This is the time to take a close look at the security profile of the control plane network and determine what assurances can be put in place to prevent the malicious attacks that will certainly be forthcoming if nothing is done.How Diameter routing for policy can become a differentiator when offering VoLTE services?
This blog post was written by Peter Nas, Senior Solution Architect, F5 In a discussion around the added-value of a Diameter Routing Agent (DRA) in a VoLTE deployment, I was asked the following questions and would like to share my response: How does the PCRF (Policy and Charging Rules Function) make decisions around policies? Are all policies defined per subscriber, or are some policies defined per bearer (e.g. default bearer, regardless of the identity of the subscriber)? Does the PCRF collect the subscriber-related policies from the subscriber’s HSS (Home Subscriber Server) record? PCRFs are very conducive to contain a combination of general policies and subscriber-specific policies, all depending on how an operator wants to use them (assuming these PCRFs are the kind that have wide flexibility). For example, you could have a default policy for a bearer, access-type (RAT is 3G, 4g, and onwards) location, or other parameters, plus the subscriber-specific parameters depending on the HSS profile (e.g. the services and options that the subscriber has opted for), and all on top of the subscriber’s quota or other variables. We have seen that OTT providers could register a certain subscriber as a premium user of their OTT video service (or any other service), which guarantees the subscriber the highest quality-of-service (QoS) possible. Obviously, this service level would be accompanied by the appropriate charging level when he/she wants to download or interact with a video or any other service from that OTT provider. A VoLTE scenario is perfect for this example. If you are a VoLTE subscriber, you deserve to receive the highest quality of voice. But what happens if during the VoLTE call, the same subscriber requests another IMS-based service? In that case, the operator may want to assign a dedicated bearer for that specific service, enforce session binding, and manage the QoS if the bearer is shared (this is the PCRF’s role). Otherwise, the quality of service of the VoLTE call would probably deteriorate. All of the above scenarios involve a mixture of PCRF profiles, in addition to information on the network state, type of access, type of device, in home network or roaming, if an OTT provider is involved, and other parameters. Obviously, there are many factors involved, both network related and subscriber specific which a Diameter Routing Agent (DRA) can manage and ensure that the information is transmitted to and from the PCRF assigned to the subscriber for the particular session. Finally, I believe more and more operators are beginning to use PCRFs to differentiate themselves from competitors, and not “just” for cost reduction. Ensuring that the PCRF receives the right information, and transmits the information back to the Policy and Charging Enforcement Function (PCEF) to apply the policies is the critical role of signaling (mainly Diameter signaling but not limited to). Therefore, a DRA with gateway functionalities, such as the F5 Traffix Signaling Delivery Controller (SDC) is the key enabler to benefit from cost reduction and competitive differentiation in many VoLTE scenarios.Why do you need a Diameter Routing Agent (DRA) in a VoLTE deployment?
This article was written by Peter Nas, Senior Solution Architect for the Traffix SDC Operators have begun to get more and more serious around deploying VoLTE (Voice over LTE) in their networks. Since the announcements of VoLTE services from some Korean and US operators, others, particularly in Asia, North America and EMEA, have launched or are about to launch VoLTE (see GSA announcement of 17th Sep 2014: 71 operators in 36 countries investing in VoLTE deployments, studies or trials, 10 operators commercially launched HD voice using VoLTE). More often than not, operators use a Diameter Routing Agent (DRA) to support correct routing and control of the Diameter signaling related to VoLTE. Basic session binding In 3GPP, a DRA is defined for session binding in IP-CAN sessions (equivalent to PDP context in 3G) towards a PCRF server. This was designed for multiple Diameter sessions in VoLTE in order to control the LTE and the IMS parts of the VoLTE service. To maintain an efficient and scalable network rollout, it is important that the LTE parts of an IMS VoLTE call, together with the IMS parts, are controlled by one and the same PCRF (server). Similarly, consistent policy rules need to be applied to the session that are related to the same VoLTE call. Let's explore in some more detail what needs to be managed by the same PCRF server and why. When using a VoLTE-enabled device, the mobile subscriber first needs to register to the network and establish the default data bearer to exchange data with the network or applications. This is followed by the authentication and authorization procedures, and mobility management communication between an MME and the HSS where the subscriber profile is stored. (Incidentally, the signaling for these procedures typically uses the Diameter S6a interface that is also often routed with help of a DRA). Now this device can establish the always-on LTE default user data bearer. In order to do so the device communicates with the PGW and establishes a user data session. For that user data session, in this case still the default bearer, the PGW needs to contact the PCRF via the Diameter Gx interface and receive the policy and charging rules for this customer's data session. Once the policies have been exchanged and applied by the PGW and sometimes there are other involved PCEFs (Policy and Charging Enforcement Function), the mobile user can either use Internet services via the established default bearer or in our scenario, opts to continue to establish a VoLTE call. To do so the VoLTE application on the handset will communicate (via SIP, over the established default LTE bearer) with the IMS network and its embedded VoLTE application server. First a SIP signaling bearer needs to be established after policy for that bearer is applied. To apply the policy, the IMS's P-CSCF needs to communicate via the Diameter Rx interface with a PCRF server. Actually, it needs to communicate with the same PCRF server that was already involved in managing the related LTE default bearer. This is exactly where the added-value of a DRA's session binding functionality becomes necessary, because the DRA has to search its memory for the same PCRF server that was used in the Gx session for that specific customer (e.g. specific IMSI and session ID). It has to match the unique and related information in the Rx signaling in order to make the same routing decision and end up at the same PCRF server. The relevant IMS information is the Framed-IP address because IMSIs are not usually required in IMS. A smart DRA has stored in its memory the association between an IMSI and Session-ID plus the Framed-IP address used by the device. If now that same Framed-IP address shows up in an IMS Diameter Rx message, a match can be made and the same routing decision can be applied. Now once the Diameter Gx for the LTE part and the Diameter Rx for the IMS part are bound to the same PCRF server we are almost there. Next comes the exchange and application of the policy and charging rules for the SIP Signaling bearer. And now we can move to the third key component of the VoLTE call and that is the SIP signaled voice. For voice signaling, the same PCRF server needs to be addressed, and the related IMS signaling is again exchanged via the Diameter Rx interface. Finally, once the policies and charging have been exchanged and applied, the VoLTE call can be made successfully. If there is a need for changing the policy or charging rules (for instance, if a customer reaches a certain threshold), than the same PCRF server can communicate via Gx to the LTE's PCEFs and via Rx to the involved IMS elements like the P-CSCF. In this way, the various sessions that are related to the same VoLTE service are managed consistently. Also when the VoLTE call is terminated the various sessions need to be released, except for the LTE default bearer, and the correlation between the LTE and IMS part of this VoLTE call can be cancelled. Other DRA added-value in VoLTE There’s additional value to the fundamental session binding functionality of a DRA. A DRA can enable optimal call management ensuring higher quality-of-service VoLTE calls. For instance, think of all the different vendors’ equipment that is needed to exchange Diameter Gx and Rx signaling. One example is when the LTE PGW has a different Gx implementation than the PCRF. In turn that PCRF can have a different Diameter Rx implementation than the IMS's P-CSCF node. Typically inside an operator's network, there will be various vendors for LTE, PCRF and IMS core network elements. And this is the norm in roaming use cases where the visited LTE network is out of control (meaning a different vendor) than the home IMS network, where the P-CSCF (and other elements) will be involved. In addition, once VoLTE takes off more substantially, the quantity of signaling also will take off and increase dramatically. Therefore, a DRA will play the most significant role in providing load balancing and overload control, both in normal circumstance but clearly also under special circumstances like when network elements went down and recover or other heavy signaling loads are occurring. A DRA could also prioritize VoLTE related signaling, over all the various Diameter interfaces. When serving this function, operators can provide a higher quality VoLTE service over other services, particularly when other services load the network. In this case, a network without this DRA functionality of prioritization, would experience degraded VoLTE service. There are more added-value functionalities – all made possible by a DRA, like VoLTE specific KPI generation. As time goes on and we experience increased use of VoLTE, we will learn more and more about how a DRA can improve the quality and efficiency of VoLTE and its related services. Peter Nas serves as Senior Solution Architect for the Traffix SDC team at F5 Networks and draws from more than 20 years of telecom experience to advise operators how to leverage Diameter signaling solutions to enable the optimal LTE experience. Peter joined F5 with the company’s acquisition of Traffix where he was responsible for global business development. Prior to joining Traffix, he worked at Tekelec focusing on market development for Diameter and SIP routing. In his days before Tekelec, he served as Core Network Engineering Manager at a prominent mobile operator in the Netherlands.
Sally Orders Lunch: Retail On-Line Payment
Sally is hungry but she left her wallet at the office. “I know, I’ll go to the Local Diner,” she thought. “Let’s see what looks good.” She opens the website and sees: “Yum, the hot dog looks good, and I’ll also have a coffee.” Sally clicks the two items and sees: When Sally placed her order, the Local Diner website established a session with Sally’s mobile service provider to get authorization for the purchase: The website requests the Diameter Routing Agent to make sure that Sally can pay for her order. Sally has a contract with her mobile provider that allows her to pay via her monthly bill or via a pre-paid account. The Diameter box checks with the carrier’s On-line Charging System and reserves the total amount of Sally’s lunch. Sally continues her walk to the Local Diner and thanks goodness that she pre-ordered because the line is out the door. She notices a short line, “Pre-Orders here.” Sally walks to the register and sees a placard: The placard is printed with invisible capacitive ink in a specific pattern that's detected by the touchscreen as multiple simultaneous finger presses. The arrangement of this pattern is used to link Sally’s phone with the Local Diner website. The website triggers a second set of messages to the Diameter Routing Agent that first verifies that the phone is actually Sally’s, then confirms the charge to the carrier’s billing system: The On-line Charging System assigns a transaction id and the Diameter Routing Agent sends the Local Diner website a receipt. The OCS settles the transaction by transferring funds to the Local Diner at the end of the day. The clerk sees Sally’s confirmation of payment on his screen so he hands over her order with a big smile. Sally’s phone displays the following: This customer scenario can be realized today using secure RESTful transactions between the Diner’s website, an F5 Signaling Delivery Controller and proven Diameter Credit Control Application messages to a carrier’s On-Line Charging System. The touch screen phone’s capability to read invisible ink is new technology but is currently available, without the requirement to download a reader onto the handset. Next: Sally Goes to the Grocery
