![[prev]](left.gif)
![[up]](up.gif)
![[next]](right.gif)
Previous: 1 Introduction
Up: Securing 'Classical IP over ATM Networks'
Next: 3 Solutions
The model for the following security analysis of a ``Classical IP over ATM'' (CLIP) LAN consists of two logical IP subnets (LIS) connected to each other by a firewall. The firewall is used to divide the LAN into a critical subnet containing valuable data called the ``internal network'' (192.168.15.0) and a public subnet connected to the world called the ``external network'' (192.168.16.0). The TCP/IP traffic between the networks is examined by the firewall. The type of services provided and the access control policy enforced by the firewall will not be discussed here. Currently no ``native ATM'' applications need to be supported, but the concept must not prohibit extensibility.
One possible setup for the above requirements is shown in figure 1. This configuration has two major drawbacks. Firstly, it does not allow for the possibility of running a ``native ATM'' application using both of the networks, as the firewall only provides TCP/IP services. Secondly, as this configuration requires the use of two ATM switches, expensive equipment is wasted.
Figure 1:
Gateway-Firewall in an ATM Network
As ATM allows for multiple virtual networks on the same physical network (i.e. on the same ATM switch) a similar setup can be built with just one ATM switch (see fig. 2).
Figure 2:
Gateway-Firewall with one ATM Switch
The configuration of multiple virtual networks using one ATM switch is a simple task, but configuring this setup in a secure mode requires a deep analysis of the associated risks. The configuration with one ATM switch allows ``native ATM'' traffic to bypass the TCP/IP firewall. Unfortunately, ``native ATM'' connections can also be used to send IP datagrams. By circumventing the local Classical IP stack an attacker can send IP datagrams to systems in the other virtual network without traversing the firewall. The associated security risks and possible solutions are discussed in the following sections.
IP spoofing attacks have been well understood for many years [2]. Essentially, IP spoofing means sending IP packets with faked IP source addresses. Services that use IP source addresses for authentication can be easily exploited by this attack.
IP spoofing is possible in `Classical IP over ATM' (CLIP) networks.
Whenever the ATM address of a server is known, an attacker
can establish a direct ATM connection![[*]](foot_motif.gif)
to that host.
The attacker can now register with the IP address of a trusted host
by sending a carefully crafted `InATMARP-Reply' message over
this connection. After successful registration, spoofed IP packets can
be sent over this connection. Moreover, due to the ``ATMARP-Cache poisoning'',
the attacked server will send reply packets back to the attacker
on the same ATM connection.
This kind of attack is possible, because the peers do not authenticate each other in a reliable manner. Moreover section 6.4 ATMARP Client Operational Requirements of RFC 1577 [10] explicitly requires, that CLIP clients process 'InATMARP-Requests' and 'InATMARP-Replies' in order to update their local address resolution tables.
In contrast to legacy LANs (e.g. Ethernets) there is no need to attack
the host whose address has been used. Because the server sends its
segments over the virtual connection to the attacker, the trusted host
will not notice that its address has been used by another system.
Furthermore there is no need for the attacker to guess the TCP sequence number of the server. The server will use the established virtual connection to send its segments to the attacker. So all other packets destined to the trusted host will also be sent to the attacker (see also section 2.3).
In summary, IP spoofing is easier to accomplish in ATM based networks and harder to detect. It can also be considered more dangerous, as simple countermeasures, for example requiring an IDENT [9] query before access is granted, can be spoofed more easily than in ``legacy networks''.
The figure 3 shows the time-sequence diagram of a successful simulated attack in a test environment. The attacker (A) pretends to be the host (192.168.15.A) and registers itself by sending an `InATMARP-Reply' to host (B). In order to verify that the spoofing is successful, an `ICMP-ECHO-Request' is used to test the established connection.
Figure 3:
ATM based Spoofing Attack
It should be noticed that the attack is not detectable unless the host (B) verifies the 'InATMARP-Reply' by contacting a trusted ATMARP server (see section 3.1 for a discussion on securing the ATMARP server).
This attack is not restricted to hosts in the same LIS. Any host to which a direct ATM connection can be opened can be attacked. Routers that connect different LISs can be bypassed if the underlying ATM network allows for a direct ATM connection between hosts in different LISs. It is therefore important to point out that filters in these routers cannot be used to protect against this type of IP spoofing attacks. Neither a firewall nor an inter LIS router will have access to the datagrams because all hosts of the same LIS always use direct (non routed) connections. Moreover if the attacked host subsequentially wants to open TCP connections to the host (e.g. an IDENT query [9]), the address of which has been used for spoofing, a typical implementation will use the established virtual connection to the attacker. This would also enable the attacker to perpetrate `Man in the Middle' attacks.
The attacker may now register itself with any unused IP address of the LIS. As every IP address can only be registered once, this will prevent hosts that were temporarily offline from registering themselves, if the attacker succeeds in allocating their IP address. The LIS member will be unable to use CLIP services as long as its IP address is registered with the attacker. Moreover the attacker may wait for clients to go offline by periodically verifying if a learned binding is still in the ATMARP servers cache.
Instead of reserving a random IP address in the subnet, the attacker only reserves the addresses of those LIS clients which are known to be temporarily offline. This puts the attacker in the position of being able to perpetrate very efficient attacks. Some additional aspects of ATMARP server based denial of service attacks are discussed in [1].
This kind of attack is possible, because any host that is able to
establish an ATM connection to the ATMARP server, may register various
<IP address,ATM address> bindings without authentication. An
attacker only needs the ATM address of an ATMARP server in order to
establish a virtual connection. Since the ATM address of the attacker is
not used for path finding during signaling, the attacker may
select any ATM address during connection establishment with the ATMARP
server. This makes it even harder to trace the origin of
an attack, as the address information in the ATMARP server cannot
be trusted.
ATM address.
Moreover this kind of attack is hard to trace. The reservation of resources is a common procedure in ATM networks so that each intermediate switch may have to refuse the establishment of a connection due to insufficient resources. If a switch refuses the establishment of a CBR or VBR CLIP connection, the client host cannot detect whether this is due to normal protocol processing or vicious bandwidth allocation. There is also no way to deduce an attack by bad performance over an unspecified bit rate (UBR) connection since the throughput of an UBR connection may degrade at any time due to normal resource allocation in an ATM network.
to 2^24.
It seems that this huge number of simultaneous connections
is enough even for a big server but a typical client implementation of
an ATM device driver limits the number of VCIDs to a considerable
smaller number of 1024 or 2048. This limit of 2048 connections can be
reached by an attacker trying to block a host from communication.
A problem arises by the fact that ILMI does not provide a mechanism
for the authentication because the underlaying SNMP only uses clear
text pass phrases as a weak authentication mechanism. Moreover the
community name to access the ILMI management information base (MIB) is
specified as `ILMI' [13, p. 147]. An attacker who does not need
to authenticate himself can use the ILMI to register additional ATM
addresses for his workstation. By using the additional registered
address the attacker can bypass address filters which have been
configured at the switch. The attacker could also try to register
himself with the ATM address of an offline workstation. This is
similar to the attack described in section
2.2. ILMI can also be used to automatically configure
the interface type of an ATM switch-port. An attacker may use ILMI to
pretend that he is a switch by setting the interface type to ``NNI''
(Network to Network Interface).
In order to attack the switch the UNI signaling has to be changed to
NNI
signaling. This has to be done prior to attacks on the switch to make
sure, that the switch will recognize the P-NNI protocol as this will
be used by the attacker.
We will briefly discuss a possible strategy an attacker could use in
order to prepare for the attack on a switch (see the following
section). In typical ``Plug and Play'' installations it is likely that
the attacker's host is connected to an ATM switch that uses the ILMI
protocol for automatic configuration. The host
has already been detected by the switch and the interface (port) of
the switch is configured for UNI signaling. In
order to change the interface from UNI to NNI it is sufficient to use
the following ILMI mechanisms:
setup, and the
attacker can use the P-NNI routing protocol to confuse the switch as
described below.
database or even try to configure routing loops into the hierarchic
structure. He might block the communication of whole peer groups or
even redirect communication over his workstation. The blocking of a
peer group is very similar to the manipulation of routers with incorrect
'ICMP-Host/Net- unreachable' messages.
Attacks based on the P-NNI protocol can use replies to `HELLO' messages of a peer group leader to inject malicious information about `link states'. The peer group leader in turn will broadcast these changes to its group members. Peer group members that have updated their link state information with faked information are likely to make the wrong routing decision.
Carsten Benecke, Uwe Ellermann / DFN-FWL