Subject: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port

From: "Sami Vaarala" <[email-masked]>
Date: Tue, 17 Jul 2001 09:15:29 +0300

Hi,

We just posted a draft for Mobile IP NAT traversal that is based
on reusing the Mobile IP signalling ports for data encapsulation.
We wanted to get this in for the next IETF to spark some discussion
on the subject.  The draft can be found in:

http://www.ietf.org/internet-drafts/draft-vaarala-mobileip-nat-traversal-00.
txt

The draft differs from the draft by Levkowetz et al in the following:

  - There is no separate UDP encapsulation port.  Using a separate
    port for data encapsulation has the following problems:

      1. It adds latency, since HA-to-MN traffic can only
         start flowing once the NAT mapping for the data encapsulation
         port has been established.

      2. Should the first keepalive message be lost, and should the
         MN have no data to send, the binding will be successful,
         but data cannot move until the NAT keepalive interval elapses
         and a new keepalive (hopefully successful) is sent.  Another
         way to recover is by the MN sending some data to the HA.

      3. Even though RREQ/RREP succeeds, there is no guarantee that the
         data port actually works.  Thus, there has to be some expensive
         (in time) trial-and-error method for finding a port that can be
         used.  Another alternative is manual configuration of acceptable
         ports for given access points.

    Using the same port for both data and MIP traffic solves these
    problems.  In particular, success of RREQ/RREP equates to success of
    data encapsulation, at least in practice.  Loss of either RREQ/RREP
    is handled using the ordinary retransmission scheme of Mobile IP.

  - The protocol allows the client to request tunnelling regardless of
    presence of NAT devices.  This is useful when dealing with firewalls
    (even in absence of NAT).

The draft attempts to avoid extra tunnelling overhead by exchanging
Mobile IP vs. IPv4 message markers.  The current version has two
methods, either the range 0x45...0x4f is reserved for tunnelling, or
a single Mobile IP message type marker is used (with one octet
overhead).  Another alternative would be to "shift" the range 0x45...0x4f
to a free range (eg 0x75...0x7f), and the communicating parties would
negotiate which ranges are free at each end.

Comments on the draft are most welcome,

-Sami

--
Sami Vaarala
Senior Software Architect
NetSeal Technologies

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 17 Jul 2001 12:03:43 +0200

Sami,

	I've just read your draft, with great interest, and find that
apart from the choice of tunnelling through the well-known port 434
instead of an arbitrary port, our drafts match very well. My intention
was actually to submit a draft for a general UDP tunnelling mechanism
for Mobile IP, providing for tunnelling through port 434, but time
caught up with me and I did not make it to the -00 draft cut-off date.

	The advantages of your method, which you list below, are quite
correctly represented, as far as I can see. However, the drawback to 
your method, which made us choose not to multiplex through 434 in a
vendor-specific solution, is that you effectively subsume the use of a 
(dynamically assignable) mobile-ip message number which has not been 
assigned for that use by IANA, in order to effect the data tunnelling 
through port 434. We did not feel that we could do this -- and for 
that reason, in part, we intended to write and propose a non-vendor 
specific solution where a new mobile-ip message is defined to carry 
the data traffic tunnelled through port 434.

	I wonder if there are more people interested in defining a non-
vendor specific solution for NAT traversal for Mobile IP v4?

	As for some other particulars described in your draft, I liked
the provision for a dynamic keepalive-interval. We had discussed the
use of a flag similar to your 'U' flag, too, although we left it out
of the vendor-specific solution.

	Best regards,
		Henrik Levkowetz

---

From: "Sami Vaarala" <[email-masked]>
Date: Tue, 17 Jul 2001 13:53:50 +0300

Henrik,

From: "Henrik Levkowetz" <[email-masked]>
>[...]

I agree that it is not very "polite" to carry data traffic using a
dynamically
assigned message type.  We decided that this approach would be OK mainly
because:
  * it is dynamical, and each host determines which message type(s) it can
    use for such purposes (thus eliminating conflicts between existing or
new
    IANA types)
  * no-one except MN and HA process such messages (eg no FAs are in the
route)
  * the data encapsulation is never used, unless both parties agree that
they
    support the mechanism (and the negotiation process is authenticated
    using Mobile IP authentication)

