Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-11.txt

From: Salvatore Loreto <[email-masked]>
Date: Tue, 1 Mar 2005 09:20:47 +0100 (CET)

Hi all,
 
I've a question about addip:
 
why is it impossible change an association address during the four way handshaking ?
 
br
Sal

[email-masked] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

Title : Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
Author(s) : R. Stewart, et al.
Filename : draft-ietf-tsvwg-addip-sctp-11.txt
Pages : 35
Date : 2005-2-22

This document describes extensions to the Stream Control Transmission
Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
address information on an existing association.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-11.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-tsvwg-addip-sctp-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-11.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---------------------------------
Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! 

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 1 Mar 2005 13:57:54 +0100

Hi Sal,

why not just use the correct addresses dring setup? If
one of the addresses is not valid anymore it can not be
used for DATA transfer, because it will not be verified.

And the SCTP chunk authentication, which is now required
for ASCONF/ASCONF-ACK chunks needs the 4 way handshake
to establish a shared key. See
http://www.ietf.org/internet-drafts/draft-tuexen-sctp-auth-chunk-03.txt

Best regards
Michael

On Mar 1, 2005, at 9:20 Uhr, Salvatore Loreto wrote:

> Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, 
> Webcam, Giochi, Rubrica… Scaricalo 
> ora!_______________________________________________
> tsvwg mailing list
> [email-masked]

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 1 Mar 2005 14:50:42 +0100 (CET)

Hi Michael,
 
my scenario is this, 
suppose I want start a session with a node belongto a Mobile IP network, and this node moved to a foreign network...
so now when the MN receives an INIT, I think insert in the INIT ACK also a ASCONF chunk with the real address (it has in the foreign network), should improve mobility delay.
 
br
Sal

Michael Tuexen <[email-masked]> wrote:
Hi Sal,

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 1 Mar 2005 17:27:39 +0100

Hi Sal,

you can just use the real address as the source address of the
INIT-ACK and list the destination address of the INIT in the
INIT-ACK.
So the COOKIE-ECHO should go to the real address.

After the handshake you could delete the address.

Please note that the intention of ADDIP is not mobility,
but allow for reconfiguration in long living associations
without interrupting the service.

Best regards
Michael

On Mar 1, 2005, at 14:50 Uhr, Salvatore Loreto wrote:

> Hi Michael,
>  
> my scenario is this,
> suppose I want start a session with a node belongto a Mobile IP 
> network, and this node moved to a foreign network...
> so now when the MN receives an INIT, I think insert in the INIT ACK 
> also a ASCONF chunk with the real address (it has in the foreign 
> network), should improve mobility delay.
>  
> br
> Sal
>
> > why is it impossible change an association address during the four 
> way
> > handshaking ?
> >  
> > br
> > Sal
> >
> > [email-masked] with the word unsubscribe in the body 
> of
> > the message.
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> Webcam, Giochi, Rubrica… Scaricalo ora!

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 1 Mar 2005 18:16:43 +0100 (CET)

Hi Michael,
 
sorry but if an INIT sender receives an INIT ack from a different Address
that can't be a problem?
 
br
/sal

Best regards
Michael

On Mar 1, 2005, at 14:50 Uhr, Salvatore Loreto wrote:

> Michael Tuexen wrote:

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 1 Mar 2005 20:14:00 +0100

Hi Sal,

it is not a problem if the destination address of the INIT is
listed in the INIT-ACK. If it is a problem with a particular
implementation it is a bug of that implementation...

Best regards
Michael

On Mar 1, 2005, at 18:16 Uhr, Salvatore Loreto wrote:

> > > This draft is a work item of the Transport Area Working Group  
> Working
> > > Group of the IETF.
> > >

---

From: Randall Stewart <[email-masked]>
Date: Wed, 02 Mar 2005 07:39:52 -0500

> implementation it is a bug of that implementation...

Michael:

We need to add this has a test for the next inter-op... since
it is an important little nit that should be tested. Something
to consider for the bakeoff draft..

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Randall Stewart <[email-masked]>
Date: Wed, 02 Mar 2005 07:38:36 -0500

> sorry but if an INIT sender receives an INIT ack from a different Address

Nope...

Here an example in a NON-Mobile type case that is perfectly valid..

Consider the following two hosts..

+========+                        +========+
| (IP-A1)+<----/cloud ISP1 /----->+(IP-Z1) |
| host-a |                        | host-z |
| (IP-A2)+<----/cloud ISP2/------>+(IP-Z2) |
+========+                        +========+

Now.. lets say that the admin on each system
niavely setup the routing tables to add default
routes out to each of the two ISPs...

Linux allows multiple default routes if I remember
right.. FreeBSD you have to turn on RADIX_MPATH in
the KAME implementation..  Lets also assume
that we do not have the patch for alternate
routing (for a discussion of this see under
the downloads tab at http://www.sctp.org about
why you need alternate routing).

Now in this case both sides will use the default route
that is FIRST.. and lets say on one side the admin typed

route add default A1-ISP1
route add default A2-ISP2

and the other the admin typed

route add default Z2-ISP2
route add default Z1-ISP1

Now A binds port 9000 and Z binds port 10000 and
binds all addresses. A initiates an association to
IP-Z1

so you get:

------TO:IP-Z1[INIT(IP-A1, IP-A2) FROM:IP-A1---->

Since the default route for IP-A1 will point out the
interface of A1, we will do the proper src addr selection
and pick up the outbound interface that is bound to
the address...

The peer will answer:

<-----TO:IP-A1[INIT(IP-Z1, IP-Z2) FROM:IP-Z2-----

And will route it out over ISP-2.. since this is the
"first" default route.

So when the packet arrives.. it will be sourced from
Z2 ... which in theory, the peer did not know about...

This is why when parsing INIT/INIT-ACK's an implementation
must consider ALL addresses listed in both the INIT
and the INIT-ACK's .. even Z must do that incase a
collision case is happening where the A side restarted. It
needs to find out if A1 or A2 are already inside an association
or not.

So .. bottom line is all one needs to do for your case is
has Michael stated..

When the guy sends in the INIT .. it can be forwarded by
Mobile-IP... when it arrives at the real address send back
the INIT-ACK with a source address of the mobile address and
just list the "home" address inside the INIT-ACK. After
the assoc is up.. send a ASCONF that deletes the "home" address.

This is also how Anycast and SCTP will work well together too.
Since you can do the same scenario with an Anycast address ...

R

> ------------------------------------------------------------------------
>

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 2 Mar 2005 21:27:11 +0100

Randy,

I'll add this.

Such a test is part of the ETSI tests....

Best regards
Michael