Subject: RE: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP

From: Schruefer Wolfgang <[email-masked]>
Date: Thu, 17 Feb 2005 13:48:03 -0800 (PST)

Randy,

Randall Stewart wrote:
> 
> Spencer:
> 
> That is why I wondered about Wolfgang's proposal.
> 
> You need seperate NAPT's on seperate boxes... to
> get diversity and no single point of failure..
> 
> You won't get that with Wolfgang's picture...

Sorry, the picture was misleading, I just wanted to make it as easy a possible 
...
Please see the NAPT as a cloud with random Address and Port translations, not 
as a single box.

> 
> And then the only way I can think of is to either
> a) have a nat-2-nat protocol... talk about way ugly
> 
> or
> 
> b) have a way to have SCTP use different ports.. which
>     is not allowed by the spec (and rightly so in my mind). Changing
>     it, especially since 99.9 % of all napt's know nothing about
>     SCTP yet, is like having the tail wag the dog... IMO. You don't
>     design a transport protocol FOR NAT's...

By this argumentation You'll have a dog biting its tail ... NATs would not 
implement SCTP because SCTP does not support NAT ... SCTP would not support NAT 
because NATs do not support SCTP ... 

> 
> So.. not sure of a multi-homing solution for SCTP and NAT. Singly
> homed will work just fine (as long as napt's will implement it).
> 

Please let me summarize your words:

We have 3 Options:

a) nat-2-nat protocol: (... ugly ...)
b) bring SCTP to use different ports  (... not needed...)
c) forget NAT usage for SCTP ...

If everybody shares your opinion I think we can close the discussion.
I personally do not agree, I would continue with option b) ...

Best regards,
Wolfgang

> R
> 
> Spencer Dawkins wrote:
> > Randall,
> > 
> > Thanks for popping in here.
> > 
> > My concern is about "multihoming solutions" that would require two 
> > different IP interfaces (chosen for diversity) to point 
> traffic to the 
> > same NATP box (so it can assign the same outgoing 
> translation port to 
> > both interfaces).
> > 
> > It seems to me that inserting a single point of failure, 
> regardless of 
> > its reliability, into a multihoming solution isn't quite 
> solving the 
> > right problem.
> > 
> > If I chose two interfaces that home through two different 
> ISPs, traffic 
> > to two ISPs would have to traverse the same NATP in order 
> to pull this 
> > off (or we could insert a NATP-to-NATP protocol that would keep 
> > translation ports synchronized, but...).
> > 
> > Thank you for pointing out the "don't heartbeat to both IP 
> addresses" 
> > problem. I hadn't thought of that.
> > 
> > I agree that things are getting ugly fast. I'm not sure 
> everyone has the 
> > same definition of "ugly" in this thread.
> > 
> > Spencer
> > 
> >>
> >> Now, the problem here is that of ports... which is
> >> why you are asking for SCTP to have multiple ports.
> >>
> >> And I would argue that if your NAPT's is written to
> >> handle two interfaces, it could also assign the same outgoing
> >> translation port to both interfaces (if it knew that
> >> the SCTP endpoint was multi-homed by looking
> >> inside the INIT/INIT-ACK). Of course it would
> >> then have to do some method to use both networks. I.e.
> >> how would it decide to fail over.. it can't know
> >> what the end's are doing.. and of course the
> >> multi-homed nature would be hidden from the
> >> peer Host-Z which would mean it would not
> >> know to HB a seperate address.
> >>
> >> This gets ugly fast...
> >>
> >> If the base protocol had seperate ports allowed.. you might
> >> be able to do it... but that is a major change to the
> >> protocol..
> >>
> >> R 
> > 
> > 
> > 
> > _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > 
> 
> 
> -- 
> Randall Stewart
> ITD
> 803-345-0369 <or> 815-342-5222
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Feb 2005 14:04:29 -0800 (PST)

On Thursday, February 17, 2005, at 04:47 PM, Schruefer Wolfgang wrote:
We have 3 Options:

a) nat-2-nat protocol: (... ugly ...)
b) bring SCTP to use different ports  (... not needed...)
c) forget NAT usage for SCTP ...
a and b solve two completely different problems.  If SCTP is to
traverse NATs, both of those problems would need to be solved.
I have a strong preference for c, at least in the multihomed case.
Melinda

---

From: Randall Stewart <[email-masked]>
Date: Thu, 17 Feb 2005 14:21:20 -0800 (PST)

Schruefer Wolfgang wrote:
Randy,

Randall Stewart wrote:

Spencer:

You need seperate NAPT's on seperate boxes... to get diversity and
no single point of failure..
You won't get that with Wolfgang's picture...

Sorry, the picture was misleading, I just wanted to make it as easy a
possible ... Please see the NAPT as a cloud with random Address and
Port translations, not as a single box.
If you have two random NAPT's scattered amongst the cloud
somewhere.. .then how would you ever coordinate the heartbeating?
If you have two seperate IP addresses on the NAT's then
you have a problem with only one side will get the INIT
(or INIT-ACK) to populate the state.. and, since SCTP only
knows about its internal private addresses thats all it
can list in its INIT... And right now we specifically tests
at inter-ops that SCTP endpoints DON'T do this so they can
get through NAT's singly homed.
So... you would then need NAT'a KNOWING that NAT'b was
at a different address... and knowing its address and then
somehow talking to it to get state set in.. once you have
the two NATs talking I think it should be no problem to
coordinate what ports are handed out.. and then.. tada
SCTP works as is through a NAT.. we just need to get the above
fixed in SCTP implementations.. i.e. go ahead and list
your private addresses...

