Subject: [mobile-ip] Feedback on mipv4 nat traversal draft: major issues

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

Major issues with 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 major 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).

Minor changes are being posted separately.

	Henrik

---

Major issues:

1.
	It was felt that the default time between keepalives (20 seconds) was
    extremely short, and in view of one of the reasons for a short time proving
    false (it is the full registration time, not the time between re-registrations,
    which limit the time a redirection attack works without repeated intervention),
    the default time between keepalives has therefore been adjusted from 20 seconds
    to 110 seconds in section 4.9. This should also to some extent
    alleviate the performance concerns described under issue 3 below. 

	    For each mobility binding which has UDP tunnelling established, the
	|   non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive
	|   packet if no other packet to the HA has been sent in K seconds.  Here
	|   K is a parameter with a default value of 110 seconds.  K may be set
	|   to another value by the HA as described in the UDP tunnelling reply
	|   extension (Section 3.2).

2.
	It was suggested that the keepalive function and the re-registration
    function should be fully separate. The keepalive function and 
    re-registration has thus been separated, removing the use of 
    registration requests for keepalive urposes. This led to changes throughout 
    the draft, including the removal of the 'E' bit in the udp tunnel reply 
    extension. The major changes were in section 4.9 on keepalives, which 
    became simpler and shorter:

	 4.9 Tunnel Keepalive

	    As the existence of the bi-directional UDP tunnel through the NAT is
	    dependent on the NAT keeping state information associated with a
	    session, as described in RFC 2663 [12], and as the NAT may decide
	    that the session has terminated after a certain time, keepalive
	    messages may be needed to keep the tunnel open.  The keepalives
	    should be sent more often than the timeout value used by the NAT.
	    This timeout may be assumed to be a couple of minutes, according to
	    RFC 2663 [12], but it is conceivable that shorter timeouts may exist
	    in some NATs.

	    For this reason the extension used to set up the UDP tunnel has the
	    option of setting the keepalive message interval to another value
	    than the default value, see Section 3.2.

	|   The keepalive message sent MUST consist of a properly UDP
	|   encapsulated ICMP echo request directed to the home agent.

	    For each mobility binding which has UDP tunnelling established, the
	|   non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive
	|   packet if no other packet to the HA has been sent in K seconds.  Here
	|   K is a parameter with a default value of 110 seconds.  K may be set
	|   to another value by the HA as described in the UDP tunnelling reply
	|   extension (Section 3.2).

	|   Except for the case where the mobile node registers with a co-located
	|   address through an FA (see Section 4.11) MIP UDP tunnelling is done
	    using the same ports that have already been used for the registration
	|   request / reply exchange.  The MN or FA will send its first keepalive
	    message at the earliest K seconds after the registration request was
	|   sent.  The same UDP source port MUST be used for the keepalive
	|   messages as was used for the original Registration Messages and for
	|   data messages.
	|
	|   The remote UDP tunnel endpoint MUST use two-way keepalives consisting
	|   of UDP encapsulated ICMP Echo Request/Reply messages.  The rationale
	|   for using two-way keepalives is two-fold:
	|
	|      1.  Two-way keepalives allow the mobile node to detect loss of a
	|          NAT mapping.  Detection of NAT mapping loss in turn allows the
	|          MN to compensate by re-registering and using a shorter
	|          keepalive to avoid loss of NAT mappings in the future.
	|
	|      2.  One-way keepalives actually cause more keepalive traffic
	|          overhead; the keepalive messages have to be sent more
	|          frequently to compensate for occasional loss of keepalive
	|          messages.  In contrast, two-way keepalives are acknowledged,
	|          and retransmissions occur only when a response is not received
	|          for a keepalive request within a reasonable time.
	|

3.
	One suggestion which has been made by Madhavi Chandra during the
    IESG last call, but not accepted into the draft, is to permit
    one-way keepalives. The reason for requireing two-way keepalives,
    and the actions to be taken by the mobile when an expected response
    is missing has been described in more detail in section 4.9 and 4.10

	|   The remote UDP tunnel endpoint MUST use two-way keepalives consisting
	|   of UDP encapsulated ICMP Echo Request/Reply messages.  The rationale
	|   for using two-way keepalives is two-fold:
	|
	|      1.  Two-way keepalives allow the mobile node to detect loss of a
	|          NAT mapping.  Detection of NAT mapping loss in turn allows the
	|          MN to compensate by re-registering and using a shorter
	|          keepalive to avoid loss of NAT mappings in the future.
	|
	|      2.  One-way keepalives actually cause more keepalive traffic
	|          overhead; the keepalive messages have to be sent more
	|          frequently to compensate for occasional loss of keepalive
	|          messages.  In contrast, two-way keepalives are acknowledged,
	|          and retransmissions occur only when a response is not received
	|          for a keepalive request within a reasonable time.
	|
	|4.10 Detecting and compensating for loss of NAT mapping
	|
	|   When a mobile node is using UDP encapsulated ICMP Echo Request/Reply
	|   messages as keepalives, it will have to deal with the possibility
	|   that a NAT mapping is lost by a NAT device.  The crucial thing here
	|   is of course not the loss of the NAT mapping in itself; but rather
	|   that the home agent, in the absence of a Registration Request through
	|   the new mapping, will continue to send traffic to the NAT port
	|   associated with the old mapping.
	|
	|   If the mobile node does not get a reply to its UDP encapsulated ICMP
	|   Echo Request even after a number of retransmissions, and is still
	|   connected to the same router that was used to establish the current
	|   mobility binding, the mobile node SHOULD re-register with the home
	|   agent by sending an Registration Request.  This lets the HA know
	|   about the new NAT mapping and restores connectivity between mobile
	|   node and home agent.
	|
	|   Having established a new mobility binding, the mobile node MAY use a
	|   shorter keepalive interval than before the NAT mapping was lost; in
	|   particular, the mobile node MAY deviate from the keepalive interval
	|   assigned by the home agent.  If the binding loss continues to occur,
	|   the mobile node may shorten the keepalive interval each time it re-
	|   registers, in order to end up with a keepalive interval that is
	|   sufficient to keep the NAT mapping alive.  The strategy used to
	|   arrive at a keepalive interval when a NAT mapping is lost is
	|   implementation dependent.  However, the mobile node MUST NOT use a
	|   keepalive less than 10 seconds.
	|
	|   Note that the above discussion only applies when the mobile node is
	|   re-registering through the same router, and thus presumably through
	|   the same NAT device that lost a NAT mapping earlier.  If the MN moves
	|   and still finds itself behind a NAT, it SHOULD return to its original
	|   keepalive interval (the default value, or as assigned by the home
	|   agent) and it SHOULD NOT do any keepalive interval compensation
	|   unless it discovers a loss of NAT mapping in the new environment.
	|
	|   The home agent MUST NOT attempt to detect or compensate for NAT
	|   binding loss by dynamically changing the keepalive interval assigned
	|   in the Registration Reply; the home agent does not have enough
	|   information to do this reliably and should thus not do it at all.
	|   The mobile node is in a much better position to determine when a NAT
	|   mapping has actually been lost.  Note also that a MN is allowed to
	|   let a NAT mapping expire if the MN no longer needs connectivity.
	|
	|   The discussion above does only in a limited sense apply to a foreign
	|   agent which is situated behind a NAT and using MIP UDP tunnelling.
	|   In this case, it is a matter of permanently configuring the FA to use
	|   a keepalive interval which is lower than the NAT mapping lifetime,
	|   rather than trying to dynamically adapt to the binding lifetimes of
	|   different NATs.

---