Voice/Video over Internet Protocol (VVoIP) STIG

Unified messaging and email systems provide the capability to receive voicemails via email and in some cases, have emails read to the user via a text-to-speech feature when accessing the system from a telephone (dial-in). For DoD, this presents two issues or vulnerabilities. Access to voicemail from a telephone only requires the user’s telephone number and a PIN. The telephone number is the account or mailbox number on the voicemail system while the PIN is the user password for accessing the account. This is a rather weak authentication method. The first issue for DoD, is that DoD policy states that access to email requires PKI based authentication of the user before they are granted access to their email account. PKI certificates are required to decrypt encrypted email. PKI authentication is not available when using a standard telephone. While some organizations might implement PKI authenticated access to the site’s phone system, such a facility is not available via most DoD phone systems and certainly not via the PSTN. Additionally, while a non-PKI enabled text-to-speech feature would not be able to read encrypted email (which would be considered the most sensitive) the unencrypted email is still considered sensitive DoD information. The argument could be made that normal voicemail messages and regular telephone conversations can also contain sensitive information. However, there is typically more sensitive information in email. This does not apply to DoD issued PDA/PED devices that provide CAC authenticated access to email. Access to unified mail voicemail would be via PKI authenticated email service through which the user could listen to the voicemail. Text-to-speech conversion would be permitted in this case even though caution should be used when listening to any voicemail, particularly in a public place. The use of a wired earphone is highly recommended. The use of Bluetooth, DECT/DECT 6.0, and other RF wireless technologies for accessories must be approved.

Visual collaboration often requires the sharing or display of presentations, open documents, and white board information to one or more communicating endpoints. While the technology for doing this is different between hardware based endpoints and PC based application endpoints, the vulnerability it creates is the same. In both cases, the displayed information typically resides on a PC. While in presentation/sharing mode, care must be exercised so that the PC user does not inadvertently display and transmit information on their workstation that is not part of the communications session and not intended to be viewed by the other communicating parties. Users must be aware that anything they display on their PC monitor while presenting to a communications session may be displayed on the other communicating endpoints. This is particularly true when the PC video output is connected to a VTC CODEC since the information will be displayed on all of the conference monitors. This presentation/sharing feature could result in the disclosure of sensitive or classified information to individuals that do not have a validated need-to-know or have the proper clearance to view the information. Thus, the presentation/sharing feature presents a vulnerability to other information displayed on the PC, if the feature is misused. This is a problem when sharing (displaying) a PC desktop via any collaboration tool using any connection method. There is little that can be done to mitigate this vulnerability other than to develop policy and procedures to present to collaborative communications sessions. All users that perform this function must have awareness of the issues and be trained in the proper operational procedures. Such procedures may require that there be no non-session related documents or windows open or minimized on the PC while presenting or sharing. An additional requirement may be that the user may not permit others in a session to remotely control their PC. A similar issue is that some PC based collaboration applications can permit a user to allow other session participants to remotely control their PC. Depending upon how this feature is implemented and limited, it could lead to undesired activities on the part of the person in control and possible compromise of information that is external to the collaboration session. This would be the case if such sharing or remote control provided access to the local hard drive and non session related applications or network drives accessible from the controlled PC.

The protection of the VVoIP system is enhanced by ensuring all VVoIP systems and components within the LAN (Enclave) are deployed using separate address blocks from the normal data address blocks. This is one of the required steps required to help protect the VVoIP infrastructure and services by allowing traffic and access control via firewalls and router ACLs.

Assigning static addresses to core VVoIP servers and devices permits tighter control using ACLs on firewalls and routers to help in the protection of these devices.

When using Dynamic Host Configuration Protocol (DHCP) for address assignment and host configuration, different DHCP scopes (different address space, subnets, and VLANs) must be used for voice components and data components. Optimally, the design would place a DHCP server dedicated to providing IP address and configuration information to the VVoIP endpoints separate from the IP address and configuration information to data hosts (workstations etc.). The DHCP server providing VVoIP devices should be in a Voice Video and/or Unified Capability (UC) domain having the same address space and VLAN to prevent DHCP requests routed onto the data environment that degrade the separation of the VVoIP environment and the data environment. With centralized management of DHCP (and other services, such as DNS) this separation is obviously eliminated. DHCP requests and responses for voice must reside on a segregated VLAN. The best practice is to manually assign addresses when authorizing the instrument by generating its configuration file. In the event a dedicated DHCP server for VVoIP endpoints is not implemented, the network (i.e., the router controlling access to and from the VVoIP endpoint VLANs) must route VVoIP endpoint DHCP requests directly to the DHCP server in such a manner that prevents traffic to flow between the VVoIP and data VLANs. Additionally the DHCP server must prevent such traffic flows while providing the VVoIP endpoints with proper VVoIP addresses and other information within the VVoIP address/subnet range (scope).

