Subject: [Mobike] Issue: NAT-T interaction (#3)

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Jun 2004 18:20:16 +0300

This is about the interaction with NAT traversal:
does the MOBIKE protocol work one one party goes behind NAT,
comes from behind NAT, or goes from one NAT to another?
There was a lot of discussion about this at Seoul, so it
is clearly an issue of concern to many people. Is limiting
our protocol to only working if there is no NAT might be
too restrictive because most users don't know when they
are behind a NAT, or are about to move to behind a NAT?

Or should MOBIKE and NAT-T be seen as alternative
solutions; if you enable NAT-T then you use just
that and live with its limitations & if you use
MOBIKE then you don't have a NAT?

In Seoul it seemed that the WG wanted MOBIKE and
NAT-T to work together. If so, would testing for
NATs occur after each address change?

[Reminder: our charter says we shall not replace
or modify NAT traversal, and that we should not
integrate the protocol tightly with NAT traversal.
However, we need to document how (and when) they
work together.]

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 18:20:20 +0200

In your previous mail you wrote:

=> please note there is far more than one question in this statement!

The first one is "one party goes behind NAT": IMHO this is more
an IKEv2 question and the IPsec WG already decided to not support
directly this case, i.e., the IKE SA is broken and everything restart
from the beginning.
MOBIKE is like IKEv2: peer address "floating" is accepted only from
a peer known to be behind a NAT, so there is no detection issue
and we can go to the last case.

The last one is "one party goes from one NAT to another": IMHO
we should not try to handle this case and leave it to NAT-T itself.
The real question is whether is one party using NAT-T (and behind
a NAT) with the other party using MOBIKE a real world case?
Without a concrete example of such a situation I propose to not
require the support of this case.

The second one is "one party comes from behind NAT": IMHO this is
more a NAT-T issue and the real question is the opposite of
the first one: NAT-T to no-NAT-T transition.
The simplest answer is just to keep the NAT-T mode but there is
a bidding down attack on this (bidding down because NAT-T has a
larger overhead and provides less security than "plain" IPsec).
My proposal is to accept this possible attack but to require
a per peer configuration switch which enables or disables NAT-T
(note this is a different switch than NAT-T support itself. for
instance NAT detection can (should!) be performed even when the
switch is on "disabled").

Regards

[email-masked]