TR-069 Dynamic DNS (DDNS)

Let me give some introduction on DDNS before giving some ideas on DDNS data model.

Many small offices would not want to pay for static public IP addresses and yet host servers for public access. For public access of servers, it is necessary that reachability information is constant. DDNS functionality enables this. DDNS providers facilitate this by allowing CPE devices to advertise IP address changes to DDNS providers. DDNS providers internally update their DNS servers with this new IP address.

DynDNS is a popular protocol used by many DDNS providers. Though it is not a defined by IETF or any other standard body, this seems to be quite popular. DDNS providers such as www.dyndns.org and 3322.org use this protocol to provide dynamic DNS service. TZO is another protocol used to update the service. DDNS provider www.tzo.com provides DDNS Service using this protocol.

As an end user, following steps are to be followed to get hooked into this service:

• Create account with DDNS provider using their web site. You may be asked to provide your email address, user name and password.
  
• Register your domain names with the DDNS provider by visiting their web site or by using one of their clients.
• Configure your router with DDNS provider information to update IP address automatically.
• Set up your internal servers for public access.
  
• Configure your CPE router to forward the traffic to your servers.

CPE router configuration: CPE routers normally support multiple instances of DDNS - One instance for each WAN link. For example, If there are two WAN links, then CPE devices will have two DDNS client instances. Each client instance can update the IP address for multiple domain names. Each record would need to have following information configured.

• Name of the record : To identify the record.
• WAN interface (link): DDNS client monitors the IP address of this link. Wheneverthe IP address of the link is changed, then it starts the process of updating.
  
• Update time period: This time period indicates the periodic interval to update the IP address, even if the link address is not changed. This configuration parameter is not used by some DDNS protocols such as 'dyndns'.
  
• Domain name 1 : Name of the domain name that was registered.
  
• Domain name2
• Domain name3
• Domain name4
• DDNS protocol to be used: Protocol that is to be used to update IP address. 'dyndns', 'tzo', 'dhrp' etc..
• Provider details
• In case of dyndns, the additional configuration required to contact DDNS provider are:
• DDNS provider IP address or FQDN: Reachability information to reach DDNS provider.
• Relative URL (Script name): DynDNS protocol is HTTP or HTTPS based. This parameter indicates the CGI script to be used to send update information. Unfortunately, this name is not standardized. Different providers are using different script names. Hence, this should be taken as configuration parameter.
• Protocol : HTTP or HTTPS
• Port : Typically, it is 80 or 443.
  
• User name and password: User name and password used to create account with DDNS provider.
• Trusted Certificate in PEM form: When HTTPS used. This certificate is used to authenticate the DDNS provider to avoid MITM attacks.
  
• Note: DDNS client always should send MX=NOCHG and wildcard = NOCHG to ensure that configuration done using DDNS provider website is not erased.
• TZO provider information: As I understand, TZO protocol defines server discovery. I guess this is mainly for load balancing. It involves following stages - Getting IP addresses of clusters and getting IP addresses of update servers and then updating IP address to one of the update servers.
  
• ProviderIP address/host name (Cluster lookup host): Using this IPaddress/host name, the TZO client in the CPE gets the all IP addresses of cluster. TZO client makes a TCP connection for this purpose.
  
• Cluster lookup port: Port used by TCP connection to do cluster lookup. Default : 21340
  
• Update Server lookup Port: Once TZO client gets the cluster IP addresses, it is expected to choose one of them and make another TCP connection to get the list of servers that can be used to update the new dynamic public IP address. This port is used by client to make the connection. Default : 21344
  
• Email address: Mail address used when the TZO account was created.
  
• Key: Key generated when the TZO account was created.

Based on above explanation, the TR-069 data model for DDNS could be:

• internetGatewayDevice.DynamicDNS.{i} : PC - New instances can be created.
  
• Name
  
• Enable
• LinkReference : Fully Qualified name of WanDevice->WanConnectionDevice->WanIPConnection or WANPPPConnection.
• UpdateTimePeriod : In seconds.
• DomainName1
• DomainName2
• DomainName3
• DomainName4
• DdnsProtocol : Takes one of the values of 'dyndns', 'tzo'
• internetGatewayDevice.DynamicDNS.{i}.dyndns
• ProviderFQDN
• ProviderURLScript
• ProviderProtocolSupports: Read Only, String, It takes comma separated protocol strings such as http, https etc..
  
• ProviderProtocol : take 'http' or 'https'
• ProviderPort
• Username
• Password
• ProviderCACertificate : Valid only if 'https'
  
• internetGatewayDevice.DynamicDNS.{i}.tzo
• ProviderClusterLookupFQDN
• ProviderClusterLookupPort
• ProviderUpdateServerLookupPort
• RegisteredEmailAddress
• KeyProvided

Why is IKEv2 better than IKEv1?

IMO, any new deployment should go with IKEv2. It provides several advantages over IKEv1.

• IKEv2 is light on bandwidth and faster
• Less number of messages to establish tunnel.
• IKEv2 provides inbuilt NAT Traversal.
• IKEv1 does not provide this facility. But an internet draft was created to enhance IKEv1 with this functionality. Since this draft is not standardized, there may be interoperability issues.
• IKEv2 has inbuilt tunnel liveness checks.
• If tunnel is broken down on peer, it has facility to detect and re-establish the tunnel.
• IKEv1 does not have this functionality. There is an internet draft available though.
• IKEv2 provides comprehensive authentication capabilities.
• It supports Pre-shared key authentication, certificate authentication. IKEv1 also has them.
  
• More importantly, it provides EAP authentication and hence it is suitable to integrate with existing authentication systems in Enterprises. IKEv1 does not have this capability.
• IKEv2 has companion document to work with changing IP addresses on devices .
• MOBIKE standard is only supported on IKEv2.
• IKEv2 has facility to negotiate multiple sets of selectors.
• Many networks/ranges can be negotiated in one exchange. Hence, number of policy records can be very less when sites have multiple networks.
• In IKEv1, each pair of networks need to be defined in one policy record in SPD.
• IKEv2 has clear method to choose subset of selectors when both sites are not configured with exact selector values.
  
• In case of mismatch, IKEv2 has better mechanisms to converge.

If you are newly deploying IPsec gateways or thinking of upgrading Ipsec based security gateways, consider using IKEv2.

IPsec and DDNS - Where do they meet?

If some one tells you that you require permanent public IP address for connecting offices via IPsec tunnel, then he/she is not up-to-date with the latest offerings.

It is true that original IPsec security gateways do require static public IP address for establishing tunnel. With Dynamic DNS capability built into these gateways, this is no longer the case. As long as there is public IP address (static or dynamic), IPsec tunnel establishment is possible. Both sites participating in the tunnel can have dynamic public IP addresses.

What is Dynamic public IP address?

IP address assigned by ISP is not constant. ISPs can change the IP address that is being assigned from time to time. More often, every time CPE device reconnects (in case of PPP) or require new lease (in case of DHCP), ISPs provide new IP address.

What dynamic DNS?

Dynamic DNS provides fixed domain name, but changing IP address. There are large number of providers (One example: www.dyndns.org) provide services to register for domain name and change the IP address for this domain name through proprietary but well published protocols. CPE device, whenever public IP address changes informs dynamic DNS providers through the protocol. Any peer who needs to communicate with the CPE device will get the latest IP address via DNS protocol. Only limitation is that all peers must communicate with the CPE using domain name.

IPsec and DDNS:

IPsec as an application can make use of domain name to communicate with the peer. IPsec component must have domain name resolution facility to get IP address of peer before connecting to it via IKE. IPsec tunnel establishment can happen even if both the sites have dynamic public IP addresses as long as they have DynDNS capability.

With gateway adoption feature as described in one of previous blog entries, tunnel need not get torn down even if the IP address changes, thus providing seem less connectivity.

Fragmentation before encapusulation (Red side fragmentation) - IPsec

I don't know why it is called 'red side fragmentation'.

What is red side fragmentation?

Fragmentation of IP packets is done before ESP/AH/IPCOMP encapsulation in IPsec such that there is no fragmentation required to transmit the encapsulated packets.

Why is this required?

I believe some of service providers tend to give less priority to packets that are fragmented. When they detect congestion, fragmented packets are given lesser priority and they may get dropped.

IPsec carries many important protocol traffic across sites. Any IPsec packet drops cause degradation of application performance. IPsec gateways need to ensure that this traffic is not dropped. As you are aware, IPsec adds additional encapsulation headers such as ESP/AH/IPCOMP and another IP header in case of tunnel mode. It increases the packet size by few more bytes. If big size packet is received from local hosts and any additions to this packet requires fragmentation. If the fragmentation is done after encapsulation, the resulting packets have fragmentation variables set (MF bit and Offset bit) in IP headers. To avoid this, fragmentation is done on clear packets and IPsec encapsulation, outer IP header insertion is done on each of clear fragments. In this case, the outer IP header does not have fragmentation variables set. By this, service providers don't give lesser priority to these packets upon congestion.

Many security devices supporting IPsec have this feature. As an evaluator of security devices, you should look for this feature.

OMA-DM Vs TR-069 - One difference

I found one difference between OMA-DM effort and TR-069.

DSLForum (TR-069) defines multiple technical reports (TRs) describing data models. It defined TRs for Internet Gateway Devices, VOIP TAs, NAS etc.. Within each TR, there are multiple profiles for each of the functions of devices. As I understand there are multiple working groups working on defining data models for different kinds of devices. Also, there are some working groups working on test specifications. It appears that DSL forum, at this time, concentrating on defining as many data models as possible and very active in that.

