Subject: [NSIS] NATFW and multihoming

From: Matthias Friedrich <[email-masked]>
Date: Thu, 4 May 2006 09:49:38 +0200

Hi,

I've got a question about section 2.8 of the NATFW draft ("Multihomed
Network with NAT").

According to the text, "NATFW NSLP must be able to handle this situation
properly", however the referenced section 3.8.2 only specifies the
REA mechanism. The case where the NAT on the data and signaling path
disappears is not covered. The end hosts could still communicate using
the other NAT in theory, but of course the IP address changes and the
state on the original NAT is lost.

I realize that there is no simple solution, it would require creating
new state and modifying existing state on the path (which includes
creating new bindings on the remaining NAT). The application data flow
has to be redirected, too, which isn't trivial.

Is this scenario out of scope or are there plans to support it in NATFW?

The draft at [1] also lists this as an open question (section 3.2.4(4)).

Thanks,
	Matthias

[1] http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-04.txt

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 4 May 2006 17:26:12 +0200

Hi Matthias,

> state on the original NAT is lost.

There is no straight forward solution for the case where the DR is  
behind NATs
and the NAT goes down. This is due to the properties of NATs.

> Is this scenario out of scope or are there plans to support it in  

There is need no easy solution, which is due to the NAT itself.

However, for a data sender behind a NAT (as in Section 2.8) the  
unavailable
NAT will result in a route change (given that there is routing).
The route change behaviour is described in Section 3.10.

A data receiver behind a NAT has several mean to detect the
unavailable NAT:
a) No data yet, but reserved state from the REA exchange
b) Data flow is running

In a), the REA refresh messages will be re-routed (given that there
is routing) to another NAT and the DR will receive a new public IP
address. This needs to communicate to the other peers of DR.

In b), the DR would need to monitor the data flow and the signaling
message exchange (there have to be refresh messages). It can
be an indication of a failed NAT, if both, data and signaling, and  
not alive
anymore (also it can indicate other problems, either at the DS side or
somewhere else on the way).

The DR needs to send a REA message, either reusing old state
(i.e., sending a refresh REA) or setting up a complete new
session. In  any case, the DR will be receiving a new IP address
and port number and this needs to told other peers.

   Martin

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 04 May 2006 22:36:28 +0200

Hi Matthias,

let me also respond to you.

Matthias Friedrich wrote:
> disappears is not covered.
 > The end hosts could still communicate using

Let us look at the picture and assume that  MB1 and MB2 are NATs and the 
network is multi-homed.

              +----+
    DR -------|MB1 |\
        \     +----+ \  //---\\
         \            -|       |-- DS
          \             \\---//
           \  +----+       |
            --|MB2 |-------+
              +----+

         private          public

The initial REA allocated a NAT binding at MB1. Now, MB1 goes down.

The main question now depends on how data traffic is routed. If the REA 
routing changes and travels through MB2 then everything will be fine 
again at the next refresh interval. The REA will hit MB2 and will create 
a new NAT binding.

If traffic sent by the DR travels to MB1 (which does not work anymore) 
then both data traffic and NSIS signaling traffic will disappear.

What do you think?

Ciao
Hannes

---

From: Matthias Friedrich <[email-masked]>
Date: Fri, 5 May 2006 15:09:11 +0200

Hi,

thanks for the answer, more questions below.

> Matthias Friedrich wrote:

[...]

> again at the next refresh interval. The REA will hit MB2 and will create 

OK, so the DR sends REAs regularly to keep the NAT binding alive, as
per section 3.8.3. From reading [1] I got the impression that CREATE
(or rather RESPONSE?) could also keep the NAT binding alive. See their
section 8, state SESSION, which doesn't send refresh REAs.

> What do you think?

This means the DR has to check all RESPONSEs to its REA messages and
if the external address has changed, it has to tell the DS the new
address via some signaling mechanism (as Martin wrote in his reply).
One way would be to use the application level signaling if that's still
available. The other would be to send an NATFW NOTIFY to the DS which
contains the new external address.

For the latter method, an optional "Data Terminal Information Object"
would have to be added to NOTIFY. Do you think the use case is important
enough to justify this change?

Even if the NOTIFY is modified, it's not guaranteed that the DS can
redirect the data traffic. For example, it's not easily possible to
change the destination address of a TCP session on the fly.

Thanks for your answers,
	Matthias

[1] http://www.ietf.org/internet-drafts/draft-werner-nsis-natfw-nslp-statemachine-02.txt