Furthermore, we strongly feel that a range of Mobile IP message types should
be used (instead of a separate marker octet) to multiplex traffic, in order
to avoid overhead (and also loss of packet alignment) caused by extra marker
octet(s).  Another approach with regards to standardization would be to
define a separate, standard UDP tunnelling port that would be well known
and thus hopefully likely to be passed thru along with 434 (at the cost of
added latency).

With regards to the -00 draft, an idea to add more flexibility to the
marker negotiation would be to remove the "non-optimized tunnelling"
in our draft, and instead negotiate which ranges of markers are available
at each end.  This would avoid the fixed 0x45...0x4f range in optimized
tunnelling, and at the same time remove the need for two separate methods
of tunnelling.

An even more flexible mechanism would be to specify the 11 marker octets
mapping to 0x45...0x4f, and not requiring that the markers be continuously
allocated from the Mobile IP message type space.

As an aside, how do people feel about TCP-based traversal?  With regards
to keepalives, such tunnelling could be more efficient, but is it worth
the extra trouble?  For one, the standard RREQ/RREP mechanism cannot be
used to negotiate the traversal, as with UDP-based traversal, eg in case
UDP is not passed to the home agent at all, but TCP is.

> vendor specific solution for NAT traversal for Mobile IP v4?

This is an interesting question;  we feel that Mobile IP NAT traversal
is increasingly important, and should not be too difficult to standardize
(eg in comparison to IPsec NAT traversal).  Hopefully there will be enough
discussion before and during IETF 51.

Best regards,

-Sami

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 17 Jul 2001 15:59:09 +0200

Sami,

On the dynamically assigned message type:

Although we have chosen not to use such to tunnel trough 434, I to
some extent agree with what you write on this, however: If you deploy a
number of HA's & clients worldwide, using this solution, and some of
the MIP message numbers which are now unassigned become assigned for
standardised messages, you are in a situation where all of your HA's
and clients will need to be reconfigured to not use those message
numbers -- and if your company is successful in selling this solution,
that could be a lot of HA's and clients!  There's always a chance then,
that some customer would miss or ignore the reconfiguration. 

I don't think you should assume that only your own clients will be used
with your HA's, or only your own HA's will be used to support your
clients -- and if other vendors' products with new message types were to
conflict with your tunneling solution because a reconfiguration had
been missed, it would be quite unfortunate.

In theory, you should still never get a conflict if you take care to
treat these message types as tunneling only after negotiation, and
as unrecognised messages otherwise, but it's balancing a little too
close to the edge for my liking...  :-)
(Remember Murphy.)

It would also be unfortunate if the IANA felt that due to the existence
in the marketplace of a solution which had subsumed the use of message
types 0x45..0x4f, those could not be used for new Mobile IP messages
types, and had to be barred.

On TCP-based traversal:

I think that there would be added complexity and overhead, without
proportionately added benefit. If the protocol being carried in the
tunnel also was TCP, I think you might get complex interactions
between the two levels of TCP timers, resends and whatnot?
We chose to go with UDP because IP-in-UDP behaviour is very close 
to IP-in-IP or bare IP. I'm sure you have made the same reflexions.

On standardised NAT-traversal:

Yes. And I'm slightly surprised at the scarcity of comments, so far.
Of course, this subject isn't as sexy as MIPv6 or Fast Handover :-)

	Best regards,
		Henrik

Sami Vaarala wrote:
>     use for such purposes (thus eliminating conflicts between existing or new
>     IANA types)
>   * no-one except MN and HA process such messages (eg no FAs are in the route)
>   * the data encapsulation is never used, unless both parties agree that they

---

From: "Sami Vaarala" <[email-masked]>
Date: Wed, 18 Jul 2001 10:44:48 +0300

Henrik,

(Long posting, sorry...)

> that some customer would miss or ignore the reconfiguration.

We seem to disagree on this point, and I'll try to break down the issue
to see where exactly we disagree.  Basically I am trying to convince you
that no reconfiguration is necessary -- unless a software update is done
to add support for new message types anyway.

1.  I have assumed that it is okay to diverge into a non-conformant
mode if support for the traversal feature is mutually established in an
authenticated manner.

2.  Both the mobile node and the home agent can independently
determine which mobile IP message type(s) they are willing to reserve
for tunnelling purposes.  If the node supports an IANA assigned
message type X, it MUST NOT indicate that such a number would be
acceptable for traversal purposes.  Both the MN and the HA
independently define which message type(s) they are willing to
accept when _receiving_ tunnelled packets, so difference of implemented
message types is not a problem.

3.  Only the MN and the HA need to understand these packets.  There
are no third party conflicts, unless you consider hosts such as network
sniffers as such.  (True, it would be irritating to see network packets
incorrectly dumped, but I don't consider this a major problem :)

4.  Now, suppose that MN and HA are both supporting the traversal mechanism
AND that they are independently administrated.  Supposed now that a new
IANA message type X is defined, and the HA (but not the MN) is upgraded to
support the message type.

4a. After the software update the HA would no longer indicate that message
type X would be valid for traversal.  Thus MN->HA traffic would cause no
conflicts, even if MN is not updated (since MN will obey the traversal
requirements indicated by the HA).

4b.  HA->MN traffic would also work.  If MN would happen to indicate that X
is used as a traversal marker, the HA would determine that MN _does not_
support X anyway, and would refrain from sending the actual message type X
to the MN (since it would never process it anyway).

Should the HA send X to MN prior to establishing a traversal binding, the
MN would respond normally, as if an unsupported message type was received.

5.  MN upgraded, HA not -> similar to case 4.

6.  One host is upgraded and rebooted while an existing binding is still
valid.  This causes a small period of time during which the other host
may be sending traversal processed packets that might conflict with the
rebooted host.  However, by using short lifetimes for traversal bindings
(eg one minute), this would be a minor concern.

----

The point I am trying to make is that message type changes require a
_software update_ anyway, and the software can be updated at the same time
to not use conflicting traversal markers.

Point 4b) will have to be elaborated in the draft, since it is important
with regards to software upgrades.  The described approach is not very
clean since it interacts with the rest of the Mobile IP implementation.
Any ideas on how to make it cleaner?

> been missed, it would be quite unfortunate.

I don't see how this could happen?  The following cases arise:

1.  Neither supports the draft -- no problem here.

2.  MN supports, HA doesn't -- NVSE ignored.

3.  MN does not support, HA does -- NVSE not sent, no problem.

4.  Both support, but disagree on which message types are okay for
    traversal -- no problem, since traversal for each direction is
    negotiated separately.

Have I missed something here that you are concerned about?

> close to the edge for my liking...  :-)

There are conflicts if one assumes that messages before and after
establishing a traversal binding are confused, that is true.
However, one could also argue that the MN might confuse GRE tunneling
with minimal encapsulation, or co-located address with using an FA.
Is there a fundamental difference between these different types of
confusion?

Since the traversal parameters and state are a part of the binding
state, which has to be carefully maintained anyway, I don't see a
problem with the confusion -- the traversal state would be bound to
the same data structures as eg. GRE vs. minimal encapsulation mode.

> types, and had to be barred.

I agree.  This is why I think that both hosts should indicate which
marker octets they are willing to use for optimized traversal as well,
ie by indicating the range or the individual octets supported.

Of course, it would be best if there was a consensus that MIPv4 NAT
traversal is important, and marker octets were assigned by IANA;  then
there would be no possibility for confusion, and no need for
negotiation of markers.

> to IP-in-IP or bare IP. I'm sure you have made the same reflexions.

I agree completely;  the advantages do not seem to be worth the
hassle.  UDP tunnelling can be thought of as a new kind of mobility
binding, while TCP tunnelling requires much larger changes to the
protocol model.

> Of course, this subject isn't as sexy as MIPv6 or Fast Handover :-)

It is amazing though, because NAT traversal is a _major_ deployment
requirement.  Does this indicate that people are not deploying? ;-)

Best regards,
-Sami

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 18 Jul 2001 11:56:23 +0200

Sami,

	Yes, I see that the scheme is well-thought out. I hadn't fully
appreciated the benefits of both sides indicating which MIP message
type they are willing to receive as a data tunnelling marker.

	To me, it appears as if your scheme will work, too, and will not