In case of OMA-DM, I did not see any effort going on in open mobile alliance group (based on public access I have to their site and I may be wrong) to define configuration parameters for different kinds of applications. I am not sure whether it is intentional to keep this effort out of this group. But this is one difference I find between OMA-DM efforts and TR-069 efforts by respective standard bodies.

TR-69 Vs OMA-DM

TR-069 is standard from DSLForum to remotely manage networking devices. OMA-DM is standard from "Open Mobile Alliance' to manage smart phones remotely. Though the target market segment is different, I don't see any major difference between both of them as far as their functionality is concerned. I believe that both the standards are suitable for both kinds of market segments.

Similarities:

• Remote configuration and monitoring of devices
• TR-069 is meant for managing networking devices.
• OMA-DM is meant for managing Mobile devices.
  
• Firmware upgrade.
• HTTP based access - OMA-DM support other transports too.
• SSL for security.
• Both use XML for exchanging messages.
• Both support configuration parameters in hierarchical fashion (Tree form).
• Both expect devices to make connection to the central configuration server.
• Both support mutual authentication.
• Both have mechanism for central configuration server to notify devices of different events.
  
• OMA-DM uses WAP-Push and SMS.
• TR-069 connects to device embedded HTTP Server.
  

I don't see many differences though. I will post new entry once I find more information.

Both of these standards have become very popular in their market segments and IMO both will be surviving for a long time.

Mutliple security Zones in Enterprise networks - Security Devices

Traditionally, security devices such as firewalls and UTMs are deployed at the Enterprise Edge. At Enterprise edge, one is satisfied with trusted zone (corporate network), untrusted zone (Internet), De-Militarized zone (DMZ) separation provided by security devices.

Increasingly, security devices are being deployed in Enterprise core where multiple department networks are present - Engineering, Marketing, Sales, Finance etc.. These security devices not only provide access control, intrusion prevention, network anti-virus and spam protection from Internet (untrusted network), but also provide isolation among the departments. Enterprises are increasingly providing internet connectivity for visitors too. Isolating corporate department networks from visitor network is very important from security perspective. To provide granular access controls and other security services among departments, three network zones provided by traditional security devices are not good enough. Security devices must support definition of zones and policy configuration among these multiple zones. For example, a firewall ACL rule can be defined to allow a specific traffic such as HTTP between Finance zone and Engineering zone. Security devices supporting multiple zones provide rule definition with 'From' and 'To' zones in additional traditional 5 tuples (source IP, destination IP, Protocol, Source port and destination port).

Some security devices in the market provide rule definition for each network interface. That is, each network interface is considered as a separate zone. Yet times, many Ethernet interfaces are connected to different segments of one department. In those cases, the rule definition needs to be duplicated for each interface. So, I prefer security devices providing concept of zones and associating Ethernet and other network interfaces to zones. Security policies are defined with respect to zones. By separating rule definition from interfaces, addition of new interfaces and deletion of interfaces to/from zones does not effect the rule definitions for that department.

SNAT and DNAT on same connection?

One small office network administrator asked me this question on why both source NAT and destination NAT required on the same TCP/IP connection. My answer: It is not required in many deployments, but some deployment do require this. Read on... Let me give a small brief on source NAT and destination NAT first.

In many deployments 'source NAT' is used when number of public IP addresses given by ISP are less than the number of machines that require internet connectivity. In many small office deployments in Asia and Latin America typically get only one dynamic public IP address. In few cases, upon request, few static public IP address are given for a fee. Source NAT in NAT routers is used with NAPT (Port translation) to provide internet connectivity for many PCs with one or more public IP addresses. Source NAT is used for outbound connections - Connection originated by internal PCs to resource in public network (Internet). In source NAT mode, source IP and port values are changed on client to server packets. Destination IP address and port values are changed on server to client packets so that the packets go to the PCs that initiated the connection.

Note that 'source NAT' does not mean that only Source IP and port values are changed in all packets. The term 'source' or 'destination' in SNAT and DNAT is used to represent the translation points on first packet of connection i.e client to server packets. Note that reverse translation happens on server to client side packets, that is if source IP is changed in client to server packets, then destination IP is changed in server to client packets of the connection. But the term 'source NAT' is used to represent this kind of NAT.

Destination NAT is typically done for inbound connections. When Enterprise have many servers inside (for providing services for users in public network) and if the Enterprise has less number of public IP addresses than the number of servers , then destination NAT is required on routers (NAT routers). Let us say that a small Enterprise have two servers - One Web server and one email sever. If that enterprise have one public IP address, then all HTTP and SMTP/POP3 connections land on this IP address. The NAT router having this public IP address must have DNAT facility to redirect the traffic to internal HTTP Server and Email Servers, by changing the destination IP address and possibly port on the incoming packets (client to server packets).

SNAT and DNAT on the same connection: So far we have discussed that outbound connections from Enterprise use SNAT and inbound connections to Enterprise use DNAT. SNAT and DNAT combination means that both source and destination IP addresses of the packets are changed at the same time. SNAT+DNAT is typically required for inbound connections when the Enterprise has more than one WAN connection being serviced by different NAT routers. These NAT routers are assigned with appropriate public IP addresses or they get IP addresses dynamically from ISP either via DHCP or PPP. If inbound connections undergo network translation by a router, it is imperative that reverse traffic on the connection also go through the same router for reverse address translation. Inbound connections can land on any of the routers (based on the IP address used by clients in public network) and get redirected to internal server. Internal servers are not intelligent enough to route the packets to appropriate router. Typically they use same default route for all outbound packets. In theses cases, all packets go to one of two routers. This router may not be able to service connections which were redirected by other routers. To overcome this, routers need to apply SNAT on the connections. This will ensure that reverse traffic from servers go to right routers.

Asymmetric Routing - Security Devices

It appears that asymmetric routing is very common in Enterprise networks. It was a surprise for me when I first heard about this few years back.

When packets of a connection take different routes in networks, then the network has asymmetric routing problem. Any stateful security device will have problem with this. Stateful security devices expect all packets of connections pass through them - Client to Server and Server to Client packets. If packets belonging to one leg of connections don't pass through, these devices fail to parse the protocol states and report them as 'attacks'. For example, if second packet of TCP connection (TCP Packet with SYN+ACK flag - First packet from Server to Client) is received by security device and not the first packet (TCP packet with SYN flag only - Client to Server packet), then the security device (firewall) treats this as an 'attack' or reconnaissance attempt by attacker. Typically these packets are dropped. Hence, the connections are not established, even though they are genuine.

Many times, this asymmetric problem is observed in Enterprise core networks, but not on Enterprise Edge. It is observed that this problem is not so much in large Enterprises as security administrators work with network administrators to fix the network. In SME markets, security device vendors can't expect them to fix their network problems immediately. Security device vendors are expected to have work around in their devices while administrators fix the problems over time.

Some security device vendors support feature 'Bypass Security processing'. This feature allows users to configure multiple bypass records with each record taking pair of networks. Any traffic having source IP address and destination IP address falling in any of bypass records is forwarded or switched immediately, without any security analysis. Forwarding or switching decision is taken whether the security device is operating in route mode or bridge mode.

As a security administrator, it is better to look for security devices that have bypass flexibility.

Are firewalls susceptible to DDOS?

Answer is : Many of them.

Packet filters are thing of past. Firewalls today are stateful inspection firewalls or proxy firewalls. In both cases, they maintain state information in sessions. Sessions are created for TCP/IP connections. These firewalls maintain ACL - Access control Lists - configured to implement company policies. First packet of any TCP/IP connection passing through firewall device is validated against ACL. If ACL rule allows the connection, then rest of packets of connection are allowed to pass through the firewall device.

Some of the firewall devices in the market have additional functionality such as protection from DoS (Denial Of Service) attacks, complex application traversal functionality via Application Layer Gateways (ALGs) and source/destination Network Address Translation (SNAT and DNAT). Don't think that firewalls stop DDOS attacks effectively. Don't be fooled by literature. Some firewall devices don't even protect themselves from the DDOS attacks.

Since firewalls maintain states, they are susceptible to DDOS attack unless firewall vendor has taken enough precautions to provide functionality beyond 'Access Control'. Don't bet that all firewalls have functionality to defend against DDOS attacks. Before I proceed further recommending the features to look for in firewall to minimize DDOS attack impact, let me give a brief on DDOS attacks.

DDOS Attacks: DDOS attacks by definition are distributed Denial Of Service attacks. The attack is mounted from multiple external locations at the same time on to internal servers/services. It results in flood of packets and thus disturb service availability. Some of DDOS attacks when mounted smartly do not even require enough bandwidth for attackers.

Firewalls can't prevent DDOS attacks completely - Some attacks can be detected and prevented, some can be detected and further action needs to be taken manually. But it is very important that firewall devices themselves should not become victim of these attacks and firewalls are expected to minimize the impact of DDOS attack.

Some DDOS attacks are nontrackable. Source IP is spoofed in these cases. If source IP of the attack packets are spoofed, the response packets from the victim can't be routed to the attacker. Hence these attacks are mostly send multiple packets with one packet per connection to overwhelm the resources at the victim end. In case of TCP based connections, attacker can send large number of SYN packets with spoofed source IP addresses. This is called SYN flood attack. If firewall device does not have defense against this, attacker can overwhelm the TCP listen queue in server machines and also he/she can overwhelm the session table in firewall, thus the complete network behind firewall is unreachable for genuine users as long as SYN flood attack continues. Fortunately, many firewalls have mechanisms to defend from this attack. Firewalls implement SYN-Cookie defense mechanism to allow connection only if originator responds with next packet in TCP (ACK) to the packet firewall sends (TCP packet with SYN and ACK flags). Firewall do this without creating any session from its session table. If your firewall does not have this feature, then you better go for firewall device from some other vendor supporting this defense mechanism.

