Subject: RE: [Tsvwg] End point and association Address conflict

From: [email-masked]
Date: Wed, 24 Apr 2002 15:34:12 +0300

Hi all!

	I would like to make some comments, just to be sure that I understand the logic of the dynamic addition/deletion of IP addresses for SCTP in the right way... As the subject is a little bit confusing, I'll try to be as clear as I can... which means a long mail... :-(

> "Balani, Sandeep" wrote:
> > 
> > Thanks Randy & Qiaobing,
> >   Although i would like to add something here.
> > 
> > So the inference of this discussion is : The source IP 
> Addresses in an
> > association can be subset of Endpoint addresses.   Is this 
> statment correct
> > ?

	In my understanding, this is the whole picture. Your machine has several different NICs, let's say each of them with a single IP address. Imagine that those IP addresses are IPa, IPb, IPc and IPd... You can use all of them or just a subset of them, plus a port number, to create an endpoint. As always, if two endpoints use the same port, they cannot share the use of any address (i.e., that address cannot be used in more than one endpoint). Endpoints E1(IPa, IPb; Port 1), E2(IPc, IPd; Port 1), and E3(IPa, IPb, IPc; Port 2) could coexist without problems...

	Let's say that you have created E1. Then you are listening on IPa and IPb with Port number 1. When you receive SCTP datagrams (from unknown peer addresses) to any of these two addresses using Port 1, you should answer in the right way depending the type of chunks it carries (INIT, COOKIE ECHO, SHUTDOWN ACK, OOTB...).

	However, when you create an association, it initially uses ALL the IP addresses of that endpoint (no matter if your user started it or if the peer was the one sending the INIT chunk)... This is my understanding... :-/ If you create the association in a different endpoint, you can use a different set of addresses, though...