And then the only way I can think of is to either a) have a
nat-2-nat protocol... talk about way ugly
or

b) have a way to have SCTP use different ports.. which is not
allowed by the spec (and rightly so in my mind). Changing it,
especially since 99.9 % of all napt's know nothing about SCTP yet,
is like having the tail wag the dog... IMO. You don't design a
transport protocol FOR NAT's...

By this argumentation You'll have a dog biting its tail ... NATs
would not implement SCTP because SCTP does not support NAT ... SCTP
would not support NAT because NATs do not support SCTP ...

A Nat can support SCTP the same way it supports TCP.. aka
singly homed. There is no problem with this at all.

We have 3 Options:

a) nat-2-nat protocol: (... ugly ...) b) bring SCTP to use different
ports  (... not needed...) c) forget NAT usage for SCTP ...
No..

Lets first GET NAT's working with singly homed SCTP. Thats the
FIRST step.. there are problems to address in that (I know
from experience) world...
Then, the next step is to try to get M-Homed working in some way.. and
that MAY take an ugly NAT-2-NAT protocol.
We don't go re-design the base spec to fit NAT's.. What we
do is get NAT's working for the general case (singly homed) then
we can discuss the more complex area .. which by the way .. will
have less demand.
R

Best regards, Wolfgang

R

Spencer Dawkins wrote:

Randall,

My concern is about "multihoming solutions" that would require
two different IP interfaces (chosen for diversity) to point
traffic to the

both interfaces).

right problem.

Spencer

Now, the problem here is that of ports... which is why you are
asking for SCTP to have multiple ports.
And I would argue that if your NAPT's is written to handle two
interfaces, it could also assign the same outgoing translation
port to both interfaces (if it knew that the SCTP endpoint was
multi-homed by looking inside the INIT/INIT-ACK). Of course it
would then have to do some method to use both networks. I.e. 
how would it decide to fail over.. it can't know what the end's
are doing.. and of course the multi-homed nature would be
hidden from the peer Host-Z which would mean it would not know
to HB a seperate address.

This gets ugly fast...

If the base protocol had seperate ports allowed.. you might be
able to do it... but that is a major change to the protocol..
R

_______________________________________________ Ietf-behave
mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx 
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

-- Randall Stewart ITD 803-345-0369 <or> 815-342-5222 
_______________________________________________ Ietf-behave mailing
list Ietf-behave@xxxxxxxxxxxxxxxxxxx 
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 17 Feb 2005 14:23:57 -0800 (PST)

...
c) forget NAT usage for SCTP ...
a and b solve two completely different problems.  If SCTP is to
traverse NATs, both of those problems would need to be solved.
I have a strong preference for c, at least in the multihomed case.
What do you mean by "forget NAT usage for SCTP"? I personally have known commercially 
deployed networks running multi-homed SCTP nodes across NATs.

regards,
-Qiaobing
Melinda

---

From: Randall Stewart <[email-masked]>
Date: Thu, 17 Feb 2005 14:28:13 -0800 (PST)

Melinda Shore wrote:

We have 3 Options:

a and b solve two completely different problems.  If SCTP is to
traverse NATs, both of those problems would need to be solved.
I have a strong preference for c, at least in the multihomed case.
I think we agree then.. lets get singly homed SCTP NAT's working

And then head out south into the hinter land :-D

R
Melinda

---

From: Randall Stewart <[email-masked]>
Date: Thu, 17 Feb 2005 14:29:17 -0800 (PST)

Qiaobing Xie wrote:
...

What do you mean by "forget NAT usage for SCTP"? I personally have known 
commercially deployed networks running multi-homed SCTP nodes across NATs.
Whoses NAT are they using? Tell me in private if you can't tell
me in public..
I am curious and this could help me to know that..

R
regards,
-Qiaobing
Melinda

---

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Feb 2005 14:48:00 -0800 (PST)

On Thursday, February 17, 2005, at 05:21 PM, Qiaobing Xie wrote:
What do you mean by "forget NAT usage for SCTP"? I personally have 
known commercially deployed networks running multi-homed SCTP nodes 
across NATs.
Do you know how they're doing it?

You'll note that I qualified my "forget NAT ... " comment with "at
least in the multihomed case."  I do think that if there are concerns
beyond basic protocol support they should be documented, as is being
done here with TCP, etc.  What I think should be forgotten, or at least
deferred for the time being, is modifying SCTP to support multiple port
numbers.  What I think should be deferred forever is a nat-nat protocol,
since there are security reasons and topological reasons to push the
solution for that particular problem out to the endpoints rather than
embedding it in the NATs.
Melinda

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 17 Feb 2005 15:42:59 -0800 (PST)

Malinda,

....
What do you mean by "forget NAT usage for SCTP"? I personally have 
known commercially deployed networks running multi-homed SCTP nodes 
across NATs.
Do you know how they're doing it?
I won't be able to give details. But at a very high level, they did not try to attempt a 
multi-point traverse of a multi-homed sctp association (as we are trying to figured out here 
and we all agree that there is no cheap solution). In their case, the association in the 
network gives you true path redundancy from HOST A to NAT, and true path redundancy from NAT 
to HOST Z, and they accept the fact that the NAT is a single point of failure in the path.

regards,
-Qiaobing