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

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

Qiaobing, 

Qiaobing Xie wrote:
> 
> Schruefer Wolfgang wrote:
> 
> > Hello,
> > 
> > yesterday Melinda gave us the advice to consider the larger context...
> > Therefore I will try first to explain my motivation by an example instead 
> > of technical details:
> > 
> > *********************************************
> > Example (I will use Luca's scenario):
> > 
> > - A client application on host X needs Interface 
> >  redundancy, but unfortunately SCTP can not establish a multihomed 
> > Association due to NAPT... 
> > 
> > 
> >> 
> >>    SCTP   (A+)-------------N                                     SCTP
> >>    HOST X (  )             A--E+-------------cloud------------+--HOST Z
> >>           (B+)------------ P
> >>                            T   
> > 
> > 
> > - But the application is smart: it creates 2 singled homed associations: a 
> > primary association containing Addr A as 
> >   Source Address and a secondary containing Addr B as Source Address.
> > - If Association A fails, the application continues data 
> >   transfer using association B.
> 
> I assume you meant that they were 2 singled homed 
> associations with HOST Z, i.e., A<->Z and 
> B<->Z.
 
Yes, exactly. I wanted just to make it simple. 
Please see the NAPT as a cloud with random Address and Port translations, not 
as a single box.

> > 
> > And you see: The application has a multihoming 
> functionality, it uses SCTP and it is behind a NAPT!
> > 
> > **********************************************
> > 
> > What I expect:
> > 
> > If the application can realize multihoming, SCTP should be 
> able to do it also. Probably better. 
> > Do I really expect too much???  
> 
> But why this is a question unique to SCTP? Your smart 
> application should be able to do the 
> same with two TCP connections, right? If so, maybe your 
> challenge should be: should any 
> transport be able to do it also.

This question is unique to SCTP, because it is the unique protocol that claims 
the multihoming feature.
Let me cite the introduction of the SCTP RFC:
"SCTP ... offers the following services to its users:
      --...      
      -- network-level fault tolerance through supporting of multi-
         homing at either or both ends of an association."

Sure, as you agree that an application might implement its own multihoming if 
SCTP fails, it would not need SCTP. Then a smart application might use TCP or 
even UDP...

But the transport protocols should provide best service to applications to make 
things easier and with as less restrictions as possible. That is why I think 
the multihoming and port numbering restrictions should be a topic for future 
SCTP improvement.

Best regards,
Wolfgang

> regards,
> -Qiaobing

---

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

Comments inline..

Qiaobing Xie wrote:

Hello,

yesterday Melinda gave us the advice to consider the larger
context... Therefore I will try first to explain my motivation by
an example instead of technical details:
********************************************* Example (I will use
Luca's scenario):
- A client application on host X needs Interface redundancy, but
unfortunately SCTP can not establish a multihomed Association due
to NAPT...

SCTP   (A+)-------------N
SCTP HOST X (  )
A--E+-------------cloud------------+--HOST Z (B+)------------ P
 T

- But the application is smart: it creates 2 singled homed
associations: a primary association containing Addr A as Source
Address and a secondary containing Addr B as Source Address. - If
Association A fails, the application continues data transfer
using association B.
I assume you meant that they were 2 singled homed associations with
HOST Z, i.e., A<->Z and B<->Z.

Yes, exactly. I wanted just to make it simple. Please see the NAPT as
a cloud with random Address and Port translations, not as a single
box.

What I expect:

Do I really expect too much???
But why this is a question unique to SCTP? Your smart application
should be able to do the same with two TCP connections, right? If
so, maybe your challenge should be: should any transport be able to
do it also.

This question is unique to SCTP, because it is the unique protocol
that claims the multihoming feature. Let me cite the introduction of
the SCTP RFC: "SCTP ... offers the following services to its users: 
--... -- network-level fault tolerance through supporting of multi- 
homing at either or both ends of an association."

Sure, as you agree that an application might implement its own
multihoming if SCTP fails, it would not need SCTP. Then a smart
application might use TCP or even UDP...
But the transport protocols should provide best service to
applications to make things easier and with as less restrictions as
possible. That is why I think the multihoming and port numbering
restrictions should be a topic for future SCTP improvement.
So you want to change a fundamental design concept to accomadate
a hack called NAT.
And on top of that, I know of NO NAT's that yet implement SCTP.. yes
I have worked on a BSD version of one but its not released or even
fully tested yet.... So we have roughly 25-30 different implementations
of SCTP many being used in production environments.. and you want all
of them to go through major changes so you can make implementing SCTP
over NAT's more easy.. And yes it is major changes since you are
talking about the fundamental method that associations are
found via..
And it does not help solve the single point of failure issue... either..
nor does it help with HB'ing and all the other things.
In fact it solves very little of the true M-Homing NAT problem.. which
IMO is a need for a Nat-2-Nat communication protocol to allow two NATs
to assign the same port numbers and communicate state to each other.
Especially since very few nats are configured per your drawing... IMO

R

Best regards, Wolfgang

regards, -Qiaobing

--
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222

---

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

On Thursday, February 17, 2005, at 04:42 PM, Randall Stewart wrote:
In fact it solves very little of the true M-Homing NAT problem.. which
IMO is a need for a Nat-2-Nat communication protocol to allow two NATs
to assign the same port numbers and communicate state to each other.
I think this would be extremely difficult to do with any reliability
or robustness and I also think that we need to step back a bit.  It's
not that we've wandered into the weeds, it's that we're starting out
in the weeds.
What you're proposing here is that a host not only needs to know the 
address
of a NAT that its packets are going to traverse, the NAT is going to
need to know the address of another NAT and choose the correct one
based on addressing information.  Basically it's going to need to
know how to do network-layer routing.  Not only that, because packets
will not have started flowing from the other host(s) comprising the
endpoint, the nat-nat protocol you're proposing would also have to
be a request protocol - it's going to have to ask the other NAT(s)
to install a mapping and return the results (we already have that -
it's called midcom).  Now think security, and what would have to
be done to authenticate both the request and response (and in the
case of NAT, an authenticated response is as important, if not
moreso, than an authenticated request).

Frankly, I think that the topology problem in doing this nat-nat
thing is basically intractable in IP networks as they work today.
My preference, because it's architecturally more harmonious (oommmmm),
would be to have the endpoint sending the INIT or ACK do the
requesting/discovery.  A more compelling reason, perhaps, than
the question of architectural goodness would be that if you're using
AH you're not going to be able to allow the NATs to scribble in the
headers.  So in addition to breaking basic IP networking principles
you'd also be causing a more tangible problem by breaking security.
Hence my preference for the endpoint-initiated request, although
I still think it's a mistake.
Melinda

---

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

Hi, Wolfgang,

...
This question is unique to SCTP, because it is the unique protocol that claims the multihoming feature.

Sure, as you agree that an application might implement its own multihoming if SCTP fails, it would not need SCTP. Then a smart application might use TCP or even UDP...

But the transport protocols should provide best service to applications to make things easier and with as less restrictions as possible. That is why I think the multihoming and port numbering restrictions should be a topic for future SCTP improvement.
So, it is a unique challenge to SCTP simply because SCTP is the one that has made such a 
statement/claim of supporting multi-homed endpoints while TCP does not? To be specific, 
which part(s) of the above quoted text from SCTP is invalidated or be made questionable by 
some one throwing a NAPT or two into the path?

regards,
-Qiaobing

Best regards,
Wolfgang

regards,
-Qiaobing

---

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

Melinda:

The last thing I would want to do is advocate such a protocol.
Its the only way, off hand, I can see of doing multi-homing with
NATs.. there may be other ways .. BUT I would NOT support
changing SCTP to make it work.
Now what we SHOULD be doing in NAT land is figuring out
how to make sure SCTP works through NAT's and getting THAT
working first... Lets concentrate on a singly homed SCTP
endpoint working through a NAT the same way TCP does today.
Get that done first and we have accomplished something..
AFTER that is done..  we can head off into the weeds and
look and see if we can find a Bass willing to byte our hook..
as long as it don't byte our heads off :-D
R

Melinda Shore wrote: