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

From: Tuexen Michael <[email-masked]>
Date: Mon, 29 Apr 2002 13:55:37 +0200

Brian,

see my comments below.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CC SE 7    E-mail: [email-masked]

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Monday, April 29, 2002 12:24 PM
> To:	Tuexen Michael
> Cc:	Jacob Heitz; Khan, Mohammad; [email-masked]'; Pillai, Hari
> Subject:	Re: [Tsvwg] EndPoint and Association Address conflict
> 
> Tuexen,
> 
> On Mon, 29 Apr 2002, Tuexen Michael wrote:
> 
> > Brian,
> > 
> > looking at the definition of SCTP end point on page 13 of
> > RFC 2960 an SCTP endpoint can be identified by a set of 
> > IP-addresses and a port number.
> > 
> > So for me it is a pair consisiting of a non empty set of
> > IP-addresses and a pot number. Endpoint = ({IP1, ..., IPn}, Port).
> > 
> > Using that definition your example is not valid if you consider
> > Add-IP working on end point base. It is valid if you consider 
> > Add-IP working on assciation base.
> 
> Why restrict Add-IP to an endpoint basis?
> 
	[Tuexen Michael]  Consider E1 = ({IP'}, Port), E2 = ({IP'''}, Port),
	E3 = ({IP''''}, Port) with pairwise different IP', IP''', IP'''' and two associations
	A1: E1 <-> E2
	A2: E1 <-> E3

	Now if we add IP'' to the association A1 we get
	A1 : E1' <-> E2
	with E1' = ({IP', IP''}, Port).
	E1' and E2 share one transport address which is in violation to RFC 2960, page 13.

	Please note that an association has two SCTP end points and these end points
	have the IP addresses. So changing IP addresses means modifying the end points.

	Best regards
	Michael  
> --brian
> 
> > 
> > Best regards
> > Michael
> > 
> > Michael Tuexen    Tel.:   +49 89 722 47210
> > Siemens AG        Fax:    +49 89 722 48212
> > ICN WN CC SE 7    E-mail: [email-masked]
> > 
> > > -----Original Message-----
> > > From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> > > Sent:	Monday, April 29, 2002 10:44 AM
> > > To:	Jacob Heitz
> > > Cc:	Khan, Mohammad; [email-masked]'; Pillai, Hari
> > > Subject:	Re: [Tsvwg] EndPoint and Association Address conflict
> > > 
> > > Jacob,
> > > 
> > > True, in the examples I gave, the Host was one SCTP endpoint, but the
> > > same is true for the Peer Hosts in Mohammad's example:
> > > 
> > > > > > >     E1(IPA and PortX)                       Peer Hosts
> > > > > > >     A1(E1)                                  IPB and Port X
> > > > > > >     A2(E1)                                  IPC and Port X
> > > > > > >     A3(E1)                                  IPD and Port X
> > > 
> > > 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
> > > 
> > > 
> > > On Mon, 29 Apr 2002, Jacob Heitz wrote:> 
> > > 
> > > > 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.
> > > > 
> > > > "Brian F. G. Bidulock" wrote:
> > > > > 
> > > > > Mohammad,
> > > > > 
> > > > > Please see comments below...
> > > > > 
> > > > > On Mon, 29 Apr 2002, Khan, Mohammad wrote:
> > > > > 
> > > > > > 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
> > > > > > "
> > > > > 
> > > > > 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 pla> ce 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.
> > > > > 
> > > > > > >
> > > > > > > 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.> 
> > > > > 
> > > >>  > 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
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Same procedure is to be adopted to delete an address from an endpoint.
> > > > > > > Please comment.
> > > > > > >
> > > > > > > Regards
> > > > > > > kashif
> > > > 
> > > > -- 
> > > > // Jacob Heitz. Tel:510-747-2917
> > > 
> > > -- 
> > > 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
> 
> -- 
> 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 07:14:52 -0500

Tuexen,

> 	E1' and E2 share one transport address which is in violation to RFC

There is only one MUST on page 13: "Two SCTP endpoints MUST NOT have more
than one SCTP association between them at any given time."

How does this violate anything on page 13?

E1' and E2 only have one association between them.  E1 and E3 only have one
association between them.  Everthing appears ok as far as page 13 is
concerned.

Did you mean another page?

Or, did you mean the statement: "A transport address used by an
SCTP endpoint must not be used by another SCTP endpoint.  In other
words, a transport address is unique to an SCTP endpoint."  ...which
is absurd, particularly as it is done in TCP all the time, and when
you consider that non-multihomed SCTP associations need to reuse
dynamic port numbers for connection to other hosts.

--brian

> 
> 	Please note that an association has two SCTP end points and these end
> 	points have the IP addresses. So changing IP addresses means modifying
> 	the end points.
> 
> 	Best regards
> 	Michael