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

From: Schruefer Wolfgang <[email-masked]>
Date: Thu, 22 Jul 2004 15:03:48 +0200

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Jul 2004 17:24:14 +0200

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:
> One or two simple NAT boxes translate addresses AL1 and AL2 to global 
> Adresses AG1 and AG2 (just IP-Address / Port).
>
>
> Procedure:
>
> 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.
>
>
>
> Purpose: To mark the second association as temporarily used for ADDIP 
> (this association should not be used for data transport).
>
> 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'.