Subject: [Tsvwg] EndPoint and Association Address conflict

From: "Khan, Mohammad" <[email-masked]>
Date: Sun, 28 Apr 2002 23:03:50 -0700

Hi All,
I could make the following observations from the ongoing discussions about
Endpoint and Association address conflict for SCTP.

1)INIT chunk shall contain all the addresses bound to the Endpoint.

2)Addition and deletion of IP address shall be on Endpoint not on
Association.

For the point 2) suppose an Endpoint E1(IPA and Port X) has multiple
associations A1, A2 and A3 with three different peers.

	E1(IPA and PortX)			Peer Hosts
	A1(E1)					IPB and Port X
	A2(E1)					IPC and Port X
	A3(E1)					IPD and Port X
As per the assumption 2) to add an IPZ at E1 SCTP has to send ASCONF chunk
on all the A1, A2 and A3 associations and it shall not consider this address
as added till it receives success from all the associations. If failure is
received is received from any of the associations then this Add-IP request
shall be discarded. 

Same procedure is to be adopted to delete an address from an endpoint.
Please comment.

Regards
kashif

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Apr 2002 01:56:20 -0500

Khan,,

> 1)INIT chunk shall contain all the addresses bound to the Endpoint.

RFC 2960 permits non-multihoming.  It also permits the addresses in
the INIT to be a subset of the addresses available to an Endpoint.
A user process starting an association might not have permission to
all the addresses owned by a host.  How do you propose to make this
requirement stick?

If you mean that when an association happens to be bound with
INADDR_ANY and an IP is added, and the host determines in some
implementation dependent fashion that a new dynamic address should
be subsequently added to this association, that it should perform
the ADDIP procedures on behalf of the association, then there might
not be a problem.  But the above seems to rule out many features of
SCTP that are already implemented and being used.

> received is received from any of the associations then this Add-IP request

Huh?  Why must it fail for all if it fails for one?  That doesn't
sound too wise.  For example, if the receiver of the ASCONF does not
like the new destination (perhaps it does not meet security criteria)
it would not be able to reject it?

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 29 Apr 2002 12:50:42 -0500

Hi, kashif,

I didn't see your this email before I sent out my "rules" email a few
min ago. I totally agree with your following rules. 

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 13:07:04 -0500

> received is received from any of the associations then this Add-IP request

Here I disagree.. You add it to the endpoint and it is added
RIGHT away..

At the same time you start sending off your ASCONF's. If for some reason
an association  fails to add an address (either via non-support of
add-ip OR some other failure) that association is in a odd state
until either:

A) it restarts

or

B) it terminates.

This is such a corner case I don't see it as an issue. The corner
case being that your peer (who does NOT support Add-IP) sends an
INIT to the new address. If that were to occur, when you unpacked
the cookie you would find the other association and in my opinion
to handle the corner case.. abort the newly forming association
(not the old one) or just drop the cookie and let it timeout until
it goes away...

I don't see this to be an issue...

R
-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 13:53:32 -0500

Qiaobing:

See my response to your email on "new rules" I think
I show that all Hell will NOT break loose... since
the handling of duplicate INIT's with the added
"no new addresses can be added (in the implementors guide)"
pretty much handles this case correctly..

R

Qiaobing Xie wrote:
> Randall Stewart wrote:
> Either treatment (ie., to reject the add or to force out associations
> that can't perform the add) will be OK with me. The bottom line is to
> maintain the integrity of the endpoint, otherwise "all hell will break
> loose" :-)
> 
> -Qiaobing
> 
> >

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 29 Apr 2002 13:45:51 -0500

-Qiaobing