Subject: RE: [Tsvwg] SCTP: alternative ADDIP to enable NAT for mulithoming

From: Schruefer Wolfgang <[email-masked]>
Date: Thu, 22 Jul 2004 18:28:44 +0200

Hi Michael,

thanks for your comments, I can imagine your idea with association identifiers could improve the procedure.
 
But I do not unterstand your problems with the port numbers???
Maybe we should distinguish between the local port number and the remote port number:

For this idea it is not necessary to change the local port number handling! 
The only change is that we have a different remote port number for every path.
I think this should not cause difficulties, it is just an additional entry in the local path variables?

Please give an example if you still see serious problems.

Thanks
Wolfgang 

> -----Original Message-----
> From: Michael Tuexen [mailto:[email-masked]]
> Sent: Thursday, July 22, 2004 5:24 PM
> To: Schruefer Wolfgang
> Cc: [email-masked]
> Subject: Re: [Tsvwg] SCTP: alternative ADDIP to enable NAT for
> mulithoming 
> 
> 
> Hi Wolfgang,
> 
> I think it is very difficult to change the definition of an
> SCTP endpoint (at a given time) from a pair of a non-empty set
> of IP-address and a port number to a non-empty set of
> pair of IP-addresses and port numbers.
> 
> However, if you only consider NAT boxes which translate IP-Addresses
> and and not port numbers than you have only to avoid transporting
> IP-addresses inside SCTP.
> 
> You can do this by using an association identifier which you
> put into the INIT and INIT-ACK as a new parameter. This can be
> a hash to the TCB or something like this.
> 
> Then you add a new chunk which acts like an ADD-IP but contains
> the association identifier instead of the old address. The receiver
> could find the association based on the association identifier and
> could add the source address as an additional path.
> 
> Of course you would need to use the SCTP-AUTH extension to sign this
> new chunk, as it will be required for ADDIP.
> 
> This would be a possible way do deal with NAT engines which do
> not look at port numbers and therefore should work with SCTP.
> 
> This solution does not work with NAT engines which look at
> port numbers. But these boxes would need to support SCTP ...
> 
> Best regards
> Michael
> 
> On Jul 22, 2004, at 3:03 PM, Schruefer Wolfgang wrote:
> 
> > Dear all,
> >
> > I want to suggest an alternative ADDIP procedure to enable 
> multi-homed 
> > SCTP associations through simple NAT boxes. Its goal is to 
> avoid the 
> > usage of address parameters within SCTP chunks. It is just an idea, 
> > but up to now I see no restriction why it should not work ...
> >
> >
> > Example configuration:
> > Consider endpoint A (Client) has two local transport 
> Adresses AL1 and 
> > AL2.
> > Consider endpoint B (Server) has one or more global 
> transport Adresses 
> > B.
> > One or two simple NAT boxes translate addresses AL1 and AL2 
> to global 
> > Adresses AG1 and AG2 (just IP-Address / Port).
> >
> >
> > Procedure:
> >
> > 1. Step: A establishes a first single-homed Association 
> from AL1 to B.
> >
> > 2. Step: A establishes a second single-homed Association 
> from AL2 to B.
> >
> > 3. Step: A requests B to merge the transport address of the second 
> > assoc as new path for the first association. In parallel the second 
> > association must be aborted.
> >
> >
> >
> > It could this be realized this way:
> >
> > 1) Definition of a new INIT/INIT-ACK parameter e.g. 'MERGE ONLY'.
> > Purpose: To mark the second association as temporarily used 
> for ADDIP 
> > (this association should not be used for data transport).
> >
> > 2) Definition of a new ASCONF (ADDIP) parameter e.g. 'MERGE SCTP 
> > ENDPOINT'.
> > Purpose: To be sent via the first association to trigger the merger 
> > (for security this parameter should contain at least the 
> Verification 
> > Tags of the second association, but not its transport address).
> >
> > 3) Removal of the Address Parameters in the ASCONF 
> Paramters 'Delete 
> > IP Address' and 'Set Primary IP Address'.
> > Remark: The source address of the packet including this 
> chunk should 
> > be used instead to identify the path.
> >
> > 4) Removal of the SCTP restriction: all path addresses must use the 
> > same port number.
> >
> >
> >
> > Your comments are welcome!
> >
> > Viele Gruesse
> > Wolfgang
> >
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> >
> 

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Jul 2004 19:06:08 +0200

Hi Wolfgang,

it is not required that an SCTP implementation controls
the source address. If the port number depends on the
source address, then the SCTP implementation has to
make that choice. Just one example.

Best regards
Michael