Subject: [mobile-ip] Feedback on mipv4 nat traversal draft: minor changes

From: "Henrik Levkowetz" <[email-masked]>
Date: Fri, 27 Sep 2002 14:24:28 +0200

Minor changes to the mipv4 nat traversal draft:

Feedback from the working group is needed on the changes in the mipv4
nat traversal draft resulting from comments from the ADs and the IESG.
As changes have been made, updated drafts have been submitted. The
most recent draft is -06, which will be announced shortly. It is also
available at:
 http://www.levkowetz.com/pub/id/draft-ietf-mobileip-nat-traversal-06.txt

The following is a list of the minor issues and the resulting changes 
to the draft. The full list of issues and changes can also be found at:
 http://www.levkowetz.com/pub/id/summary-changes-mobileip-nat-traversal-03..06.txt

Please post your comments with the appropriate issue number in the
subject line (instead of simply replying to this email).

Major issues are being posted separately

	Henrik

---

Minor issues:

4.
	The IANA considerations section as formulated in -03 included
    suggestions of numbers to use for interop testing. This has been
    removed, and the whole section rewritten to be clearer and more
    complete.

	|8. IANA Considerations
	|
	|   The numbers for the extensions defined in this I-D should be taken
	|   from the numbering space defined for Mobile IP messages, registration
	|   extensions and error codes defined in RFC 3344 [10].  This draft
	|   proposes one new message, two new extensions and a new error code
	|   that require type numbers and error code value to be assigned by
	|   IANA.  The two new extensions also introduce two new sub-type
	|   numbering spaces to be managed by IANA.
	|
	|   Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request
	|   Extension.  The type number for this extension should be of type
	|   skippable.  This extension introduces a new sub-type numbering space
	|   where the value 0 has been assigned to this extension.
	|
	|   Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply
	|   Extension .  The type value for this extension should be of type non-
	|   skippable.  This extension introduces a new sub-type numbering space
	|   where the value 0 has been assigned to this extension.
	|
	|   Section 3.3 defines a new Mobile IP message, the Tunnel Data message.
	|   The type value for this message should be taken from the numbering
	|   space defined for Mobile IP messages.
	|
	|   Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL:
	|   "Requested UDP tunnel encapsulation unavailable", from the numbering
	|   space for values defined for use with the Code field of Mobile IP
	|   Registration Reply Messages.  This code should be taken from the
	|   subset "Error Codes from the Home Agent".

	    The values for the Next Header field in the MIP Tunnel Data Message
	    (Section 3.3) shall be the same as those used for the Protocol field
	|   of the IP header[2], and requires no new number assignment.

5.
	The references to the base specification for mobile ip has been
    updated to point to RFC3344.

6.
	In the problem description, some language was clarified, and it was
    more clearly pointed out that the nat traversal problem lies in 
    IP-IP tunnelling not providing port numbers for the NAT to use. 

	 1.2 Problem description

	    A basic assumption that Mobile IP [10] makes is that mobile nodes and
	|   foreign agents are uniquely identifiable by a globally routable IP
	|   address.  This assumption breaks down when a mobile node attempts to
	    communicate from behind a NAT.

	    Mobile IP relies on sending traffic from the home network to the
	    mobile node or foreign agent through IP-in-IP tunnelling.  IP nodes
	    which communicate from behind a NAT are reachable only through the
	    NAT's public address(es).  IP-in-IP tunnelling does not generally
	    contain enough information to permit unique translation from the
	    common public address(es) to the particular care-of address of a
	|   mobile node or foreign agent which resides behind the NAT; in
	|   particular there are no TCP/UDP port numbers available for a NAT to
	|   work with.  For this reason, IP-in-IP tunnels cannot in general pass
	|   through a NAT, and Mobile IP will not work across a NAT.

	    Mobile IP's Registration Request and Reply will on the other hand be
	    able to pass through NATs and NAPTs on the mobile node or foreign
	    agent side, as they are UDP datagrams originated from the inside of
	    the NAT or NAPT.  When passing out, they make the NAT set up an
	|   address/port mapping through which the Registration Reply will be
	    able to pass in to the correct recipient.  The current Mobile IP
	    protocol does however not permit a registration where the mobile
	    node's IP source address is not either the CoA, the Home Address, or
	    0.0.0.0.

7.
	An explicit list of the 3 different scenarios handled by the
    proposed mechanism was added to the problem description.

	|   This mechanism will address 3 different scenarios:
	|
	|      -  A mobile node with co-located address behind a NAT; no FA
	|
	|      -  A mobile node registered away with an FA which is behind a NAT
	|
	|      -  A mobile node with co-located address using an FA which demands
	|         that registrations pass through the FA (sets the "R" bit) where
	|         both the mobile node and the FA are behind a NAT
	|

