The simple question “react or not react on received ICMP notification?” cannot be answered clearly and definitively. It depends on many factors and only indirect indices can give the answer with some probability. It is a task of the network security policy to define heuristic rules [14] for dealing with these types of messages. This is a problem limited not only to the M-VPN and it is problem for all security protocols, like as IPSec. The heuristic rules can be for example: revise check if the sender is replying to pings, trace route to the sender, allow a range of minimal MTU values, restrict the number of ICMP messages per second, etc.
6.2.2 Denial of Service attacks
The M-VPN secures the transported data, but does not provide any delivery guarantee. It is possible that the packets are dropped, wrongly delivered or retransmitted by the intermediate router. The packet routing and in general the transportation is not a protected service and an attacker can easily manipulate the IP and UDP header without even knowing the content.
Denial of Service attacks can be performed without any security knowledge, simply by replaying M-SE packets. The M-VPN gateway must decrypt the packet in order to verify the sequence number. This requires computational power of the gateway and an attacker can easily overload the gateway.
The risk of (D)DoS can be minimized by implementing intrusion detection and prevention policies with heuristic rules. They can be very simple, for example: if a host has sent more than 10 packets incorrectly, then it is blocked for 5 minutes. If the M-SE packet received was repeated more then 10 times, this M-SE session is blocked for 5 min. This is a heuristic solution using efficient simple rules for preventing most practical attacks. Every rule can affect trustful (innocent) M-SE sessions and this can become an undesired issue. The heuristic rules are trade-off filters for the bad and good connections using abnormal behaviour detection. This of course, doest not prevent (D)DoD attacks, but my limit the effect of the attack.
6.3 State attacks
State attacks try to mislead the protocol in circular behaviour or to cancel certain session. The main instruments are out of sequence packets, replay or dropping packets.
6.3.1 Lost last acknowledgement
The security protocols are connection-oriented, because they negotiate security parameters. A general problem of all connection-oriented protocols is the so-called “lost last acknowledgement”. Both nodes can get in not corresponding states, so that the sent packets get lost. For example: Alice and Bob have one active session. After some time Alice sends finish/close message and deletes the session. If this finish message gets lost, Bob will not close its session and will keep using it. The sent packets by Bob get lost, since Alice has no session any more.
The not secure protocols can mange a workaround to this issue. The TCP [15] stack, for example, uses a simple rule: if a packet is received for not existing session, then a packet with control bit RST is send back. The receiver of the RST deletes its session. The connection is closed and both nodes arrive at the same state.
This problem is more complex in the security protocols, because they should ignore unauthenticated packets. The connection does not exist any more in the memory of the receiver and there is no key, ID etc. It cannot be answered in an authenticated way, consequently the peer will not trust this unauthenticated answer. Otherwise, an attacker can
6.3 State attacks 101
reset every security connection. This problem cannot be solved principally by a design in any security protocols. It can be reduced only in the implementation using local policy with heuristic rules.
Partial solution in some security implementations, such as Cisco IPSec [9], is using “down-negotiation” state. After sending close notify, the session goes in state “down- negotiation”. The security parameters are kept for replying in an authenticated way if the last packet gets lost. The problem is only partially solved, because the time for keeping the state “down-negotiation” is limited. There is still the possibility to receive a packet after the “down-negotiation” is deleted. Furthermore, if the remote peer is not sending packets then its session will stay active. The session closure may be the trigger for backup actions or/and routing updates.
This is a security thread of all protocols and must be considered by the implementations. The M-KE implementation should implement the Cisco IKE strategy, since it limits to some degree the problem.
6.3.2 Rollback behaviour
Rollback behaviour occurs, when the send/receive timeout is shorter than the round trip delay. The host receives delayed packets with previous state and goes back to the last state (the state rolls back). If the transmission time is constant, this will cause delay in the negotiation by some packets, but the negotiation will be successfully finished.
The rollback becomes an issue when the transmission time is not constant during the negotiation. Some of the packets have bigger delay compared to other ones during the negotiation. The mobile environment uses mostly wireless connections, which are very unstable when the host moves. At some physical position during the movement, there is a strong signal and in some not. In areas with low signal, there will be more errors in the transmission. Therefore, some retransmission at wireless layer may be needed and the total delay will increase. When the host moves, there will be variable delay depending on the physical position of the node to the antenna. The variable delay in the negotiation can cancel the negotiation because of the retransmissions. Every protocol has a limit for retransmitting during the negotiation. When this number is reached, the negotiation is discarded. A simple example is show in Figure 6.3. Every state is retransmitted increasingly, which causes connection drop at the end.
The same behaviour can occur not only due to natural properties of the media, but also due to attack. An active attacker can disturb the commutation and cause circular behaviour of the both nodes. The problem cannot be solved principally, but can be reduced by using some rules. Dropped and out of sequence packets are expected in mobile environments. In order to reduce this circular behaviour, the following rules are set in M-VPN:
Host A Host B State 1 time time State 2 State 1* State 3 State 4 State 4 State 3 State 2 State 5 State 5 State 3* State 4 State 5 State 6 State 5* State 6
* - retransmittion due to timeout
timeout timeout timeout timeout timeout timeout
6.4 Attacks on M-KE and M-SE