Silent Knight Teldat System IP traffic patterns and network integration highlights

IP Alarm System patterns and network integration highlights DOCUME cid 29 T VisorALARM IPDACT System IP traffic patterns network highlights August 2008 version version 2.0 1 IP TRAFFIC FLOWS 2 1 IPDACT A cid 29 D VISORALARM BEHI cid 29 D A cid 29 APT ROUTER 3 2 IPDACT A cid 29 D VISORALARM I cid 29 A VP cid 29 4 ARC BA cid 29 DWIDTH DIME cid 29 SIO cid 29 I cid 29 G 6 1 IP traffic flows the IP traffic exchanged between the IPDACT and the VisorALARM is of type UDP This traffic runs a single UDP connection i e a single UDP port the Teldat UDP frame payload is encrypted the frame header is sent without any encryption so network equipments can process and forward them without any restriction at all just as they do with any application traffic based on UDP IP telephony audio streams video streams etc such the UDP header of all frames transmitted from the IPDACT to the VisorALARM Have both the UDP source and destination ports set to the VisorALARM serving port value UDP 80 by default This port is manually configured Have the source IP address set to the IPDACT local IP address This address is manually or obtained from DHCP Have the destination IP address set to either the VisorALARM IP address This IP address is also configured in the IPDACT Are transmitted through the IPDACT default gateway IP address analogy all UDP frames sent from the VisorALARM to the IPDACT Have the UDP source port value set to the VisorALARM serving port UDP port 80 by default Have the destination UDP port set to the IPDACT port that was learnt in the VisorALARM from last IPDACT keep alive frame received Have the source IP address set to the VisorALARM LAN port IP address Have the destination IP address set to the IPDACT address that was learnt in the VisorALARM the last keep alive received Are transmitted through the VisorALARM default gateway IP address 2 1 IPDACT and VisorALARM behind a NAPT router a typical scenario the IPDACT and VisorALARM default gateways are connected to the Internet The frames transmitted to the Internet through these gateways are hence modified according to NAPT Address Port Translation The following diagram illustrates a network diagram for this scenario well as the UDP frame header parameters in each network segment subscriber network the Internet and ARC network 1 NAPT scenario and UDP frame header conversions we can observe in Figure 1 both routers need to do NAPT so the transmitted UDP frame travels along Internet with the system public IP addresses 213.4.21.187 and 80.26.96.183 in the Figure For the system operation the subscriber network firewall should allow UDP traffic sent from the IPDACT IP address 192.168.1.2 in the example to the ARC public IP 80.26.96.183 in the example On transmission the subscriber default gateway sets a conversion entry in its cache memory so the received UDP traffic from the Internet can be back to the IPDACT UDP traffic received from the ARC 80.26.96.183 The subscriber default gateway will forward traffic to the IPDACT 192.168.1.2 according to its cached NAPT entry analogy the ARC network firewall should allow UDP traffic received from the Internet to its serving port port 80 in the example Traffic to this should be triggered to the VisorALARM IP address 172.24.4.1 serving port 80 UDP traffic sent from the VisorALARM to the Internet 3 2 IPDACT and VisorALARM in a VPN Teldat IP alarm system already offers high protection and secured data transmission The payload of UDP traffic exchanged between the IPDACT and the VisorALARM is encrypted in AES 512 but also system offers its own protection mechanism for device substitution and man in the middle attacks As the implementation of a VPN network for this system is not necessary However if a VPN network is available the user can seamlessly integrate his IPDACTC and VisorALARM just as he other third party or generic hosts with no additional precautions VPN implementations consist on establishing a tunnel between the subscriber and the ARC along the Internet Figure 2 depicts a simple scenario where the subscriber and ARC default are also terminating the VPN tunnel at their respective sides 2 VPN scenario and UDP frame header parameters implementation based on IP tunnels provides the user with LAN to LAN Some hosts the subscriber LAN network those ones defined in the Security Policy will have direct IP to hosts and servers in the ARC LAN network For the host IPDACT its remote peer as if it was connected to the same IP network the Figure 2 example the subscriber VPN edge gateway should be capable of route the IP traffic to host 172.24.4.1 through the VPN tunnel The ARC VPN gateway should include a route to the at 192.168.1.2 through the VPN tunnel 4 VPN network edge i e the subscriber gateway or ARC gateway adapts the UDP traffic flow so it be transmitted through the tunnel This adaptation may imply modifications on the UDP frame header specified in the Figure Chart Nevertheless the VPN peer the ARC gateway or subscriber respectively will to undo these modifications to convert the tunnelled IP traffic to LAN IP traffic it can be transmitted all the way to its destination this case the subscriber and ARC network firewalls should also include the security rules that allow the flows specified in Figure 2 Chart 5 ARC BANDWIDTH DIMENSIONING this section we are going to analyze the mIP IPDACT VisorALARM system traffic This analysis should used as a basis in order to size the IP communications in the alarms reception center incoming and outgoing IP traffic in the VisorALARM depends on The number of mIP IPDACT devices being served Each VisorALARM is capable of up to 3000 mIP IPDACTs In High availability ARC setups a Backup is added but the limit of 3000 mIP IPDACT accounts is kept The poll time i e the keep alive time interval configured in the mIP IPDACT The configurable poll time is 10 seconds More traffic is generated with a shorter poll Alarms sent by the mIP IPDACT modules Traffic generated by the configuration synchronizations between the VisorALARM devices we fix the poll time to the minimum configurable value of 10 seconds we can estimate the maximum required for the ARC IP service of traffic in the traffic from the Kbps Kbps Kbps Kbps Kbps Kbps Kbps Kbps Kbps Kbps Kbps Kbps 1 Maximum ARC throughput as a function of the amount of served mIP IPDACT poll time in UL listed mIP and IPDACT devices is limited to a minimum of 90 complying with UL specifications values in Chart 1 were measured assuming a traffic pattern of a typical ARC where 55 of the IP corresponds to user alarms 35 corresponds to account supervision and the rest is used for the Main Backup VisorALARM Data Base synchronization in High Availability scenarios The traffic is illustrated in Chart 2 6 2 The typical ARC traf