8.
	The rationale for the client taking care to use the same UDP
    source port when re-registering as used the previous time was
    expanded in section 4.4

	|   When the mobile node re-registers without having moved, it SHOULD
	|   take care to use the same source port as was used for the original
	|   registration of the current mobility binding.  Otherwise, while the
	|   home agent would change destination port on acceptance of the new
	|   registration, and the mobile node would presumably start listening on
	|   the new port, the packets in flight from the home agent at the time
	|   of change will be dropped when arriving at the mobile node's old
	|   port.  (This does not mean that the home agent should refuse a
	|   registration request using MIP UDP tunnelling where a new port have
	|   been used, as this might be the result of the NAT dropping state, the
	|   mobile node re-booting, changing interface, etc.)

9.	
	The IPR notification section was rewritten to point to the
    online list of claimed rights.

10.
	An unsaf considerations section (based on
    draft-iab-unsaf-considerations-01) was requested by the IESG,
    written and included:

	|7. UNSAF Considerations
	|
	|   The mechanism described in this document is not an "UNilateral Self-
	|   Address Fixing" (UNSAF) mechanism.  Although the mobile node makes no
	|   attempt to determine or use the NAT translated address, the mobile
	|   node through the registration process does attempt to keep the NAT
	|   mapping alive through refresh messages.  This section attempts to
	|   address issues that may be raised through this usage through the
	|   framework of the unsaf considerations IAB document [14].
	|
	|      1.  Precise definition.
	|          This proposal extends the Mobile IP v4 registration process to
	|          work across intervening NATs.  The Home Agent detects the
	|          presence of the NAT by examining the source address in the
	|          packet header and comparing it with the address contained in
	|          the registration message.
	|
	|          The NAT address and port detected by the home agent are not
	|          exported or communicated to any other node anywhere.
	|
	|      2.  Exit strategy.
	|          This mechanism will go out of use as IPv6 and Mobile IP v6 is
	|          deployed, obviating the need for MIPv4 NAT traversal.
	|
	|          It can also be noted that this mechanism makes no changes to
	|          the base MIPv4 protocol which makes it dependent on the
	|          presence of NATs or the current extensions - i.e.  no
	|          additional protocol changes would be needed if NATs were to go
	|          away.
	|
	|      3.  Issues making systems more brittle.
	|          The specific issue which is relevant here is that the
	|          effective care-of address (being the source address in the IP
	|          header received by the HA) is not protected by the Mobile IP
	|          authentication extension, and therefore may be spoofed.  This
	|          is discussed in some detail in Section 6, Security
	|          Considerations.
	|
	|      4.  Requirements for longer term solutions.
	|          The trivial long term solution is a transition to an
	|          environment where NATs are not required.  The most obvious
	|          such environment would be an IPv6 based internet.
	|
	|          In the presence of NATs, an improved solution would require
	|
	|             *  the ability to discover the translations done by each
	|                NAT along the route
	|             *  the ability to validate the authority of each NAT to do
	|                those translations
	|
	|             *  communicating as part of the signed registration request
	|                the address of the NAT closest to the HA, for use as the
	|                effective care-of address from the viewpoint of the HA.
	|
	|             *  configuration of all intermediate NATs to accept only
	|                packets from the neighbour NATs.
	|
	|      5.  Impact on existing, deployed NATs.
	|          One precursor of the mechanism described here has been used
	|          successfully across deployed NATs in Sweden, Germany, England,
	|          Japan and the USA, without necessitating neither adjustments
	|          of the NATs in question, nor adjustment of any protocol
	|          parameters.  At the time of writing, little experience exist
	|          with the exact implementation proposed in this document, but
	|          effort has been put into making this mechanism even more
	|          robust and adaptive than its precursors.
	|
	|          With respect to the base Mobile IP specification, the impact
	|          of this document is that an increased frequency of
	|          registration requests is recommended from a security
	|          perspective when the NAT traversal mechanism is used.
	|

11.
	Clarification of language in section 4.5

	|   A foreign agent using MIP UDP tunnelling to a home agent because the
	|   FA is situated behind a NAT may be configured to encourage reverse
	    tunnelling, or be neutral about it, depending on the characteristics
	    of the NAT.  If the NAT translates all source addresses of outgoing

12.
	The semantics of the Reserved 3 field were unclear, and the
    handling of it unclear. This was clarified in section 3.1 and 3.1.1

	       Reserved 3          Reserved for future use.  MUST be set to 0 on
	|                          sending, MUST be verified as 0 on receipt;
	|                          otherwise the extension must be handled as not
	|                          understood and silently skipped.

    ...
	 3.1.3 Reserved Fields

	    The 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt,
	    while the 'Reserved 3' field must be 0 on receipt, otherwise this
	|   extension MUST be handled as not understood and silently skipped.
	|   This permits future additions to this extension to be made which
	|   either can co-exist with old implementations, or will force a
	|   rejection of the extension from an old implementation.