Next question to ask in selecting the firewall is DDOS defense mechanism when the attacker overwhelms the network with full TCP connections - that is, attacker responding with ACK and keeping the connection for a long time. This attack also can overwhelm the TCP protocol servers such as HTTP, SMTP, IMAP etc.. and also can overwhelm firewall session table. Since TCP connection is established with full 3-way handshake, source IP address is known and attacker tracking is possible via service providers. But, firewall device should log these events and provide log analysis for administrator to take up the case with their service providers. Reporting and analysis is one important aspect of selection of firewall device.

UDP is one tough nut to crack if DDOS attack is mounted on UDP Service. By sending packets with spoofed IP address, attackers can easily overwhelm services and firewalls. Best precaution to take is to stop all inbound UDP Services. But yet times, it is not possible for companies to block these services. Some popular servers use UDP - DNS, IKEv1/v2, SIP, RTP etc. RTP is not an issue for firewalls as it requires some other signaling protocol such as SIP, H.323 and MGCP to go first.

Unlike TCP, there is no connection establishment phase. Hence it is difficult to figure out whether it is genuine UDP packet or coming from attacker. But the UDP flood on one service and an internal machine should not bring down other UDP and TCP services. Firewall devices should protect its session table from using up all resources and also ensure to make other services available. That is, if UDP SIP Service is being flooded, UDP DNS service and other services should not get affected. IMO, firewall should provide mechanism to control maximum number of simultaneous sessions for each internal service/server combination and the rate at which connections are getting established. Firewalls also should provide mechanisms to reserve sessions for some critical services/server combination for critical users.

Unless firewall provide these defense mechanisms, they can't prevent DDOS attacks and many times can't protect itself.

In summary, good firewall device must:

• Prevent from flood attacks such as SYN flood.
• Detect source of attacks in cases where source IP can't be spoofed. Logging and Reporting is very important feature to look for.
• Ensure availability of services even in cases where one of the services is being attacked. Session Table limit and reservation on per service/server combination and flexibility of configuration of same is very important to ensure availability of other critical services.

P2P Control in Enterprises - What to look for in security devices?

P2P application popularity has been soaring. They are mainly meant for sharing files - Audio, Video and date files. Due to sharing of copyrighted files, there has been multiple law suites on P2P software providers and p2P users. Still the popularity continue to raise. Now, audio/video distributors are using p2p mechanism for marketing purposes. Some of Linux OS distributors are using P2P applications for downloading Linux images. So, it appears that P2P application is being adopted for businesses as well.

One of the main advantages of P2P is its low cost of distribution: P2P uses distributed delivery mechanism. Big file is divided into smaller pieces and they get distributed. User P2P application downloading these files will provide upload service there by making distribution network bigger day by day. P2P client downloads multiple pieces from different locations and combine them together to create original file. Original distributor site is less loaded due to inherent distribution capability of P2P applications.

Due to its low cost of delivering content to multiple users, this became play ground for distributing illegal copies and became kind of social networking tool where group of people share and distribute big size files containing audio/video and data content.

Some of popular P2P applications are:

• AppleJuice
• Ares: Ares, KCEasy the applications that use Ares protocol.
  
• Bit Torrent Protocol: This protocol is implemented by many applications such as Azureus, BitTorrent, BitComet, Mu-Torrent , Shareaza and many more.
• DirectConnect
  
• eDonkey Protocol: eMule-Plus, xMule, aMule. Shareaza use this protocol.
• FastTrack protocol: kazaa-lite, Shareaza, Kceasy use this protocol.
• Freenet
• Gnutella: Bearhare, Limeware, Gnuclues, iMesh and may applications use this protocol.
• iMesh
• Monolito
• WinMX
• Winny

Many one-click hosting providers provide content directly on their site for download. They include rapidshare, megaupload, youtube etc..


P2P applications are increasingly being used in Enterprise networks for personnel use. Some times, these P2P machines become super nodes where they become distribution point for some content, some times with the knowledge of user and some times inadvertently. These put strain on Enterprise WAN links. Also, it reduces employee productivity as they get hooked into these tools.

Enterprises are looking for ways to detect P2P applications and control them either by blocking the traffic or by limiting the traffic. Enterprise requirements are summarized as below.

• Enterprises might need to allow some P2P applications as part of their business.
• Enterprise might host P2P distribution servers to distribute their content.
• Enterprises might allow some of their Employees to use some P2P applications for business use.
• Enterprises might need to control bandwidth used by different P2P applications.
• Enterprises might have different requirements of access control and rate control based on time-of-the day or day of the week.

In essence, Enterprises look for solutions which detect different kinds of P2P applications and throttle or block traffic. Enterprises are increasing looking at Network based security devices to provide this capability so that they can control at one central place.

What is the feature set Enterprise need to look for in security devices providing this function? Before this question is answered, it is better to know the inner workings of p2p applications.

Some of attributes of p2p applications from detection perspective:

• Port hopping: P2P applications came long way. Initial version of P2P applications used to use fixed set of ports. It was easy to detect them and block them. P2P application developers improved their applications/protocols to use any port that is opened by local firewall. They even use Port 80 and Port 25 which are standard ports for HTTP and SMTP. Almost all P2p protocols use port hopping. So, detection of these application by port number is no longer sufficient.
• Obfuscations - Using Encoding techniques: Due to port hopping nature of P2P applications, security device vendors started detecting the P2P applications by observing content patterns in all connections. Each P2P application can be recognized by certain pattern. Security device vendors provide these patterns as signature rules. This was very effective and continue to be effective. With popularity of these methods, P2P application developers started using encoding mechanisms to bypass detection by pattern match. Some of the examples are : Winny, Ares Galaxy and Skype.
  
• Obfuscations - Using standard protocols with encryption : Security vendors started devising techniques to detect encoded connections by applying decoding logic before matching the patterns. Engineers did reverse engineering on some of the protocols or by understanding open source code of these applications. To thwart this, some P2P applications such as BitTorrent adopted encryption and making use of standard ports. BitTorrent started using HTTP for file transfer and SSL for encryption.
  
• One Click File hosting providers: Almost all of them provide file share using HTTP protocol. So, detection should happen on HTTP protocol.
  

From above description, you can observe that it is a catching game for both security vendors and p2p application developers.

My observation as of now is that many P2P applications can be detected by content pattern matching. Some applications require decoding before matching.

What is it one need to look for in security devices claiming to be detecting P2P applications:

• Just don't look for literature on application supported by the device. Ask questions. How is it being detected? How well it can add signatures to detect future versions of applications.
• Look for flexibility of application detection signatures.
• Look for application support which require decoding
• Look for HTTP protocol intelligent keyword support in signatures to detect one click hosting providers. Without HTTP application intelligence, there could be many false positives.
  
• Look for system that has ability to do SSL decryption (Proxy based or inline passive scanning).
• Look for detection capability which spans across connections: P2P applications which are encrypted can successfully be detected by doing scanning across connections. Note that many P2P applications have handshake connections and data connections. By combing for a pattern across these connections, many P2P applications can be detected.
• Look for traffic anomaly: Some P2P applications can't be detected by pattern match or can't be decrypted. In those cases, look for anomaly in the traffic with respect to number of connections made, detecting the connection rate, byte rate etc.. Though one can't pin point actual p2P application, it provides enough hints on who might be running p2P applications.
• Always look for capability to block the P2P application traffic and/or rate limit the traffic on per IP address basis and schedule basis thus providing control for Enterprises on who can use which P2P application(s) and at what time of the day.
  

IGMP Proxy

IGMP Proxy is defined in rfc4605.txt.

IGMP proxy is typically used in Edge routers - Either office edge such as gateway routers and provider edge such as DSLAM. One main point to keep in mind is that IGMP proxy is useful only in simple tree topology where tree can be configured manually. For complex trees where manual configuration is not possible, multi cast routing protocols such as PIM should be used. IGMP proxy is very simple in the sense that it acts as IGMP router for downstream interfaces and as a host on upstream interfaces. It listens for IGMP reports coming on downstream interfaces from hosts interested in listing to multicast traffic. It consolidates report information coming from different hosts across different downstream interfaces and send consolidatedreport to upstream routers.

In Office edge routers, the interfaces connected to inside machines are typically downstream interfaces and WAN interfaces connected to ISP routers are upstream interfaces. In case of DSLAM, WAN interfaces towards its customers are downstream interfaces and upstream interface is connected towards Internet.

Multicast stream providers get unique Multicast IP address for each type of stream from IANA. This IP address is advertised. Any machines willing to receive this stream send IGMP membership reports to routers indicating their willingness to receive packets coming on a particular multicast IP address. IGMP protocol is used to send membership reports.

IGMP proxy devices receives multicast stream from upstream interfaces, it knows the downstream interfaces interested in this traffic based on membership reports it received before. It duplicates the traffic and send it to these downstream interfaces. It provides great advantage on cost savings as only one copy of stream is sent on WAN link. Gateway implementing IGMP proxy duplicates on multiple downstream interfaces.

IGMPv3 support source specific multicasting. IGMPv3 hosts can request the stream only when it is generated from a particular source. It provides some kind of security for hosts (note that IP address can be spoofed by rogue multicast stream generator) and more importantly it eases the network routing problems. IGMP proxy should honor v3 memberships with specific source IP address. If proxy receives v2 or v1 membership from local hosts on the same interface, then source specific multicast membership from v3 hosts will not have desired effect.

