Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security

From: "Sami Vaarala" <[email-masked]>
Date: Tue, 14 May 2002 13:25:45 +0300

Hi all,

Here is a new try on the security considerations section.
We tried to partition the discussion to a more manageable
form.

Francis, does this seem reasonable to you?  Any other
issues to be discussed?

Best regards,

-Sami

--------

6. Security Considerations

   The ordinary Mobile IP security mechanisms are also used with the NAT
   traversal mechanism described in this document.  However, there is
   one noticeable change: the NAT traversal mechanism requires that the
   HA trust unauthenticated address (and port) fields possibly modified
   by NATs.

   Relying on unauthenticated address information when forming or
   updating a mobility binding leads to several redirection attack
   vulnerabilities.  In essence, an attacker may do what NATs do, i.e.
   modify addresses and ports and thus cause traffic to be redirected to
   a chosen address.  The same vulnerabilities apply to both MN-HA and
   FA-HA NAT traversal.

   In more detail: without a NAT, the care-of address in the
   registration request will be directly used by the HA to send traffic
   back to the MN (or the FA), and the care-of address is protected by
   the MN-HA (or FA-HA) authentication extension.  When communicating
   across a NAT, the effective care-of address from the HA point of view
   is that of the NAT, which is not protected by any authentication
   extension, but inferred from the apparent IP source address of
   received packets.  This means that by using the mobile IP
   registration extensions described in this document to enable
   traversal of NATs, one is opening oneself up to having the care-of
   address of a MN (or a FA) maliciously changed by an attacker.

   Some, but not all, of the attacks could be alleviated to some extent
   by using a simple routability check.  However, this document does not
   specify such a mechanism for simplicity reasons and because the
   mechanism would not protect against all redirection attacks.  To
   limit the duration of such redirection attacks, it is RECOMMENDED to
   use a conservative (that is, short) mobility binding lifetime when
   using the NAT traversal mechanism specified in this document, and
   also use registration request keepalives rather than ICMP echo
   request keepalives.

   The known security issues are described in the sections that follow.

6.1 Traffic Redirection Vulnerabilities

6.1.1 Manipulation of the Registration Request Message

   An attacker on the route between the mobile node (or foreign agent)
   and the home agent may redirect mobility bindings to a desired
   address simply by modifying the IP and UDP headers of the
   Registration Request message.  Having modified the binding, the
   attacker no longer needs to listen to (or manipulate) the traffic.
   The redirection is in force until the mobility binding expires or the
   mobile node re-registers.

   This vulnerability may be used by an attacker to read traffic
   destined to a mobile node, and to send traffic impersonating the
   mobile node.  The vulnerability may also be used to redirect traffic
   to a victim host in order to cause denial-of-service on the victim.

   The only defence against this vulnerability is to have a short time
   between re-registrations, which limits the duration of the
   redirection attack after the attacker has stopped modifying
   registration messages.

6.1.2 Sending a Bogus Keepalive Message

   When registering through a FA using a co-located care-of address,
   another redirection vulnerability opens up.  Having exchanged RRQ/RRP
   messages with the HA through the FA, the MN is expected to send the
   first keepalive message to the HA, thus finalizing the mobility
   binding (the binding will remain in a "half open" state until the
   keepalive is received).

   Having observed a RRQ/RRP exchange, an attacker may send a bogus
   keepalive message assuming that the mobility binding is in the "half
   open" state.  This opens up a similar redirection attack as discussed
   in Section 6.1.1.  Note, however, that the attacker does not need to
   be able to modify packets in flight; simply being able to observe the
   RRQ/RRP message exchange is sufficient to mount the attack.

   With this in mind, the home agent MUST NOT accept a keepalive message
   from a different source IP address than where the RRQ came from, as
   specified in Section 4.6.  This requirement limits the extent of the
   attack to redirecting the traffic to a bogus UDP port, while the IP
   address must remain the same as in the initial RRQ.

   The only defences against this vulnerability are: (1) to have a short
   time between re-registrations, which limits the duration of the
   redirection attack after the attacker has stopped sending bogus
   keepalive messages, and (2) to minimize the time the binding is in a
   "half open" state by having the mobile node send the first keepalive
   message immediately after receiving an affirmative registration
   reply.

6.2 Use of IPsec

   If the intermediate network is considered insecure, it is recommended
   that IPsec be used to protect user data traffic.  However, IPsec does
   not protect against the redirection attacks described previously,
   other than to protect confidentiality of hijacked user data traffic.

   The NAT traversal mechanism described in this document allows all
   IPsec-related traffic to go through NATs without any modifications to
   IPsec.  In addition, the IPsec security associations do not need to
   be re-established when the mobile node moves.

6.3 Firewall Considerations

   This document does not specify a general firewall traversal
   mechanism.  However, the mechanism makes it possible to use only a
   single address and a port for all MN-HA (or FA-HA) communication.
   Furthermore, using the same port for the MIP UDP tunnelled traffic as
   for control messages makes it quite probable that if a MIP
   registration can reach the home agent, MIP tunnelling and reverse
   tunnelling using the described mechanism will also work.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 May 2002 21:38:42 +0200

Francis, does this seem reasonable to you?

=> this is fine. Perhaps a bit long but IMHO this is a good property
for security considerations.

   Any other issues to be discussed?
   
=> no. MIP is not the only protocol which becomes vulnerable when
one adds NAT traversal to it, even if the base protocol is itself
very secure... So this is only another hard issue from NATs.

Thanks

[email-masked]