interfere with other traffic, or cause trouble, except for e.g. 
tcpdump :-).  

	(I still don't really like the approach of using unallocated
message types, though, but now we are down to the esoterics of estethics
in software design...)

	There's also the factor of complexity vs. simplicity - your 
scheme in itself is not very complex, but simpler would be better. Having
a standardised MIP message type for this use would be simpler.

	There is one implementation aspect to this which we haven't touched
on, where I believe our solution is slightly simpler/better than yours,
which is the following: Using other ports than 434, we don't have to
multiplex MIP control and data, so detunneling can be implemented as a
pure kernel activity, while in your case, the packets would have to be
looked at by the mip daemon or equivalent, to separate the control and
data streams. This drawback would exist equally for a standardised
solution using port 434 and a standardised MIP message type, too.
Alternatively, one could standardise a separate port for MIP UDP tunnelling.

	As I indicated earlier, I'd intended to submit a draft for a
non-vendor-specific UDP tunneling extension to MIPv4, would you be
interested in co-authoring such a draft? It seems as if we wouldn't have
trouble coming up with two independent implementations of such a draft,
to take it towards standard :-) ? 

	On the volume of comments: Yes... the thought has passed my mind,
_are_ people deploying MIP at all?  Or is it that the deployments being
done are only in the US by holders of large blocks of public IPv4 
addresses?

	Best regards,
		Henrik

---

From: "Sami Vaarala" <[email-masked]>
Date: Wed, 18 Jul 2001 13:37:29 +0300

Henrik,

From: "Henrik Levkowetz" <[email-masked]>
> a standardised MIP message type for this use would be simpler.

True;  or a range of standard MIP message types to avoid overhead.
I don't know how you feel about it, but in my opinion the single octet
overhead is quite annoying.  Breaking the four-octet alignment that
naturally would exist might be a pain in some processors that
naturally process aligned data.  Adding overhead to four octets
would help that issue but seems like much extra for little gain.
(Incidentally, IPsec NAT traversal requires either 8 or 12 bytes
overhead for markers.)

> solution using port 434 and a standardised MIP message type, too.

I agree with this.  Our Mobile IP implementation is kernel-based so there
is no such problem, but I agree, this would limit implementation options
and cause problems with some existing ones.  A standard Mobile IP message
type (or range) would allow the kernel part to automatically demux
traffic, and would not need any configurable parameters as is the case
with a negotiable traversal.

> Alternatively, one could standardise a separate port for MIP UDP
tunnelling.

Yes.  We need rough consensus on at least the following issues to start
things moving:
   1. Do we allocate a separate port?  If so, what will we do if 434 is
      allowed but the port in question is not (universal deployment does
      not happen overnight) -- do we still need a port negotiation?

   2. If we go for tunnelling through port 434, do we use a set of
      markers and optimize overhead, or use a single marker to separate
      traffic.  Is it realistic for IANA to allocate a range of numbers
      for this application?  Or a range for numbers for private use
      among consenting parties (and a standardized extension for
      traversal negotiation).

I think we should have discussion over this at IETF 51 to get things
forward.

> to take it towards standard :-) ?

Yes, that sounds good, we would be interested in implementing such a
proposal.  Of course, we will have to reach some consensus on how to
go forward with the various approaches.

Best regards,
-Sami

Sami Vaarala

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 18 Jul 2001 13:40:02 +0200

Sami,

> (Incidentally, IPsec NAT traversal requires either 8 or 12 bytes

Althought maybe not the absolutely most optimal solution, I'd be most
happy with a standardised message type, starting with one-octet type
and length, and then a reserved two-octet field, to make 4 octets.
The overhead is not that horrendous, I think. Just type and length,
for a 16-bit alignment would be fairly ok, too.

>       not happen overnight) -- do we still need a port negotiation?

For a general solution, my thinking at this moment is to go for primarily
a separate port, with fallback to 434 with a new message type permitted.