> > In the above case an Implmentation "MUST" make sure that 
> whatever source IP
> > addresses are communicated during association intialisation 
> should be used
> > while sending outoing packets. ( I.e. control U'r Src IP Addresses )
> > 
> Yes. If you don't use ALL source addresses then you must
> tightly control what you place in your outbound IP packets :>
> 
> This CAN causes issues with some O/S's.. for those you may
> only be able to allow the bind-all type symantic..

	You must only use the addresses you use... I mean, as a (hopefully) easy to understand example, the same happens with the port number. If your association uses port number 23471, then, you must use that port, and not 23472 (even though another association might be using it)... Addresses/port is what determines each side of the association, so you should not use any Address or Port that is not part of the association...

> > Also to extend the same logic, In the example I have shown 
> below If i
> > terminate Association A1, I should also delete the entry of 
> IP-C address in
> > Endpoint E1 Correct ?????

	This is a somehow difficult thing to think about... This is precisely what made me change almost all the structure of my implementation...

	I would like people to comment on my comment, to see if I'm right...

	You can have several endpoints. Let's say we have the three defined above.

	Let's start for the easy thing. If you have an association created in E3, A1E3, if you erase any of the source addresses of that association, you DON'T have to erase that address from E3. I.e., if you erase IPc, then, you would still process SCTP datagrams directed to IPc and Port 2 (as directed to E3 and coming from an unknown peer), HOWEVER, you won't consider that datagram as being directed to A1E3 even if the peer of A1E3 sent that datagram (if it contains DATA, it will be an OOTB datagram).

	But this brings some other problems... Imagine that the peer of association A1E3 is IPz, Port 65535. A1E3 (after erasing IPc) will in fact be described by: [(IPa, IPb; Port 2), (IPz; Port 65535)]. If now we receive a datagram from IPz/65535, directed to IPc/2, what happens? If it doesn't carry an INIT or COOKIE ECHO, the answer is easy, just discard it, send back an ABORT or SHUTDOWN COMPLETE depending on the chunks inside... But, if the peer (IPz; Port 65535) is in fact starting a new association (sending INIT or COOKIE ECHO), what should we do? We cannot open a new association, let's say A2E3, containing all the source addresses of E3, because then we wouldn't know, for example, if a chunk from IPz/65535 and directed to IPa/2 goes to A1E3 or A2E3...

	In my case, I don't allow this. Before establishing a new association I check if this kind of problem happens...

	Now, let's say that you have another association, A1E1, created in E1, and using both IPa and IPb with Port 1, whose peer is (IPy; Port 65535). If you have another association, A1E2, created in E2, using IPc and IPd with Port 1, whose peer is the same as A1E1's one (IPy; Port 65535), what happens if A1E1 want's to add IPc as another source address?

	In my case I check again, that this wouldn't conflict with any existing association before I allow the user to do so...

	Imagine that A1E2 does not exist. In that case you would be able to add IPc to A1E1. All the datagrams directed to IPc/2 will be considered as directed to E2 if THERE ISN'T any already established association using IPc/2 whose peer uses the source address/port of the incoming datagram... I.e., if there isn't any other association established but A1E2 (with the added IPc), all the datagrams directed to IPc/2 will be treated as from an unknown peer and directed to E2, except from the ones coming from IPy/65535, that are part of A1E2...

	After adding IPc to A1E1, the user will NOT be able to create a new association in E2 whose peer is IPy/65535, for the same reasons stated above...

	So, you never change the endpoint, just the association... This creates some problems, though... That's why AddIP extension is in my opinion a somehow difficult extension to add to your implementation...

> I am a bit confused by the above. Does E1 have IP-C or not? 
> 
> I thought your example was that E1 bound all 3 A/B/C but for
> some strange reason did NOT send C on one but did on another.
> 
> For our implementation an ENDPOINT binds a SET of addresses or
> ALL addresses. So the address IP-C would NOT leave the
> endpoint once the association ended...

	Yes, but an association created within an endpoint uses always ALL the source addresses of that endpoint, right?

> > Lastly this may never be TRUE but I would like to ask this 
> question anyways.
> > In the example below I did'nt communicated IP-C on 
> Association A2, But Lets
> > take a wild case that somehow I receive a SCTP packet on [ 
> IP-C, Port-X,
> > D2, Port-P2] then SCTP will accept this Packet Is'nt it ?  
> As u will find
> > endpoint valid & Association  also .
> > 
> Well, I am not sure how this could even happen.. the peer only knows
> A/B so it is really a non-issue. But I will say the answer is
> implementation dependant. Some implementations MAY not find the
> association... Others MAY.. I think the point is moot since the
> situation is not possible...

	I'm with Randall here... If you have not sent yet the ASCONF, then, the peer should not send anything (unless you are connected to a future teller server ;->)... However, as the source address is considered in use (only when receiving datagrams, not when sending them) even before the ASCONF ACK is received, I guess that an implementation could do it either way... In my opinion it would be more reasonable not to accept that datagram as part of the association, though... :-/

	That's all!

	BR Iván Arias Rodríguez

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 24 Apr 2002 15:36:58 -0500

>         However, when you create an association, it initially uses ALL the IP addresses of that endpoint (no matter if your user started it or if the peer was the one sending the INIT chunk)... Thi…

I agree 100%.. when you send out your INIT or INIT-ACK you MUST USE ALL
of your addresses that are BOUND to the endpoint.. You should NEVER
send a "sub-set" of the endpoints addresses.. 

>         You must only use the addresses you use... I mean, as a (hopefully) easy to understand example, the same happens with the port number. If your association uses port number 23471, then, you…

Exactly!

>         In my case, I don't allow this. Before establishing a new association I check if this kind of problem happens...
I too would not allow this. I must also say that if this corner case
were to occur I would think it a bit unusual.. it is a bit odd... this
is why I think it is more than safe to NOT allow this..

>         Now, let's say that you have another association, A1E1, created in E1, and using both IPa and IPb with Port 1, whose peer is (IPy; Port 65535). If you have another association, A1E2, create…

But how could this even be legal... if 

E1={IPA, IPB + Port 1}
and
E2={IPC, IPD + Port 1}

Trying to put IPC in A1E1 means you are attempting to move
IPC from an already existing endpoint aka E2. You can't it is
a binding conflict... So you should never reach the state of
trying this since you have the IP address (IPC) already in
another endpoint E2...

>         In my case I check again, that this wouldn't conflict with any existing association before I allow the user to do so...

No, I think it is a conflict of an existing Endpoint NOT association.

> 
>         Imagine that A1E2 does not exist. In that case you would be able to add IPc to A1E1. 

No you can't do that. IPc belongs to E2 NOT E1.. so you can NOT add
a IP address to an association that does not have THAT IP address
BOUND to the ENDPOINT!

>         All the datagrams directed to IPc/2 will be considered as directed to E2 if THERE ISN'T any already established association using IPc/2 whose peer uses the source address/port of the incoming datagram... I.e., if there isn't any other association established but A1E2 (with the added IPc), all the datagrams directed to IPc/2 will be treated as from an unknown peer and directed to E2, except from the ones coming from IPy/65535, that are part of A1E2...

>         After adding IPc to A1E1, the user will NOT be able to create a new association in E2 whose peer is IPy/65535, for the same reasons stated above...
No if E2 exists and has bound IPC/IPB your SHOULD NOT ALLOW IPC to be
added to A1E1... E1 does NOT have IPC bound.

The basic concept is that a ENDPOINT must BIND the address FIRST
BEFORE you can use the dynamic IP address add. If the IP address
exists in another ENDPOINT then it is the same as if you try
to bind an address that someone else has... i.e. you get an error.

In the case of binding all ... there is no problem. you always
get all IP addresses on the machine... But once you start subset
binding the ENDPOINT must bind the address BEFORE you can add it
to ANY of the ENDPOINTS associations...

>         So, you never change the endpoint, just the association... This creates some problems, though... That's why AddIP extension is in my opinion a somehow difficult extension to add to your imp…
I think that depends. If one has a well structured implementation it
is no problem... You must keep the rules that you can't add an
IP address unless it is BOUND to the endpoint.. This is not
stated in the draft since the draft does not go in to the details
of the internal API's of the socket interface (for example). But 
you MUST structure your endpoint -to-> associations releationships
properly...

>         I'm with Randall here... If you have not sent yet the ASCONF, then, the peer should not send anything (unless you are connected to a future teller server ;->)... However, as the source addr…
If one does not while your ASCONF is "in flight" and you have not
recieved
the ASCONF-ACK.. one could always DROP the DG... the peer will
retransmit
it.. My implementation does not do this though.. it gets put into
a "special" status as I accept from it but wont source from it
until the ASCONF-ACK arrives...

I think either way is ok though...

R

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 24 Apr 2002 17:10:51 -0500

...
> send a "sub-set" of the endpoints addresses..

Agree. This is a very important point. Also, when reading this
statement, one must keep in mind the difference between "ALL addresses
BOUND to the endpoint" and "ALL addresses available to the OS/host."
They are not always the same. And with IPv6 and its fancy scoping rules,
they probably will always be different. 

-Qiaobing