Based on a previously stated requirement, a VVoIP system must have one or more production VLANs containing the VVoIP endpoints and a separate OOB management network or virtual management network (management VLAN). Also previously stated is the requirement that the LAN NEs maintain the separation between management network(s) and the production network VLANs by blocking traffic from passing between them. Maintaining this separation is also incumbent upon the managed devices that are connected to both the management and production VLANs. Individual VVoIP system core devices and traditional TDM based telecom switches connect to their production and management networks or VLANs in different ways. In some cases there are separate dedicated physical management and production interfaces. There may also be one or more physically separate management interfaces. On the other hand these interfaces may be logical or there may be some combination of logical and physical interfaces that support the required production and management traffic. In the event production and management connections use separate interfaces, whether logical or physical, the target/ managed device must not permit one network (physical or logical VLAN) to access another network through the device. That is, the device must not route IP traffic between logical or physical interfaces connected to different VLANs or physical networks that are part of a different logical security zone (protected VLAN) or physical network enclave. Permitting such routing permit a host on one network or VLAN to gain unauthorized access to a host on another network which can lead to complete corruption of the accessed system or device causing the, loss of availability (denial-of-service), integrity, and information or communications confidentiality. NOTE: While this specifically addresses a similar situation addressed in the Network Infrastructure STIG that essentially requires that the production side of a managed device must not be accessible from the management interface and vise versa, this requirement extends that requirement to multiple management interfaces. Many DSN switches and DISN IPVS system core devices are managed from the BCPS network and CCSA NOC via one interface and also monitored and potentially managed by the DISA ADIMSS or other NOC. These are separate enclaves which must be protected from inappropriate access between them. In some cases the connections from these enclaves to the managed devices are via separate interfaces on the managed devices. Ergo the requirement the managed device must not pass traffic between these interfaces. Information Assurance Officer

VLAN and IP address segmentation enables access and traffic control for the VVoIP system components. Only the required protocols are to reach a given VVoIP device thereby protecting it from non-essential protocols. This protection is afforded on the LAN by implementing ACLs based on VLAN/subnet, protocol and in some instances specific IP addresses. While a firewall placed between the core equipment and endpoint VLANs might provide better protection for the core equipment as a whole, a router is best suited to control the varying traffic patterns between the various devices.