As discussed before, IGMP proxy acts as IGMP router on downstream interfaces. As an IGMP router, it sends IGMP queries periodically to ensure that hosts are still interested in multicast streams. IGMP routers typically send generic query periodically. Group specific query is sent upon a state change such as host leaving the group.

IGMP Proxy takes responsibility of creating multicast routes based after consolidating membership reports.

With the above background, let me present the IGMP proxy configuration required in gateways.

• Enable/Disable: Whether IGMP proxy operation is to be enabled or disabled. If it is disabled, this router does not even entertain reception of IGMP messages.
• Maximum number of groups : This parameter represents the number of groups allowed by IGMP Proxy. Note that 'groups' have one to one association with multiple IP addresses.
• Robustness: Please rfc3376 for explanation. It is mainly intended for lossy network. This parameter value is default value for 'Startup Query Count' and 'Last Member Query Count'. The queries are sent as many times as 'robustness' count separated by 'Startup Query Interval' and 'Last Member Query internval respectively. Default value is 2 as per rfc3376.
  
• Query interval: The number of seconds between two IGMP general query messages. Default : 125 seconds as per rfc3376.
• Query response interval : Amount of time the querier waits for response to general query. Default is 100 (10 seconds). Each unit corresponds to 100milliseconds.
  
• Startup Query Interval : Number of seconds between general queries during startup.
• Startup Query Count: Number of queries sent out upon startup.
• Last Member Query Interval: Amount of time router can wait before sending group specific query or group-source specific query in response to leave group messages. Default is 10 (1 second). Unit is equivalent to 100 milliseconds.
  
• Last Member Query Count: Number of queries sent upon receiving leave group message.
• Host Unsolicited Report Interval: This variable used by host portion of IGMP proxy. This value is represented in seconds and is used by host to send reports. Host is expected to send 'robustness variable' number of reports within this time to the routers to cover the possibility of report misses by routers.
• Downstream interfaces: List of downstream interfaces. Interfaces are typically of type: wireless LAN, USB Ethernet, Ethernet, VLAN and PPP etc..
• UpStream interfaces: List of upstream interfaces.
• Log : YES or NO. IT departments always would like to know the network view. IGMP membership information provides valuable information about usage patterns etc.. To provide historical information to know the join and leave intervals of machines for different groups, it is required that log entries are generated. This variable controls whether log is to be generated or keep quiet. Log entry should contain
• Machine IP address
• Group IP address (Multicast IP address)
• Time at which it joined or time at which it left.
• Interface used for join or leave.

Run time information: Multicast member ship view is very important for administrators to know what is happening at any given time. One would like to know things like - Machines and their membership information and interface information on which the machines are present etc.. To be precise:

• For each group in IGMP
• Group Address (Multicast address)
• For each downstream interface
• Interface name
• Time at which this group was added.
• Source IP addresses included.
• Source IP addresses excluded.
• Machines that are interested in this group.
  

• Statistics :

• Number Of General Queries Received,
• Number Group Specific Queries Received,
• Number Of Group & Source Specific Queries Received,
• Number Of Queries Transmitted
• Number Of V1 Reports Received,
• Number Of V2 Reports Received,
• Number Of V3 Reports Received,
• Number Of Leave messages Received,
• Number Of Reports Transmitted,

With above in mind, TR-069 model can be represented as:

• internetGatewayDevice.IGMPProxy P
• Enable : RW, Integer.
• MaxNumberOfGroupsAllowed: R, Integer
• LogEnable: RW, Integer.
  
• RobustnessValue: RW, Integer
• QueryInterval: RW, Integer
• QueryReponseInterval: RW, Integer
• StartupQueryInterval: RW, Integer
• StartupQueryCount: RW, Integer
• LastMemberQueryInterval: RW, Integer
• LastMemberQueyrCount: RW, Integer
• LastMemberQueryCount: RW, Integer
• HostUnsolicitedReportInterval: RW, Integer
• internetGatewayDevice.IGMPProxy.Interface.{i} PC
  
• InterfaceReference: RW, String : Once assigned, can't be changed. This full qualified name of interface instance of LANDevice, WANIPConnection, WANPPPConnection, VLANInterface.
• InterfaceType: RW, String. "UPSTREAM", "DOWNSTREAM". Once set, it can't be changed.
• internetGatewayDevice.IGMPProxy.GroupInfo.{i} P
  
• GroupAddress: R, String.
  
• internetGatewayDevice.IGMProxy.GroupInfo.{i}.interfaceInfo.{i} P
  
• InterfaceReference: Read Only, String.
• Time : At which group is added. Date & time. Read Only, String type.
• IncludedSourceIPs: R, String. Comma separated IP addresses.
• ExcludedSourceIPs: R, String. Common separated IP addresses.
• internetGatewayDevice.IGMPProxy.statistics P
• internetGatewayDevice.IGMPProxy.statistics.hostside P
  
• NumberOfGeneralQueriesReceived : R, Integer
  
• NumberOfGroupSpecificQueriesReceived : R Integer
  
• NumberOfGroupAndSourceSpecificQueriesReceived : R, Integer
  
• NumberOfReportsTransmitted: R, Integer
  
• internetGatewayDevice.IGMPProxy.statistics.routerside P
• NumberOfQueriesTransmistted : R Integer
  
• NumberOfV1ReportsReceived: R, Integer
  
• NumberOfV2ReportsReceived: R, Integer
  
• NumberOfV3ReportsReceived: R, Integer
  
• NumberOfLeaveMessagesReceived: R Integer

WAN Links - Sharing Load and Failover - TR069 based configuration

CPE devices provide a feature called 'WAN link load balancing and fail over' facility where they have multiple WAN links to reach Internet. These WAN links are either taken from one ISP or from different ISPs by offices/homes. They provide redundancy capability and also can be configured to provide load sharing.

As far as I know, DSL forum did not define profile for this. I tried to give profile and required configuration parameters needed to configure this feature in CPE from ACS using TR-069 standard.

What constitutes this feature:

• Multiple WAN links in CPE.
  
• WAN links grouped together into multiple bundles.
• Each bundle having following properties
• Share the TCP/IP connections load across links in the bundle or just use only one link, user others when current link fails.
  
• In case of TCP/IP connections sharing, whether to bring up the all links always or bring up/down based on number of TCP/IP connections at that time - Define high threshold and low threshold in percentages. When number of TCP/IP connections reach high threshold, bring up new link in the bundle. When the connections reach low threshold, bring down one of the expensive links.
• Each link having following properties
• Method to use to check liveness : Ping, DNS resolution, None.
  
• Domain name, if method chosen is Ping or DNS.
• Liveness check interval in seconds: Liveness check is done using this interval period.
  
• Number of times the livness check should fail before marking the link 'Down'.
• Link status : UP, Down
• Cost of the link : 1 to 10 - 1 being highest cost and 10 being lowest cost.
  
• WAN interface: Interface identifier or logical identifier identifying the link.
  
• Protocol Bindings: Yet time, it is required that some protocol traffic go through some particular link in the bundle. For example, if email server is hosted by one ISP, all email connections should be sent via that link. ISP may not accept emails coming from the site via other ISP links.
• Each protocol exception record takes following parameters
• Destination IP address - Range of IP addresses.
• Protocol - UDP, TCP or UDP & TCP and any other protocol value.
• Port range: Valid in case of TCP and UDP.

Inner workings:

• Route dictates the outbound interface for packets.
• If outbound interface is WAN link, bundle is determined.
• If this is first packet of connection, then least loaded link is chosen in the bundle. If needed new link is brought up. IP address of chosen link is used for SNAT. Consider protocol bindings in choosing the link.
  
• When there are multiple WAN bundles, it is expected that ACS configures routes with source IP address - Source based routing. It enables usage of multiple WAN bundles. Note that there would be multiple default routes - one for each bundle. It is expected that ACS configures source based routes to make use of multiple bundles.

Profile as per above description:

• internetGatewayDevice.WanSharingBundle.{i}
• Enable
• Share or Failover only?: Indicates whether the load is expected to shared or use multiple links for failover only.
• HighThreshold
• LowThreshold
• NumberOfLinksInThisBundle
• internetGatewayDevice.WanSharingBundle.{i}.link.{i}
• Enable
• LinkStatus
  
• LivenessMethod : None, Ping, DNS
• DomainName : If ping or DNS is chosen as liveness method.
• Liveness interval
• FailureCount
• WanInterface : This is Full Qualified WANIPConnection or WANPPPConnection instance under WANDevice.
• CostOfLink
  
• NumberOfProtocolBindings
  
• internetGatewayDevice.WanSharingBundle.{i}.link.{i}.ProtocolBinding.{i}
• Enable
• MinSourceIPAddress
• MaxSourceIPAddress
  
• MinDestIPAddress
• MaxDestIPAddress
• Protocol
• MinPort
• MaxPort

These are my high level thoughts. More thinking should go in to make it more generic. I hope that it provided decent introduction for further work.

SIP vulnerabilities - Different types

There are many vulnerabilities being discovered in SIP implementations - SIP UA, SIP Proxy and even in SIP Border session controllers. Based on review of some of the vulnerability reports they can be categorized to different types.

• Buffer overflow attacks in
  
• SIP request first line fields - method, URI and version.
• SIP response first line fields - version, status code and reason phrase
  
• Duplicate header fields
• SIP header fields
• SDP fields
  
• Missing header fields
• SIP header fields
• SDP fields
  
• Invalid data in the
• SIP header field names
• SIP header field values
• SDP field names
• SDP field values.
  