13.
	Section 4.2 incorrectly said that an AH might be inserted
    between outer IP header and UDP header. Corrected.

	    tunnel exit point.  No change to IP options in the inner header
	    occurs during delivery of the encapsulated datagram through the
	|   tunnel.  Note that the security options of the inner IP header MAY
	|   affect the choice of security options for the encapsulating (outer)
	|   IP header.

14.
	There was no mention in the decapsulation section 4.3 of the
    address verification the HA must do to make sure the outer address
    and ports are valid.

	|   Before decapsulation is actually done, the decapsulating node MUST
	|   verify that the outer IP addresses and UDP port numbers exactly match
	|   the values used for the tunnel, with the exception of tunnels that
	|   are "half bound" (as described in Section 4.11) where the source UDP
	|   port can change.
	|
	|   IP-in-UDP encapsulated traffic is decapsulated simply by stripping
	|   off the outer IP, UDP and MIP header, which leaves the original IP
	|   packet which is forwarded as is.

15.
	In section 4.5, an incorrect statement was made in para. 5 about
    the interface an FA should use to send udp-tunnelled packets to the
    ha. The last section of the para was removed.

16.
	The requirement on HA consistence in the last para of 4.6 was
    modified to say SHOULD instead of MUST. The examples were extended.

	|   The home agent SHOULD be consistent in acknowledging support for UDP
	    tunnelling or not.  A home agent which understands the UDP Tunnel
	    Request Extension and is prepared to respond positively to such a
	|   request SHOULD also respond with a UDP Tunnel Reply Extension
	    containing a declining reply code if use of MIP UDP tunnelling is not
	    indicated for a session.  The mobile node MUST NOT assume such
	    behaviour from the home agent, since the home agent may undergo a
	|   software change with reboot, a policy change or a replacement; and
	|   consequently a change of behaviour.

17.
	In 4.6.1, some of the error cases were very similar, and it was
    not clear how the home agent would distinguish between them.
    Language clarified:

	|   UDP Tunnel Request extension sent by the mobile node (placed before
	|   the MN-HA authentication extension), but 'D' bit in registration
	|   request header not set:

		  The home agent SHOULD send a Registration Reply with the Code
		  field set to 134, "poorly formed Request".

	|   UDP Tunnel Request extension sent by the foreign agent (placed after
	|   the MN-HA authentication extension), but 'D' bit is set:

		  The home agent SHOULD send a Registration Reply with the Code
		  field set to 134, "poorly formed Request".

	|   Reserved 3 field of UDP Tunnel Request extension is nonzero:

		  The home agent SHOULD send a Registration Reply with the Code
		  field set to 134, "poorly formed Request".

	    Encapsulation type requested in UDP Tunnel Request extension is
	|   unsupported:

		  The home agent SHOULD send a Registration Reply with the Code
		  field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel
		  encapsulation unavailable" defined in Section 3.5.

18.
	It had not been properly clarified who is responsible for
    sending the keepalives in all situation. It was clarified that it is
    the node at the remote udp tunnel endpoint who sends the keepalives
    in all cases.

19.
	It was pointed out that the security benefit of re-registering
    more often than necessary based on the registration lifetime is much
    smaller than originally thought. This led to removal of part of the
    security considerations (6.1.1, last half para), and opened up for
    not using registration requests for keepalive purposes.

20.
	Some clarifications were requested on the threats and handlings
    connnected with tunnels in 'half bound' state

	 6.1.2 Sending a Bogus Keepalive Message

	|   When registering through an FA using a co-located care-of address,
	|   another redirection vulnerability opens up.  Having exchanged
	|   Registration Request/Reply 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
	|   bound" state until the keepalive is received).
	|
	|   Having observed a Registration Request/Reply exchange, an attacker
	|   may send a bogus keepalive message assuming that the mobility binding
	|   is in the "half bound" 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 Registration Request/Reply 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 Registration
	|   Request 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
	|   Registration Request.

	    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 bound" state by having the mobile node send the first keepalive
	    message immediately after receiving an affirmative registration
	    reply.

21.
	The rationale for the new error code introduced in section 3.5
    was clarified:

	|   This is used by the HA to distinguish the registration denial caused
	|   by an unavailable UDP tunnel encapsulation mode from a denial caused
	|   by unavailable standard tunnel encapsulation requested by use of the
	|   'T' bit together with either 'M' or 'G' bit.
---