While VLANs facilitate access and traffic control for the VVoIP system components and enhanced QoS, they should only be implemented on the network elements that are needed to carry the traffic from the attached devices. LAN switches will typically learn the VLANs configured on an adjacent switch and configure it locally. As such a VLAN configured on one switch can be learned and configured on the entire LAN in a very short period of time. Too many learned VLANs and a NE can crash. Additionally, a VLAN that appears on NEs where it is not required to carry traffic, places the VLAN at risk of compromise by presenting many more points at which the VLAN might be accessed. Therefore the VLANs must be pruned from trunks and interfaces where the VLAN does not need to send traffic. A VLAN that supports a number of local VVoIP endpoints only needs to traverse the NEs in two paths to the core routing devices at the VVoIP core equipment, Any specific endpoint VLAN does not need to appear on every switch in the LAN unless it serves endpoints everywhere on the LAN. Likewise the VVoIP core equipment VLANs do not need to extend past the VVoIP core routing devices (routers or layer 3 switches. The endpoint VLANs come to the core, the core VLANs do not extend to the endpoints. As such all VLANs must be pruned from any trunk where its traffic does not need to go.

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should send an alarm in response to inappropriate traffic and log the occurrence. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system .

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system. Information Assurance Officer

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system .

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.

Voice mail services in a VoIP environment are available in several different configurations. A legacy voice mail platform can connect to a VoIP environment to provide voice mail services for VoIP users. In the same respect, a VoIP voice mail platform can provide voice mail services to the legacy voice users and the VoIP users. Some voice mail systems are also capable of providing unified mail by interacting with email messaging systems. Voicemails when recorded are converted to a .wav or similar digital audio file and sent to the email server as an attachment to an email. The subject line will typically contain the caller ID information if available. The email user can then open the attachment and listen to the voicemail on their PC or whatever device that provides properly authenticated access to the user’s email. Since the voicemail server must access the voice network (which, in a VoIP system is the VoIP VLAN system), and the data network (data VLANs) to send the email, caution and control must be exercised to not degrade the separation between the voice and data VLANs. Additionally, if the email server is part of or collocated with the voicemail server, user access to email must also not degrade the separation between the voice and data VLANs. Since this server may have 2 NICs and be connected to both voice and data VLANs, the server must not act as a bridge between the voice and data VLANs.

Some VVoIP hardware endpoints and hardware based VTC endpoints contain a multi-port Ethernet switch to provide a connection on the endpoint for external devices such as a workstation (i.e., PC port). Additionally, some of these endpoints have the capability of defining the VLAN that their traffic will use via various methods but most typically by using 802.1Q trunking (VLAN tagging). However, some endpoints do not support VLAN assignment or cannot themselves maintain VLAN separation. In these cases, the responsibility of VLAN assignment and maintenance of VLAN separation falls to the LAN access switch (discrete NE or module in a larger NE) that supports the LAN cable drop to which the endpoint(s) is connected. Typically the LAN access switch port configurations contain a statement assigning the port to a specific VLAN.

Some VVoIP hardware endpoints and hardware based VTC endpoints contain a multi-port Ethernet switch to provide a connection on the endpoint for external devices such as a workstation (i.e., PC port). This is done so that a PC and a workstation can share a single network cable drop and LAN access layer switch port. The PC port can, in general, support any device requiring an Ethernet connection. In theory, a VoIP phone, a desktop VTC unit could be daisy chained on a single LAN drop. These embedded multi-port Ethernet switches must be capable of maintaining the separation of the voice (VVoIP), data, VLANs as well as the VTC VLAN and PC Comm Client VLAN if present. For example the attached PC must not be able to directly access the phone’s or VTU’s configurations or communications traffic. VAN separation helps to prevent this. NOTE: the switch or endpoint will typically utilize 802.1Q trunking (VLAN tagging) but may use some other means to separate voice and data traffic. Typically when 802.1Q VLAN tagging is used, the phone firmware tags the VoIP packets while the embedded switch passes all packets without modification. This permits devices connected to the PC port to tag their packets and assign the proper VLAN to their traffic type. 802.1Q VLAN tagging enables the LAN to better maintain separation of the traffic and is therefore the preferred method. The LAN access switch (discrete NE or module in a larger NE) must be capable of, and must be configured to, support the VLAN separation method used by the supported endpoints. The NE may perform this function in various ways as determined by the overall VVoIP system and LAN design. However, the typical (or preferred) method used by an endpoint to maintain VLAN separation is 802.1Q VLAN tagging. As such, the LAN access port and NE needs to support the receipt of tagged packets and handle them appropriately to also maintain VLAN separation. While the NE may retag the packets thereby reassigning the VLAN based on some defined rule, the NE may not strip the tags and mix all traffic together. Furthermore, The LAN access NE supporting LAN cable drops will typically have a VLAN defined for each service (VVoIP, VTC, Data, PC Comm. Client) supported by the endpoints connected to the NE. Traffic within the respective VLANs may flow between different physical ports on the NE but may not change VLANs in the process. This must be done by a routing device (discrete NE or module in a larger NE) and must be controlled by an appropriate ACL. The LAN access layer Ethernet switch may be combined in the same unit with the routing device as in the case of a layer-3 switch or a router containing an Ethernet switch module.

Policy regarding LAN access switchport mode has been established in the Network Infrastructure STIG by NET1416 which states “ensure trunking is disabled on all access ports (do not configure trunk on, desirable, non-negotiate, or auto—only off).” The reason for this is that a malicious user could affect a VLAN hopping attack. VLAN “hopping” occurs when a tagged frame destined for one VLAN is redirected to a different VLAN, threatening network security. The redirection can be initiated using two methods: “tagging attack” and “double encapsulation.” Frame tagging attacks allow a malicious user on a VLAN to get unauthorized access to another VLAN. For example, if a switch port’s trunk mode were configured as auto (enables a port to become a trunk if the connected switch it is negotiating trunking with has its state set to on or desirable) and were to receive a fake DTP packet specifying trunk on or desirable, it would become a trunk port and it could then start accepting traffic destined for all VLANs that belong to that trunk group. The attacker could start communicating with other VLANs through that compromised port—including the management VLAN. Insuring that trunk mode for any non-trunking port is configured as off can prevent this type of attack. Double encapsulation can be initiated by an attacker who has access to a switch port belonging to the native VLAN of the trunk port. Knowing the victim’s MAC address and with the victim attached to a different switch belonging to the same trunk group, thereby requiring the trunk link and frame tagging, the malicious user can begin the attack by sending frames with two sets of tags. The outer tag that is the attacker’s VLAN ID (probably the well known and omnipresent VLAN 1) is stripped off by the switch, and the inner tag that will have the victim’s VLAN ID is used by the switch as the next hop and sent out the trunk port. To ensure the integrity of the trunk link and prevent unauthorized access, the native VLAN of the trunk port should be changed from the default VLAN 1 to its own unique VLAN. NOTE: Trunk mode is typically used between LAN switches to extend defined VLANs across a network. This mode is used to interconnect LAN switches and routers with other LAN switches and routers to create a network across multiple NEs. Trunk mode generally requires each packet to be tagged with the VLAN ID that it belongs to. This tagging can follow the 802.1Q standard format or can use a vendor proprietary protocol such as Cisco’s ISL. Access mode on the other hand is used on a switchport that supports a connection to a LAN endpoint device. Typically single endpoint devices connected to a switchport send traffic that does not contain a VLAN tag. In this case, if a VLAN is defined for the endpoint, the switchport is statically assigned to a VLAN. As such, when a packet is received and sent out the “Trunk” the packet is tagged with the VLAN ID. Best practices dictate that the implementation of VVoIP on a network requires one or more VVoIP VLANs be established within the network. Therefore LAN access switchports that support VVoIP and VTC endpoints that do not tag or are capable but not configured to add a VLAN tag to their traffic must be statically assigned to the local VVoIP VLAN. VVoIP and VTC endpoints that do have the capability of adding the VLAN tag to their traffic typically use 802.1Q format and also typically support a PC port on the device. The PC port is added to the VVoIP or VTC endpoints since it reduces cabling and LAN infrastructure cost. Typically, VVoIP or VTC endpoints that support a PC port pass traffic from this port unchanged whether the traffic is tagged or not, while adding the VVoIP VLAN tag for the locally defined VVoIP VLAN to its VVoIP traffic. As such, a LAN access switchport must now support tagged and untagged traffic and keep the traffic separated. This is done by defining a default “data” VLAN (that is not the default VLAN on the NE such as VLAN 0 or 1) for the switchport in which untagged traffic is placed and defining a secondary VVoIP VLAN that matches the 802.1Q tag used for the VVoIP traffic. This method maintains the LAN access nature of the port even though it supports multiple VLANs while not requiring it to be configured as a trunk.

VVoIP or VTC endpoints that are not configured to or cannot provide a 802.1Q VLAN tag to its VVoIP traffic have no control over what VLAN their traffic ends up in, if any. Therefore the responsibility of placing VVoIP or VTC traffic in an appropriate VLAN for the type of traffic falls to the LAN switch. As such each switchport on a LAN NE that supports a VVoIP or VTC endpoint must place the traffic in the correct VLAN. This means that, in lieu of any other means to sort the traffic, each switchport must be statically assigned to the appropriate VLAN. NOTE: In some cases a LAN NE can use some other endpoint or traffic characteristic other than 802.1Q tagging to assign the traffic to the correct VLAN.

Many VVoIP and VTC endpoints provide a PC port on the device. Doing so permits a PC to share the same LAN drop as a VoIP phone or desktop VTC endpoint. The net effect is reduced installation and maintenance cost for the LAN infrastructure. Endpoints that provide a PC port have an embedded Ethernet switch which is required to support the separation of the PC data traffic from the VVoIP and VTC traffic. This is primarily accomplished by the embedded Ethernet switch in the endpoint supporting VLANs. In support of this, many VVoIP and VTC endpoints have the capability of adding a VLAN tag to their traffic using the 802.1Q format. Typically the PC port traffic is passed to the LAN unchanged whether the traffic is tagged or not, while adding the VVoIP VLAN tag for the locally defined VVoIP VLAN to its VVoIP traffic. NOTE: this is a limitation of the switchport access mode. It seems that configuring more than a default and tagged VLAN on a switchport requires the port to be set as a trunk, which is not permissible based on NET1416. This causes a limitation in the number of devices and applications that can be supported by a single switchport and LAN drop. For example, a single switchport will support a single VoIP phone (w/ an embedded switch and PC port) which tags its traffic and a connected PC that does not. Similarly, a single switchport will support a single VTC endpoint (w/ an embedded switch and PC port) which tags its traffic and a connected PC that does not. Similarly, a single switchport will support a single PC that supports a soft phone and tags its VoIP traffic while not tagging its data traffic (per the PCCC STIG). A single port will not support a VoIP phone and a VTC endpoint and a PC on a single drop unless the VTC endpoint also tags its VTC traffic with the VoIP VLAN. If a PC with a compliant soft phone is connected, it must also tag its traffic with the single VoIP VLAN tag. NOTE: Traffic to/from a VTC endpoint may use the same VLAN as the VVoIP phone system. Some exceptions may apply. NOTE: Do not use the default VLAN for the switch which is generally VLAN 1. This is used for LAN control traffic. No traffic or interface is permitted to be assigned to the switches’ default VLAN.

The typical perimeter or premise router may not be capable of supporting the needs of VVoIP and UC when entering the DISN WAN. Modern routers are capable of dealing with service classes and expedited forwarding. This why the DISN IPVS PMO specifies the specific additional capabilities required of the perimeter or premise router to support the needs of the Assures Service network. The router designated by the DISN IPVS PMO needed to support the service is the CE-R. The CE-R provides the following functionality: - Provides minimally four forwarding cues (eight preferred) - Places traffic within expedited forwarding cues based on the DSCP markings carried by the traffic. - Routes inbound AS-SIP-TLS packets and SRTP/SRTCP packets to the Session Border Controller (SBC). - Routes SIP and SRTP traffic encapsulated on port 443 to the SBC. - Routes all other inbound traffic to the data firewall. - Provides all of the filtering required of a perimeter or premise router as required by the Router STIG. Proper DSCP marking of VVoIP packets is required to provide appropriate QoS for Command and Control (C2) priority calls in support of Assured Service.

The CE-R is the first line of defense at the gateway to the enclave or LAN. The data firewall and SBC functions are the second line of defense. Since the SBC function only processes VVoIP traffic in the form of SIP, AS-SIP, and SRTP/SRTCP packets, the CE-R should only forward these packets to the SBC, including SIP and SRTP traffic encapsulated on port 443. All other traffic must be forwarded to the data firewall.

The SBC is in the VVoIP signaling between the LSC and MFSS. To limit exposure to compromise and DOS, the SBC must only exchange signaling messages using the designated protocol (AS-SIP-TLS) with the LSC(s) within the enclave and the SBC fronting the MFSS (and its backup) to which the LSC is assigned. Similarly, an SBC fronting an MFSS must only exchange signaling messages with the MFSS and LSC(s) within the enclave and the SBCs fronting other MFSSs and the LSCs assigned to it. While the SBC is also required to authenticate the source and integrity of the signaling packets it receives, filtering on source IP address adds a layer of protection for the MFSS. This is also a backup measure in the event this filtering is not done on the CE-R. Internal to the enclave, filtering signaling traffic based on the IP address(es) of the LSC(s) within the enclave limits the ability of rogue Voice Video Endpoints attempting to establish calls or cause a DOS.

The function of the SBC is to manage SIP and AS-SIP signaling messages. In order to perform its proper function in the enclave boundary, the SBC must decrypt and decode or understand the contents of SIP and AS-SIP messages. Additionally, the SBC can perform message validity checks and determine of an attack is being attempted. The SBC acts as an application level proxy and firewall for the SIP and AS-SIP signaling messages.

The function of the SBC is to manage SIP and AS-SIP signaling messages. The SBC also authenticates SIP and AS-SIP signaling messages, ensuring they are from an authorized source. DoD policy dictates that authentication be performed using DoD PKI certificates. This also applies to network hosts and elements. SIP and AS-SIP are not a secure protocols. The information passed during a call session is in human readable plain text. To secure SIP and AS-SIP, TLS is used. TLS is PKI certificate based and is used for AS-SIP message encryption, authentication, and integrity validation. NOTE: Authentication is provided by validating the sending appliance’s public PKI certificate used to establish the TLS session. AS-SIP messages are not sent until the authenticated TLS session is established.

The validation of signaling packet integrity is required to ensure the packet has not been altered in transit. Packets can be altered during uncontrollable network events, such as bit errors and packet truncation that would cause the packet to contain erroneous information. Packets containing detectable errors must not be processed. Packets can also be modified by a man-in-the-middle attack. The current Unified Capabilities Requirements (UCR) document specifies the hashing algorithm to be used during transmission.

DISN NIPRNet IPVS PMO and the UCR require all session signaling across the DISN WAN and between the LSC and EBC to be secured with TLS. The standard IANA assigned IP port for SIP protected by TLS (SIP-TLS) is 5061. DoD PPSM requires that protocols traversing the DISN and DoD enclave boundaries use the standard IP ports for the specific protocol. Since AS-SIP is a standardized extension of the SIP protocol and since AS-SIP must be protected by TLS, AS-SIP-TLS must use IP port 5061. The VVoIP system may allow SIP and SRTP traffic encrypted and encapsulated using TLS on port 443 from Cloud Service Providers.

The function of the SBC is to manage SIP and AS-SIP signaling messages. The SBC also manages the SRTP/SRTCP bearer streams. The DISN IPVS PMO has determined that the SBC will pass the negotiated and encrypted SRTP/SRTCP bearer streams without decryption and inspection. This is because doing so will not provide a significant security benefit but would cause a significant delay with a resulting decrease in the quality of the communications. Encoded audio and video is difficult to impossible to determine if an attack is being perpetrated or if sensitive information is being improperly disclosed without reconstituting the analog audio and video signals and having a person listen and watch each communication. Due to the volume of communications, to do so would be nearly impossible.

Action cannot be taken to thwart an attempted denial-of-service or compromise if the system administrators responsible for the operation of the SBC and/or the network defense operators are not alerted to the occurrence in real time.

Redundancy of equipment and associations is used in and IP network to increase the availability of a system. Multiple MFSSs in the DISN NIPRNet IPVS network and multiple SSs in the DISN SIPRNet IPVS network have been implemented in each theatre to provide network wide redundancy of their functions. They are intended to work in pairs such that one can provide its backbone services to multiple LSCs that are configured to use one as a primary and the other as a backup. This is necessary to the maintenance of backbone functionality in the event there is a circuit (network path) failure, a MFSS or SS failure, or one of the sites housing a MFSS or SS is lost or the MFSS or SS becomes unavailable. Based on this, when establishing a call on the WAN, each LSC must be configured to signal with a backup MFSS or SS in the event it cannot reach its primary.

MFSSs are critical to the operation of the DISN NIPRNet IPVS network. They broker the establishment of calls between enclaves. A MFSS provides the following functions: > Receives AS-SIP-TLS messages from other MFSSs and a specific set of regionally associated LSCs to act as a call routing manager across the backbone. > Sends AS-SIP-TLS messages to interrogate the ability of another MFSS or a LSC to receive a call, whether routine or priority. > Sends AS-SIP-TLS messages to manage the establishment of priority calls and the pre-emption of lower priority calls to LSCs and other MFSSs > Once a “trunk side” session request is received the MFSS determines if the destination is one of its assigned LSC’s. If so, it interrogates that LSC to determine if it can receive the call. If so, it signals to establish the call. If the destination is not one of its LSCs it signals with other MFSSs to locate the destination LSC and then the remote MFSS negotiates with its LSC. > Acts as a backup MFSS for LSCs assigned to other MFSSs as primary. As such, a LSC must be able to signal with a MFSS in order to establish any call across the DISN WAN. LSCs do not interact directly with LSCs. This hierarchical arrangement is required in order to be able to manage and establish priority calls and manage access circuit budgets. We established previously that each LSC must have a backup MFSS. In support of this function MFSSs must be operated in pairs with all the information about its assigned LSCs replicated across the pair.

Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. The high availability and reliability required for Special-C2 and C2 users is achieved in part by redundancy within the LAN network elements. Policy sets the minimum requirements for the availability and reliability of VVoIP systems Special-C2 users at 99.999 percent, C2 users at 99.997 percent, and C2 Routine only users (C2R) and non-C2 users at 99.9 percent. Voice services in support of high-priority military command and control precedence must meet minimum requirements for reliability and survivability of the supporting infrastructure. Design requirements for networks supporting DoD VVoIP implementations are in the Unified Capabilities Requirements (UCR), specifying assured services supporting DoD IP-based voice services. Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network. This can be accomplished by recovering from network failures quickly and maintaining the required QoS for existing services.Reduced to CAT III when the network elements do not directly support Special-C2 and C2 users.

Policy sets the minimum requirements for the availability and reliability of VoIP systems and the supporting LAN with emphasis on C2 communications. The high availability and reliability required for Special-C2 and C2 users is achieved in part by interconnecting LAN network elements with redundant uplinks via geographically diverse paths. The core layer connects to the distribution layer below it, which then connects to the access layer below it. Voice services in support of high-priority military command and control precedence must meet minimum requirements for reliability and survivability of the supporting infrastructure. Design requirements for networks supporting DoD VVoIP implementations are in the Unified Capabilities Requirements (UCR), specifying assured services supporting DoD IP-based voice services. Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network. This can be accomplished by recovering quickly from network failures quickly and maintaining the required QoS for existing services. Reduced to CAT III when the network elements do not directly support Special-C2 and C2 users.

Extension mobility is a feature of a VVoIP system that permits a person to transfer their phone number extension and phone features (or configuration) to a phone that is not in their normal workspace. This is useful when a person is visiting a remote office away from their normal office and typically functions within an established enterprise wide VVoIP system where the system is designed as a contiguous system. In this case, the system is typically a single vendor solution. The system might be within one LAN/CAN may include multiple LAN/CANs at multiple interconnected sites. To activate this feature, the user approaches a phone that is not their regular phone and identifies themselves to the phone system via a username, password, pin, code, or some combination of these. Upon validation, the system configuration manager will configure the temporary phone to match the configuration of the user’s regular phone. Minimally, the phone number is transferred and possibly some or all of the user’s speed dial numbers and other personal preferences. This capability is dependant upon the capabilities of the temporary phone. Once activated the user’s inbound calls are directed to the temporary location. The user’s regular phone may or may not maintain its normal capabilities and also may also answer inbound calls. Extension mobility is similar to but not the same as forwarding ones calls. Forwarding is typically activated from the user’s normal phone or their user preferences configuration settings. Forwarding is therefore pre-set to a known location. Extension mobility is typically activated from the remote location and is activated upon arrival at that location. Extension mobility should be available only to those individuals that need to use the feature.

Extension mobility is a feature of a VVoIP system that permits a person to transfer their phone number extension and phone features (or configuration) to a phone that is not in their normal workspace. This is useful when a person is visiting a remote office away from their normal office and typically functions within an established enterprise wide VVoIP system where the system is designed as a contiguous system. In this case, the system is typically a single vendor solution. The system might be within one LAN/CAN may include multiple LAN/CANs at multiple interconnected sites. To activate this feature, the user approaches a phone that is not their regular phone and identifies themselves to the phone system via a username, password, pin, code, or some combination of these. Upon validation, the system configuration manager will configure the temporary phone to match the configuration of the user’s regular phone. Minimally, the phone number is transferred and possibly some or all of the user’s speed dial numbers and other personal preferences. This capability is dependant upon the capabilities of the temporary phone. Once activated the user’s inbound calls are directed to the temporary location. The user’s regular phone may or may not maintain its normal capabilities and also may also answer inbound calls. Extension mobility is similar to but not the same as forwarding ones calls. Forwarding is typically activated from the user’s normal phone or their user preferences configuration settings. Forwarding is therefore pre-set to a known location. Extension mobility is typically activated from the remote location and is activated upon arrival at that location. Extension mobility should be available only to those individuals that need to use the feature.