• Short messages
• SIP request message size
• SIP response message size
  

IPS/IDS devices can do job of detecting attacks exploiting above types of vulnerabilities without false positives only if they have rich set of SIP intelligent syntax in their rule language.

Many IDS/IPS devices do support detection of traffic anomaly with respect to traffic rate, connection rate etc.. They also support detection of protocol anomalies. SIP protocol is text based protocol and SIP standard does not specify the length limits for start line fields, header field names and values. Due to its flexibility, protocol (RFC) violation detection is limited. To beef up the anomaly detection, I believe that IPS/IDS devices should support detection of protocol content anomalies for zero day detection (if not protection). At the minimum, content anomaly detection should include first line fields. SIP header fields and SDP fields. Since there is no standard on limits, IDS/IPS devices should provide flexibility for administrator to change the anomaly rules. IT departments can tune these rules based on the deployment requirements.

This anomaly detection is kind of first alert system. Upon alert, security professionals can find out the intentions of the attackers and take further actions such as beefing up the security by creating newer, stringent rules, patching the victim systems and updating their honeypot configuration for tracking the attackers etc..

Any anomaly detection should have some baseline. I am not an expert on SIP devices and SIP deployments. Based on the type of vulnerabilities, I feel baseline and associated rules to detect anomalies can be created (by security professionals or signature developers) by some guidelines such as:

• For each field in start line, SIP header and SDP fields
• Determine all possible values for fields.
  
• Determine typical lengths of field names.
  
• Determine typical lengths of field values.
• Determine typical set of characters observed normally
  
• Determine typical header fields that normally exist in SIP requests and responses.
• Determine header fields which are normally unique.

Create rules to detect any anomalies based on above baseline. Also, it is necessary to detect SQL injections and XSS injections by validating the field names and values.

SIP Security - IPS/IDS role

VOIP uses TCP/IP based communication like data services. Due to this, data threats are applicable for VOIP based systems - VOIP phones, VOIP infrastructure appliances etc.. Most of these threats and possible solutions are well discussed in many forums. Here I tried to give gist of different types of threats that are possible on VOIP systems.

• Service disruption (Denial Of Service): Service disruption can happen in many ways.
• Attacker exploiting SIP vulnerabilities and bringing down the service.
• Attacker exploiting vulnerabilities in software other than SIP and bringing down the service and device (phone or appliance or server).
  
• Attacker sending large number of SIP requests towards phone or SIP appliance and making it unusable.
• Attacker sending large number of packets to bring down the voice quality.

• Taking control of SIP device:
  
• Attacker exploiting vulnerabilities in OS and application software and injecting his/her own code to get the shell access.
• Attacker exploiting poorly configured devices.
• Taking advantage of default user name and passwords on devices: Many administrators and users forget to change the factory default credentials. Attackers take advantage of this to get control of the device.
• Taking advantage of week passwords using brute force attacks.
• Taking advantage of devices that are on public network with remote access enabled.
• Service theft: Attackers once they break into SIP phone use this to make many outbound phone calls.
  
• Eaves dropping: Hackers can eaves drop on media streams and steal sensitive information. This is possible by
• Attackers breaking into the system as explained above in 'Taking Control of SIP device' and snooping on the media streams.
  
• Attackers spoofing MAC addresses (ARP poisoning) and becoming Man-in-the-middle to snoop on media streams and any other content.
• SPIT (SPam over Internet Telephony): Similar to Email spam. Unsolicited marketing calls, commercial calls fall in this category. Unlike traditional telephony, cost of making calls using VOIP is way less. Spammer only require high bandwidth data connection which is very cheap.
  
• VOIP Phishing (Vishing): Email type of phishing fraud can be extended to VOIP by frauds. They can leave a message indicating it is very important to callback and callback number as if legitimate entity (such as bank) is called by spoofing 'From' address (Caller ID). Innocent user might call this number and provide identity information to illegitimate parties (frauds).
  

Protecting from these attacks:

No single solution can solve all of above problems. I believe Intrusion Prevention System (IPS) has a role in preventing some of above attacks on VOIP phone and other infrastructure. IPS device can be kept in the line of SIP/Voice traffic to recognize attacks and prevent them in going across. I try to describe IPS role for each of above threat types.

• Service Disruption -> SIP vulnerabilities and Vulnerabilities of other software running on the devices: IPS devices are actually designed to detect exploits targeting known vulnerabilities. IPS devices have facilities to keep up to date with exploits and vulnerabilities using auto signature download mechanisms. IPS devices also provide facilities for administrators to create their own signatures, if need be. One should look for following capabilities while selecting IPS device to protect SIP infrastructure.
• SIP protocol intelligence: Look for IPS device having SIP protocol intelligence. Without this, there would be too many false positives. Without this, it may not be possible in some cases to develop signature to cover vulnerabilities.
• HTTP Protocol intelligence: Almost all SIP infrastructure devices provide configuration via HTTP. Any vulnerabilities in HTTP Server brings down the device as well as may allow 'root' access to the device. Hence, one should look for IPS devices that have HTTP protocol intelligence.
• Other protocol intelligence: Make a list of services running in your VOIP infrastructure and look for IPS devices having these protocol intelligence.
• Service Disruption -> flood attacks: IPS devices are ideal for detecting and preventing from flood attacks. IPS devices typically have functionality to detect traffic anomaly. IPS devices doing anomaly checks with application intelligence detect flood attacks without any false positives. Look for IPS devices that support detection of traffic anomaly on specific SIP method or on content of SIP header lines in request or response. IPS devices can detect DDOS attacks that occupy bandwidth, but may not be able to prevent them on real time basis. Due to its detection, it provides information for administrators to take out-of band action.
• Taking Control of SIP Device -> Vulnerabilities: As stated above, IPS devices are ideal for detecting traffic that exploit vulnerabilities.
• Taking Control of SIP Device -> Configuration Errors: IPS devices may not be able to detect this effectively. Using IPS rule editor functionality, administrators can create signatures to look for specific strings in the traffic.
  
• Taking Control of SIP device -> Brute force attacks : IPS devices can detect this if protocol based error is returned by SIP devices upon bad authentication credentials. IPS traffic anomaly based signatures can detect this.
• Service Theft: IPS devices may not be able to prevent service theft completely. But IPS device logs can be used to detect any service theft. IPS devices typically log each transaction. Look for IPS device that support SIP based log analysis (inspection) facility. In my view, at the minimum, IPS device should have following functionality:
• Log inspection and report generation based on multiple filtering criteria such as SIP URI, date & time range, IP addresses etc.. Report output should at the minimum contain information about each local SIP phone (SIP URI). It should give number of calls received, calls originated, average duration of call, time of call etc in addition to detailed entries with each entry indicating time of call, Called party ID, duration of call and other SIP related information to identify the pattern.
• Eaves-Dropping: IPS devices can detect whether voice traffic is sent in clear using signatures.
  
• SPIT: IPS devices having SIP application intelligence can detect SPIT using SIP header line content. For example, IPS devices can detect spammers based on 'From' addresses. This kind of detection is not sufficient when spammer keep changing the 'From' addresses i.e spoofing 'From' addresses. IPS devices can't do turing where callers are provided with random challenge to play back. This turing facility helps in rejecting automated spamming systems (no human). SIP proxy firewalls are better suited for this functionality.
  
• Vishing: Vishing problem can be solved only by educating end users. IPS devices can't detect and prevent from users making calls to illegitimate party. IPS devices may help some extent if thare are known 'black' lists. I am not sure even SIP proxy firewalls can solve this problem completely.

IPS device play very important role in detecting some of critical VOIP threats and preventing them. I strongly advice Enterprises deploying VOIP infrastructure to look for IPS devices with SIP intelligence.

Encapsulation-less Route based IPsec VPN

Some one who read my blog asked me a question on mechanism to identify right Security Policy entry, now that there could be multiple policy entries with the same selectors.

In a deployment where there are multiple branch offices, head office security gateway has as many Encapsulation-Less Routerbased VPN (ELR VPN) interfaces as number of branch offices. It is quite possible that each branch office has different security requirements, hence there would be multiple SPD policy entries in head office router. When a branch office router initiates the IKE exchange, head office securty router should identify the right SPD (Security Policy Database) policy entry to negotiate security parameters for data Security associations. In typical policy based VPN and route based VPN, the SPD policy record selection is done based on selector values being negoatiated. But in Encapsulation-less Route based VPN (ELR VPN), selectors are always 0.0.0.0. Hence, this can't be used to select the SPD policy record.

ELR VPN implementation must use some other paramters to select the SPD policy entry. At the same time, implementations should not be creating proprietary extensions to IKE. So, we decided to go with 'remote ID'(ID of the initiated party) as index parameter to select right SPD policy record from SPD policy database.

In above example, each ELR VPN is associated with branch office identities. When IKE exchange is initiated by branch office router, it sends its identitity. Using this identity, head office router selects policy record that corresponds to branch office.

Hope this helps.

TR-098 LANDevice - Clarifications and suggestions

TR-098 LANDevice term is misnomer. It is actually a 802.1D bridge combining multiple Ethernet ports, USB LAN ports and WLAN Ports. Moreover it is very confusing to the reader of TR-098 ammendment1 specifications which defines sepearate 'Bridging' profile.

After getting some clarifications from some of TR-069 experts, now I have some understanding of differences between LANDevices of Basic profile and 'Bridging' profile.

LANDevices: LANDevices is a bridge device having not only multiple ports, but also can be assigned with IP address(es), configured to have DHCP Server instance. The bridge interface created for each of LANDevices instance becomes Layer 3 interface (IP Interface). Hosts connected to ports of this bridge device get IP addresses from same IP address range configured as part of DHCP Server settings.