>       among consenting parties (and a standardized extension for

I'd think that IANA would want to conserve their resources, so to speak,
and allocate one message type for tunnelling. This would be Ok for us, too.

> I think we should have discussion over this at IETF 51 to get things

Yes, absolutely. I'll be there the whole week, we definitely should get
together.

> go forward with the various approaches.

Certainly.

	Best,
		Henrik

---

From: Hans Sjöstrand <[email-masked]>
Date: Thu, 19 Jul 2001 00:12:27 +0200

> a separate port, with fallback to 434 with a new message type permitted.

Agree, I strongly think that a separate port should be used (and registered
by IANA), mandating 434 is higly dangerous.

Higher capacity routers _must_ handle the user plane in hardware, no
compromise possible there. Forwarding user plane traffic of probably Gb/s of
traffic to the slow path will for sure whack over any router on the market.
The UDP tunnel must therefore be separated from the mip control plane , this
has to be done already in HW. Since addressing can't be used, (the tunnel is
decapsulated in the router) port numbers are whats left. Requiring
the routers to look even further into the packets for markers are
not viable in my mind, not with todays ASICs etc. The solution must be
implementable on todays router plattforms.

There is also the case where the HA is only acting as a signalling proxy,
then the user traffic should be switched to another router. You don't
want that traffic up to the signalling proxy.

But, as you point out, change is gradual. Port "negotiating" (more of a
handshake really as proposed) is therefore a good thing to get through
conservative firewalls.

Regards
/// Hasse

---

From: "Sami Vaarala" <[email-masked]>
Date: Thu, 19 Jul 2001 10:54:00 +0300

Hans,

From: "Hans Sjöstrand" <[email-masked]>
> by IANA), mandating 434 is higly dangerous.

Do you mean that it is dangerous as a protocol design feature, or
dangerous to existing specifications and/or implementations?

> traffic to the slow path will for sure whack over any router on the
market.

I agree.

> implementable on todays router plattforms.

This is true as far as existing, hardware based HAs are concerned.  However,
not all HAs are hardware-based, and I think it is not good to add extra
latency and the associated UDP port decision problems (which traversal
port will work thru this set of random, third party routers) to all HAs
(software or hardware) only because some existing implementations might
not be able to support a traversal mode based on using port 434.

Since mobile nodes are practically always modifiable (ie software), we
could define a protocol that allowed the HA to decide which traversal method
(434 or other) is used.  This would allow "modifiable" HAs to use the port
434,
which provides faster handovers and more predictable traversal behavior,
while existing hardware-based implementations that cannot perform
multiplexing
beyond address/protocol/port could use a separate port.  The MNs would have
to support both, but this does not seem to be a major issue.

This is indeed what Henrik suggested.  The protocol would then go something
like this:
    1. MN indicates support for traversal, and MAY
        a. Request that traversal be used regardless of NAT existence
        b. Indicate which port it would like to use, if possible.
           Port 434 would indicate that a (standardized) marker is used,
           and another port would indicate direct tunnelling.

    2. HA performs NAT detection (and takes the 1.a. flag into account)
       and assigns a traversal port if it determines traversal is needed.
       Port number semantics the same as in 1.

       The HA could also assign a keepalive interval.

    3. Data tunnelling begins.

This would combine the features of both drafts, and would support both types
of HAs.  HAs would only have to support a given NAT traversal method or
port.

There is still the issue of lost keepalive packet in case of non-434
traversal,
in which case the NAT mapping is not formed.  If the MN has no data to send,
HA-to-MN data will not flow, until the MN resends the keepalive (which can
be
long), or until actual data is sent.

How about the following:
    - If the HA does not receive a keepalive/data packet to the assigned
port,
      it sends a Mobile IP message that requests resend of a keepalive
packet.

    - This packet would use the same message type that is used for
tunnelling,
      we would have a special flag for "keepalive request".

The HA would set a short timer for the initial keepalive (eg 3 seconds).
Upon expiration, it would send a keepalive request, and keep resending for
a number of times, until the first keepalive (or data packet) has been
received.  After that, the server never sends the keepalive request.

The loss of a keepalive request causes a resend of such a request, and
should
not cause arbitrarily long traffic blackholes.  The keepalive request would
only
be used in case of non-434 port.  It should be implementable in hardware,
because
you would only catch packets the to the data tunnelling port until you got
the
first packet (which confirms to some extent that the NAT mapping was formed)
and
then stop catching the packets.

How does this sound?

Best regards,
-Sami