Subject: RE: [Tsvwg] EndPoint and Association Address conflict

From: "Khan, Mohammad" <[email-masked]>
Date: Mon, 29 Apr 2002 00:30:00 -0700

Hi Brian,

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, April 29, 2002 12:26 PM
To: Khan, Mohammad
Cc: [email-masked]'; Pillai, Hari
Subject: Re: [Tsvwg] EndPoint and Association Address conflict

Khan,,

On Sun, 28 Apr 2002, Khan, Mohammad wrote:

> 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.

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.

This is what Randell mentioned in one of his comments
"
Why did you not include IPb in the INIT or INIT-ACK that setup A1. You
are
supposed to tell the peer of all your addresses that are bound to your
endpoint. 
You really MUST tell the peer of all your endpoint's addresses.  
R
"
> 
> 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. 

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? 

Seems quite annoyed. If u are accepting ADD/DELETE IP as successfull even if
ADD/DELETE IP is not successful for all the associations then again u will
end up in having two instances of one transport address between two
associations of same endpoint. That is what we all had been discussing till
now.
---kashif

--brian

> 
> 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

-- 
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 ¦

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Apr 2002 02:57:54 -0500

Mohammad,

Please see comments below...

On Mon, 29 Apr 2002, Khan, Mohammad wrote:

> are supposed to tell the peer of all your addresses that are bound to
> your endpoint.  You really MUST tell the peer of all your endpoint's
> addresses.  
> R
> "

Doesn't say that in RFC 2960 or anywhere else.  Here is a reason for
not including all the addresses:

I have a Signalling Gateway and an MGC, both of which have 3 interfaces:
two are high-speed interfaces on an Engineered network for signalling
applications; one is a low-speed interface which also acts as a default
route which is used for adminstrative tasks only (such as configuration,
SNMP, etc).  Although the SG can talk to the MGC on the default
interface, associations which are formed for signalling between the SG
and MGC can only use the interfaces dedicated to signalling on the
engineered network.

Now, it may be that the adminstrative interface is using DHCP on both
boxes.  When a DHCP lease time is renewed and a new IP address is
generated (e.g., on the SG), there is NO WAY that I am adding the new
address to the associations which are used for signalling.

An IPV6 example:  I have three interfaces which are connected to three
different service providers.  I place high-volume traffic on the two
service provided with which I can obtain the best rate for bulk traffic.
I place low-volume, low-latency traffic on the third service provider.
All 3 interfaces are DHCP.  I am NOT adding the low-volume service
provider interface to associations sending high-volume traffic.

I'm sorry but the INADDR_ANY approach does not work in many real-world
situations.

> associations of same endpoint.

So what's the matter with that?  This is permitted by RFC 2960 in its
current form, with or without ADDIP.

--brian

> That is what we all had been discussing till now.
> ---kashif
> 
> --brian
> 
> 
> >

---

From: Jacob Heitz <[email-masked]>
Date: Mon, 29 Apr 2002 01:24:03 -0700

Brian,

You are assuming that a host is equivalent to an SCTP endpoint.
That is, that if a host has 3 IPs, then any SCTP endpoint in that
host must have the same 3 IPs. IMO, an SCTP endpoint may be
constructed with only a subset of the IPs of it's host. ie,
this host with 3 IPs may contain an SCTP endpoint that has just
two of those IPs.

-- 
// Jacob Heitz. Tel:510-747-2917

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Apr 2002 03:44:06 -0500

Jacob,

True, in the examples I gave, the Host was one SCTP endpoint, but the

> > > >     E1(IPA and PortX)                       Peer Hosts

If one defines an Endpoint as a vector of IP addresses and a single
SCTP port number, what is to stop IP address vectors for distinct
associations from being disjoint or overlapping in any way the
implementation sees fit.  How one distinguishes endpoints is rather
arbitrary.

I don't see what is stopping this:

Before:
     Host                                    Peer Hosts
     A1(IPA and PortX)                       IPB and Port Y
     A2(IPA and PortX)                       IPC and Port Y
     A3(IPA and PortX)                       IPD and Port Y

After adding IPX, IPY, IPZ:
     Host                                    Peer Hosts
     A1(IPA, IPX and PortX)                  IPB and Port Y
     A2(IPA, IPY and PortX)                  IPC and Port Y
     A3(IPA, IPZ and PortX)                  IPD and Port Y

I could see a problem binding that way in the first place, but
for a fully formed association what does it matter?  Why define
the endpoint for the associations as EP1 just because they start
out life with the same IPA and PortX?

--brian