Bridge Profile bridges (Layer2 bridging): Conceptually this is similar to LANDevices in that it has multiple ports, but it can't be configured with DHCP Server settings and can't be assigned with IP addresses. In essence it is only meant for pure bridging of the packets. It is mainly useful to connect internal devices directly to Service provider networks such as IPTV STB etc..

I believe that bridging profile was made complicated. It should have had a Ports.{} tables within the briding profile rather than having 'Filter.{}' table and 'Marking.{}' table. LANDevice definition did not even have provision to add new interfaces to it. In my opinion, interfaces should be defined in different profile and add these interfaces to LANDevice bridges or Layer2bridging.

Suggested new profiles and changes to existing profiles:

Interface table: This table represents the physical or logical interfaces of the device. These are fixed interfaces in the device such as physical interfaces - Ethernet, USB etc.

• InternetGatewayDevice.EthernetInterfaces.{i} - This is renamed from 'EthernetLANProfile'. I Removed LANDevices tree node and I kept EthernetInterfaces directly under InternetGatewayDevice.
  

• New paramters: These parameters are in addition to the parameters that were already present.
  


• Name (Read only): Indicates the name of the interface on the device. Indicates 'eth0', 'eth1', etc..

USB LAN Profile also need to have similar changes as above.

VLAN interface: I suggest to have this new profile.

• InternetGatewayDevice.VLANInterface.{i}: ACS can add new entries to it. This configuration is used to create new VLAN interfaces from Ethernet interfaces based on VLAN ID.
• Parameters under this tree:
• Name of VLAN interface (RW variable, string type, maximum size of string 32 bytes): Device creates interface with this name.
  
• Enable (RW Variable, integer type): TRUE (value 1) is to enable the record and FALSE(0) to disable the record. Device should discard packets on disabled VLAN interface.
  
• ParentInterface Reference (RW Variable, String type): This is fully qualified name in EthernetInterfaces or USBInterfacess table. Example: InternetGatewayDevice.EthernetInterfaces{i}. Device creates VLAN interface on this Ethernet interface.
• VLAN ID (RW Variable, Integer type): VLAN ID. Device creates VLAN interface with this identifier.
  
• UntagUponReceive (RW Variable, Integer type): If true, Packet is delivered to stack from VLAN interface by removing VLAN header from the packet. If false, VLAN header is delivered to the sdtack. Default value is TRUE.
• TagWhileTransmit (RW Variable, Integer type): If true, packet delivered to VLAN interface for transmission will include VLAN header. If false, VLAN header is not included in Ethernet packet. Default value is TRUE.
• PriorityMarkWhileTransmit(RW Variable, Integer type): Indicates the priority value to be kept on transmitted packets. This field value is considered by device only if 'TagWhileTransmit' is set to TRUE.
  
• InternetGatewayDevice.VLANInterface.{i}.stats. : This block represents the statistics that are to be gathered by device. 'Sent' variables indicate the number of bytes or packets sent to the VLAN interface for transmission and 'Received' variables indicate the number of bytes or packets received by VLAN interface from parent Ethernet interface
  
• BytesSent (Read Only variable, integer type)
• BytesReceived(Read Only variable, integer type)
• PacketsSent (Read Only variable, integer type)
• PacketsReceived (Read Only variable, integer type).
  

• LANDevices.{i} changes:
• I believe that LANDevices also can be created dynamically. First change is to make it as 'PC' as requirement. Second change is to have 'Ports.{i}' to add bridge ports to the LANDevice.
  
• InternetGatewayDevice.LANDevice.{i}.Ports.{i} : This table and entries can be added, hence requirement is 'PC'.
  
• This block contains following parameters
  
• Interface (RW Variable, String type}. This is fully qualified name from EthernetInterfaces, USBinterfaces, WLANInterfaces and VLANInterfaces.
• L2Bridging changes: It needs to have only following parameters
• Number of Bridges.
• InternetGatewayDevice.Layer2Bridging.Bridge.{i} : ACS can create new instances, hence the requirement is 'PC'. Each table entry represents one bridge. Typically, this is used to bridge LAN and WAN interfaces.
• Name (RW, String type, 32 bytes long): Name of the bridge entry.
• Number of Ports (Read Only, Integer type): Number of ports in the bridge.
• Enable (RW, integer type). Takes 1 or 0 values. 1 indicates the bridge is enabled and 0 indicates that bridge to be disabled.
  
• Status (Read Only, string type) : Status of the bridge.
• InternetGatewaydevice.Layer2Bridging.Bridge.{i}.Port.{i}: This table represented bridge ports.
• Interface : Interface name of the port.
• EtherTypeFilterList, EtherTypeFilterExclude, SourceMACAddressFilterList, SourceMACAddressFilterExclude, DestiMACAddressFilterList, DestMACAddressFilterExclude: Same as TR-098 definition.
  

Route based VPNs - Explained

IPsec standard predominantly talks about policy based VPN. Policy based VPN contains multiple policy records, with each policy record having source, destination networks/hosts, service port and security paramters such as encryption, authentication algorithms etc.. These records are arranged in ordered list. Packets are matched against the policy table. If there is a policy record match, appropriate secuirty is enforced on the packets such as encryption and adding additional headers to reach the remote gateway. Remote gateway decrypts the packets and sends clear packets to intended host.

Thought policy based VPN gives granular control for administrators, it has its own disadvantages. If pair of security gateways have multiple networks and services for which data security need to be applied, then policy record(s) must be configured with these networks on the gateways. Every time new network is added in a site, policy records should be updated. Configuration update should be done not only on local gateway, but also in remote gateways. Source IP selector of policy record gets modified with new network on local gateway and Destination IP selector needs to get modified with new network on remote gateway. Admins not only need to configure routes to reach new networks in remote gateways, but also add or modify IPsec policy records. Since networks are to be added to the policy records explicitly, dynamic routing protocols also can't be used across sites.

Route based VPN solves above problems. In route based VPN, a point-to-point L3 interface is created and all traffic sent to this interface are tunneled to the remote gateway. As many interfaces are created as number of remote gateways. For a given pair of gateways, only one tunnel is created. Once this is done, administrator only needs to add routes to remote networks via tunnel interfaces. If dynamic routing protocols are used, admin need not even create routes explicitly.

Multiple types of route based VPNs are implemneted by appliance vendors. They are:

IP-in-IP route based VPN: Interfaces are created with IP-in-IP. IP packets are encapsulated with new IP header. Outer IP header IP addresses are gateway IP addresses. One IPsec policy record is created with these two gateway IP addresses as selectors. Any packets sent to this interface is encapsulated with outer IP header and then IPsec processing with ESP/AH encapsulation is done. When the encrypted packets are received, packets are decrypted, outer IP header is removed and then internal packet is routed to intended host.

GRE Route based VPN: It is similar to IP-in-IP route based VPN, except that it gets encapsulated with GRE+IP header. IPsec policy is created with GRE protocol and gateway IP addresses.

Encapsulation-less route based VPN: In this mode, there is no additional encapsulation such as IP-in-IP or GRE. Only IPsec ESP tunnel is used to encapsulate the packets with gateway IP addresses. In this case, Ipsec policy record is created with Source IP and destination IP selectors as 0.0.0.0 (ALL). So, selector negotiation happens with 0.0.0.0 IP addresses.

Since L3 interface is created, any dynamic routing protocols such as RIP, OSPF and BGP work on these interfaces and don't require any changes to the routing protocol implementations.

Session based UTM clustering - Challenges & Solutions

UTM Clustering where multiple UTM devices work together to increase the performance of certain UTM functions. Anti Virus functionality of UTM is computationally intensive and this functionality benefits greatly with clustering. Since many security functions are stateful in nature, UTM clustering technology distribute the load with sessions. That is, packet belonging to one session is processed by one of the devices in the cluster. That is why, I call this as 'Session based UTM clustering' or simply 'UTM Clustering'.

In recent past, UTM clustering lost its luster due to multi core processors such as Intel Quad processors. But, still I see that clustering is continue to be used, but I doubt 'Session based UTM clustering' is going to survive in long run. Having said that, I feel load sharing based on virtual instances (Virtual Instance based UTM Clustering) is going to survive in Service provider market. With this background, let me get back to the topic i.e challenges and solutions in Session based UTM clustering.

Technology description

At very high level, one of the devices becomes master and other devices are participants. Master device receives traffic from all ports. On first packet of any session, It decides whether the session to be handled by itself or can be load balanced. In case of load balancing, it decides the device based on load balancing algorithm such as hash on source IP/destination IP or least loaded etc.. Further packets of the session are given to appropriate device. I am calling this functionality as 'Cluster plane'. Latency of the packet increases if the packets are handled by participants - Packet comes to master device first and handed over to participant device.

I believe clustering solutions should not call for multiple set of IP addresses - with each set assigned to a device. All devices in the cluster should share same IP addresses.


Challenges & Solutions

Cluster plane should not require major modifications to existing UTM functions. It is understood that some changes are required to take advantage of clustering. As long as changes are limited, then there is more success of adaptation of clustering by vendors.

Some security functions don't work when sessions are load balanced blindly based on load balancing algorithms. Special care should be taken to handle these scenarios. I tried to describe these scenario to some extent to give an idea of the challenges. I try to give possible solution to these problems. In some cases I try to describe the solutions which are balance between complexity of implementation versus limitations.

Inter dependency among sessions: Whenever there is dependency among sessions, all the sessions must be handed over to the same device. Some of the scenarios are:

• Firewall ALG Control and Data connections : Each application context has multiple 5 tuple sessions. These are called complex protocols/applications. These typically require special module in firewall called ALGs which create pin holes and do NAT translation of IP addresses in the payload. Firewalls maintain some state information across these sessions and they are dependent. In these cases, it is required that clustering ensures that these dependent sessions are assigned to same device.
• NAPT functionality: Outbound sessions are typically NATted with one or few IP addresses. New source port is assigned to ensure that 5 tuples are unique across the sessions after NAT operation. When sessions are load balanced across devices, there is a possibility that two devices might assign same port. If it happens that all other 4 tuples are same across these connections, then you have two sessions with same 5 tuples and these connections will not work. Clustering solution must divide the ports across devices. My recommendation: One time port division across devices will work just fine. Division can happen with maximum devices in cluster in mind, even though there are less number of devices at that time.
  
• Bandwidth rate control/ Session Rate Control / Session Limits etc.. : Some UTM functions detect application (Example: P2P/IM/DDLs etc..) traffic and control the traffic. Measuring and controlling the traffic is done in terms of bytes/sec, connections/sec and simultaneous connections based on rules with each rule having set of source IP addresses, destination IP addresses and Services. Traffic rate detection happens across the sessions. This is one big challenge in clustering environments. Sharing the dynamic state information across the devices is not an elegant solution, if there is no hardware based shared memory. For one, it is complex and second there could be lot of errors in the calculations. Multiple packets can come in before the state synchronization happens. And also, if the frequency of synchronization is very high, then this itself effects the bandwidth and performance. There are three solutions possible.
• A. Let each device detect and control the traffic individually. It is up to the administrator to configure the values appropriately. (or)
  
• B. Ensure that all sessions belonging to these rules are processed by one device. (or)
• C. Ensure that all sessions belong to each rule are processed by one device. That is, rules are shared among devices.

• Option C is elegant, but complex and in some scenarios may not work. Complexity arises from different functions and need for conflict resolution. That is, function1 might be having set of rules and function 2 might be having another set of rules with intersecting selector space. If function1 rules are divided across devices, then function2 rules should be divided such a way that rules having intersecting selector space are not assigned to different devices. Some times, there can be deadlocks and this requires conflict resolution. Conflict resolution would prefer one function over another function. So, the function which got lesser priority may not work as expected. This complexity gets compounded when more functions have these kinds of rules. Also complexity goes up with dynamic change of rules. This dynamic nature of rules might require existing rule to be assigned to new device and that results to moving sessions to new device with state maintenance. This becomes really ugly. Due to these complexities, my observation is that many UTM cluster implementations go for either Option A or Option B. Balance between Option A and Option B is typically done based on whether load sharing is important or granular control is important.
  
• My recommendation: Option A. If some function is very important, then advice administrator to disable clustering or internally disable cluster automatically when that function is enabled.
  

• Policy based IPsec VPN, IP-in-IP based VPN and Encapsulation-less Tunnel VPN: In IPsec VPN, security associations are created for each tunnel. UTM devices receives clear traffic from protected network. This traffic gets encrypted and sent out. When UTM device receives encrypted traffic from remote gateway, it decrypts and sends the clear traffic to protected network. Security associations maintain quite a bit of state information and due to this, it is required the clear and encrypted traffic is sent to the device having security association. Clear traffic from protected network correspond to multiple sessions. For a given tunnel, IKE session traffic, clear traffic and encrypted traffic should go to one device.
  
• In case of policy based VPN, clear traffic traffic selectors are known. IKE session traffic is known from the gateway IP addresses and encrypted traffic selectors are known from IP protocol and gateway IP addresses. In some cases, there could be multiple data tunnels between two gateways. In these cases, all data tunnels correspond to those should be in one device.
  
• In case of route based VPNs, clear traffic information is not present in IPsec policy rules. Here, IPsec tunnel is chosen based on routing information. Clustering plane should have access to routing table to make determination of device for the sessions.
• Most challenging part is with respect to handling of remote access VPN. Remote access VPN creates data tunnels dynamically and due to that tunnel selector information is known only when remote end point authenticates using IKE. If IKE is already load balanced, clustering solution must ensure that the traffic also is passed to the same device. It requires state communication between devices and clustering plane running in master device. Remote Access VPN is also used to assign IP addresses. If two remote IKE sessions are given to two different devices, there is a possibility of assigning same IP address to remote end points. Either IKE function should have facility to divide the IP addresses among themselves or clustering plane should ensure to redirect all remote access VPN IKE sessions to one device.
  
• My recommendation: IPSec throughput can be improved with Clustering. As a pure IPsec device, I recommend cluster plane taking advantage of clusters. As far as UTM devices are concerned, first and second generation of UTM clusters would go with processing of entire Ipsec VPN in master device. Cluster plane should redirect IPsec traffic before it does load balancing decisions.
  

• Routing Protocol such as OSPF and RIPv1/v2, IGMP Proxy : It is required that routing protocol information from all neighboring routers handled by only one device for route table consolidation. My recommendation: Clustering plane must redirect all routing protocol traffic to master device.

• DHCP Server : DHCP Server assign IP addresses to DHCP Clients. It should ensure that a given IP address is not assigned to multiple DHCP Clients. If DHCP server is run in multiple devices and DHCP Sessions are load balanced, there is a big chance that two different DHCP Servers might assign same IP address to two different machines. Synchronizing the lease information periodically and ensuring that integrity is maintained is too complex. To reduce this complexity, only one copy of DHCP Server should be active at any time and cluster plane should ensure that all DHCP packets are given to the active DHCP Server. My recommendation: Have changes such a way that DHCP Server in master is active and Cluster plan should redirect all DHCP packets to master device. In any case, DHCP Server is least loaded and balancing the DHCP traffic does not provide any tangible benefit.

• Dynamic IP addressing (DHCP Client and PPPoE) & Dynamic DNS: I believe that, only Medium to big enterprises use clustering solution. It is my assumption that these deployments will have static public IP addresses. Clustering solution should not complicate themselves by supporting this function.

• Route updater: Since it is required that only one routing protocol instance should be active in a cluster, clustering function should ensure to update dynamic routes to all devices.
  

Identical configuration among all devices:

Since sessions are load balanced, configuration should be same across all devices. If there is external management system, it becomes simple. With embedded managements, there would be some instances where the configuration is different among devices, particularly, in the time between configuration change is done and configuration is synchronized. My recommendation is to provide external management system. When embedded management is used, limitation must be made known to end users.

Statistics:

Statistics are updated by each device individually. Again, external management systems can do good job of consolidating this information before presenting to the user. It is my observation that embedded managements still depend on administrators to go to each device GUI to observe the statistics individually.

Stateful Layer 2/3 interfaces:

Ethernet interfaces are typically not stateful. So, even devices output the packets with same link header, there would be no issues. But in PPP and other stateful interfaces, packets are expected to be outputted by one device. In these cases, clustering and association function must ensure to send packets through one device. I recommend that master device is used for this purpose.

Interface level traffic shaping:

Many UTM devices support traffic shaping. Traffic shaping is done typically to prioritize one kind of traffic over another and also to provide guaranteed bandwidth for certain traffic. Typically, these policies are set on per interface basis. Hence, this is called 'Interface level traffic shaping'. When traffic shaping is enabled, clustering should ensure that all packets are transferred to one device, even if packets are destined to go via Ethernet interface. My recommendation is to use master device for this purpose.

Since master device is used for many purposes, this can become bottleneck. To ensure that this does not become bottleneck, I recommend to assign less work as part of load balancing decisions. Due to this, I suggest not to use 'hash based' load balancing algorithm.

With all these limitations, what is it good for?

It is a good question. With all these limitations and many raiders, I feel that it is good for applications such as Anti Virus. As I understand, performance AV with 4K sized emails is around 100 messages/sec in a typical Pentium-4 based systems. With more devices, this performance can go up linearly with number of devices in the cluster.

Mobiles - Secure Remote Access & firewalls in middle

It is well known that IPsec with IKEv2 is typically used to tunnel remote user traffic to Enterprise networks with IPsec client running in laptops and IPsec Gateway installed in Enterprises.

Mobiles are being equipped with IPsec client to access company network resources remotely. Wifi enabled mobiles can be used to access company resources from homes, using visitor networks of other companies, from airports, from coffee shopts etc..

IPsec uses UDP 500, UDP 4500 for key exchange. Data packets are sent using UDP 4500 or IP protocols ESP, AH, IPCOMP. These ports and protocols must be opened in firewalls that are between mobiles and Enterprise IPsec gateways. Without these ports open, traditional IPsec communication does not work.

It appears that some administrators are willing to open UDP 500 and 4500 ports permanantely, but unwilling to open ESP, AH and IPCOMP protocols. Due to this, I have a feeling that eventually all IPsec communication from mobiles would happen on UDP 4500, even if there is no NAT device in between.

In some cases, administrators are unwilling to open any outbound UDP port other than DNS port. If mobiles are behind these firewalls, using SSL (TCP 443) would be a good choice. Since SSL is dependent on TCP, this type of communication is not ideal for real time traffic such as voice and video.

IMO, Mobiles in future will have both IPsec and SSL VPN tunnel support. I propose Firewall traversal discovery mechanism that can be used to select either IPsec or SSL VPN tunnel. Firewall discovery involves both client and server - Client residing in mobiles and Server residing in Enteprise gateway. Client sends UDP 500 or UDP 4500 'echo request' message to find out reachability with Enteprise gateway. Server is expected to send 'echo reply' message on the UDP session upon receiving 'echo' message. If client receives 'echo response' message, it can use Ipsec tunnels. Otherwise, Mobiles need to fallback to SSL VPN tunnel. Firewall discovery echo messages must use its own 'payload' types to avoid conflicts with existing payload types in IKEv2.

Summary:

• Secure Remote Access from Mobiles to Enterprise networks will happen on either IPsec tunnel or SSL tunnel.
• Firewall traversal discovery mechanism would be used to select IPsec tunnel or SSL tunnel.
• IPsec tunnel is preferred over SSL tunnel.
• IPsec tunnels would use UDP encapsulation even if NAT devices are not detected.

TR-069 and transactions

TR-069 defines methods 'SetParameterValues' and 'GetParamterValues' to configure devices and read confguration from devices. TR-069 ACS (Auto Configuration Server) sends these methods to TR-069 device agents. Configuration of device involves TR-069 device agent establishing session, ACS sending configuration values in one or more SetParamterValues methods and closing the session. As indicated in previous blog, DSL forum also defines data profiles containing configuration parameters. These configuration parameters are logically combined into multiple functional blocks. Blocks are of two types. Normal blocks contain parameters and Table blocks contain multiple records with each record having set of parameters.

All items listed TR-098 specifications with 'P' are either normal blocks or table blocks. All items listed with 'R' or 'W' are parameters. Blocks with multiple instances are table blocks. If 'C' is mentioned along with table blocks, then ACS can create new instances (records).

TR-069 specifications is not very clear about transaction boundaries. It indicates that parameters of a block can be set across multiple 'SetParamterValues' methods, but it did not define any transaction semantics . Hence it is better to assume that transaction boundary is limited to one instance of 'SetParamterValues' method.

If the values of parameters for a record come in multiple 'SetParamterValues' methods, it would be difficult for device to know the end and that might lead to interoperability problems if device validates parameters prematurely.

For interoperability, I suggest following guidelines for ACS and Device.

Device:

• Always create a record with default values for all parameters when instances is created with 'AddObject' method. By doing so, even if ACS sets the values of newly created instance across multiple SetParamterValue methods, device validation does not fail.
• Since one SetParameterValues method can contain parameters belonging to multiple instances of newly created records and parameters belonging to different blocks, it is required that device maintains semantics of transaction - Check for validity of all parameters first. If validation of all paramters is fine, then only it should program its internal functions.

ACS:

• Always set values of parameters of newly created instance in one SetParamterValues method.
• Don't send parameters belonging to different instances of table blocks or differenet normal blocks in one 'SetParamterValues' method.
  

Mobiles - Thick Vs Thin clients

I and my friend had an interesting discussion on how long thick clients are going to survive in mobile market. We pretty much concluded that thick clients are going to exist for next few years.

Thick clients are the ones which are special software programs in mobiles. Thin clients don't have any special software running on mobiles. They use browser and scripting that gets executed in the context of browser.

Thick Client advantages:

• Provides Rich user experience
  
• Provides facility to work off-line and synchronize upon connectivity.
• Reduces bandwidth usage: Presentation data need not be sent over the air. Only application specific data (which is smaller in quantity) needed to be exchanged between client applications on mobiles and servers. User Data entry can be validated in the client application before sending it over to the server, thereby reducing back-and-forth communication between client and server upon errors.

Thick Client Disadvantages:

• User may need to install many applications. There may not be enough memory and persistent storage in the mobiles.
  
• User needs to patch these applications to plug vulnerability holes.
  
• In case of Enterprises, it is head ache for IT departments to maintain and support many applications on mobiles.
  

Thin Client Advantages:

• Many of thick client disadvantages become advantages for thin clients.
• Most of heavy work on the server side.
  
• No need of application maintenance on the mobiles. IT departments only need to concentrate on maintaining the servers.

Even with its advantages, thick clients are going to survive until

- Web2.0 techniques such as AJAX, flash are available in Mobile browsers.
- Server content and presentation is improved for mobile screens.
- Reliable connections to servers.
- Coverage and throughput is improved.

Mobility with IPsec

IPsec protocol is being increasingly used by Enterprises to provide secure remote connectivity to internal networks thereby enabling access to internal resources to 'on road' employees and tele-commuters. IPsec gateways assign private IP address and related information (IP address, Internal networks, DNS Server and WINS Sever IP addresses) to the remote clients. Note that this is in addition to the IP address provided by service providers. Applications use private IP address to communicate with Enterprise servers and ISP provided IP address (Outer IP address) is used to tunnel the traffic securely to Enterprise gateway.

Since applications on client use private IP address, any change in the ISP provided IP address does not destroy the IP connections to Enterprise networks. This is in particular helps mobile users. While traveling by car, Mobiles may get different IP addresses across different point of attachments to the cellular network. As long as private IP address does not change, there is no disconnection to voice calls and data sessions. These sessions and calls work even in cases where mobile point of attachment changes from cellular to wi-fi and vice versa.

When outer IP address changes, IPsec client creates new tunnel to the IPsec gateway. Tunnel establishment typically takes hundred of milliseconds to a second. Though this is fine for data sessions, it introduces big jitter and that may not be acceptable for voice and other real time multi-media applications. At Intoto, we have created a proprietary solution (We call it IPsec address adoption) to adopt the IP address change in existing tunnel, there by avoiding new tunnel creation. Both IPsec Gateway and IPsec client adopt to change in IP address and change the tunnel addresses securely, avoiding expensive tunnel creation and thereby providing smooth transition.

Assumptions and Limitations of 'Address adoption' technique:

• It always uses tunnel mode.
• Forces NAT-T even when there is no NAT device in between
• Always does UDP encapsulation.
• Always sends Keep alive messages.
• Since it detects the address change based on incoming packets, it is assumed that there is traffic in both directions.

One of the advantages of 'Address adoption' solution is that it works with both IKEv1 and IKEv2. This solution is simple compared to MOBIKE. Hence, this solution can be called 'SMOBIKE' (Simple MOBIKE).

In summary, IPsec with its inherent capability of tunneling, provides seamless mobility to Enterprise resources. With additional Intoto proprietary address adoption technique, it reduces jitterness in the real time traffic.

Srini

TR-069 replacing CAPWAP - A thought

It appears that there are too many standards to manage devices remotely - We have our old friend SNMP, TR-069 and its associated data models from DSLForum, OMA Device Management from open mobile alliance and CAPWAP to manage access point devices from IETF.

I had one thought - Why not manage access points using TR-069.

Certainly CAPWAP is versatile in wireless world- It can provision and control Split-MAC and Local MAC based access points (Wireless Termination Points). If the requirement is only to provision and control LOCAL MAC based access points, then TR-069 can be used effectively by placing TR-069 Server (Auto Configuration Server) in wireless controller and TR-069 agent (client) in WTPs.

Like CAPWAP, TR-069 protocol also defines operations such as enrollment, mutual authentication, image synchronization and configuration update. It also has mechanism of 'Inform'ing central server on state changes (Parameter Value Changes). CAPWAP has additional advantage though i.e securing the traffic between WTPs and Wireless controller. I believe that this additional secuirty can be achieved by running IPsec tunnel between WTPs and Wireless controllers.

I believe that network security appliance/gateway vendors would be adding TR-069 based central mangement in their hub appliances to manage branch office boxes. I believe that wireless controller functionality is going to be included along with security gateways and appliances. Rather than having one more managment middleware, I believe that vendors would prefer to have one management middleware. CAPWAP is primarily focused on provisioning wireless devices. TR-069 is versatile. Hence, I feel that TR-069 has an advatange.

Srini

Dual Mode Phones - Considerations

Dual Mode phones are the ones with additional 802.11 (wifi) connection.

Enterprises are adopting smart phone usage by employees to increase productivity. It allows employees to access their emails from anywhere, access internal resources via embedded web browser in smart phones or thick clients installed on phones and collaborate with other employees such as conference calls, meetings.

Enterprises need to consider following and ensure that proper systems are in place for mobile connectivity to their networks.

• Device/User authentication: Allow the access to Enterprise resources only upon successful authentication by Mobile user.
  
• Data security: Data in transit must be secured i.e data must be encrypted. Integrity of the data must be ensured.
• Security Vault: I guess mobiles can be lost easily compared to laptops and other big size devices. Any confidential data downloaded by mobile user before it was lost must be in encrypted form so that it can't be viewed by others.
  
• End Point integrity : As on today, there are not many virus and worm attacks on mobiles. As mobiles use standard and common operating systems, these attacks are not far away. They not only compromise mobiles, they may also infect other systems in Enterprise networks and other mobiles. IT departments must ensure that mobiles are clean of viruses and worms before allowing access to internal networks.
  
• Policy Enforcement: Enforce the access controls based on type of user to different resources in internal networks.
• Network based Virus scanning and Intrusion protection: Scanning of traffic to/from mobiles helps in ensuring security of mobiles and internal resources. Enterprise must ensure to have some kind of UTM to analyze the traffic for worms, exploits, DoS and DDOS Attacks and stop the traffic before these attacks damage mobiles and internal network resources.
  
• Mobile Access traffic View: Complete view of traffic from/to mobiles provides Enterprises on traffic patterns. It helps IT department to take further actions such as - Increasing bandwidth, increase productivity by creating new policies etc..
• Extended Storage : I see this requirement in very near future. The storage on mobiles is limited. With always-On connectivity of these smart phones, Enterprises can allow additional storage on their networks. Enterprises can also demand their employees to store all confidential documents in this additional storage, there by mitigating the risk of losing information when mobiles are stolen or lost.

Srini