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

From: [email-masked]
Date: Fri, 26 Apr 2002 01:07:06 +0300

Randy, see my comment inline...

> [email-masked] wrote:
> > 
> >         Hi all!
> > 
> >         Well, now I realized that I had a somehow different 
> view about what was a legal addition... thanks for your comments.
> > 
> >         Now I have another doubt... Imagine that we have an 
> endpoint E1 with addresses IPa, IPb and port 1. We have an 
> association A1 that only uses IPa, whose peer is IPz and port 
> 65535. Thus the association A1 can be represented as [(IPa; 
> Port1), (IPz; Port 65535)]. What happens now if we receive an 
> INIT from IPz/65535 directed to IPb/1?
> 
> A question...
> 
> 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. I think this is the big flaw in your question..

	I did, but later on I deleted it using the AddIP extension... :-) So now I don't use it anymore...

	BR Iván Arias Rodríguez

> You really MUST tell the peer of all your endpoint's 
> addresses.  I don't
> think this is a valid scenario if you follow the proper endpoint
> procedures
> and tell your peer ALL your bound addresses..
> 
> R
> 
> 
> > 
> >         As IPb is not being used in A1, we should answer 
> with an INIT ACK as in a normal establishment of an 
> association. However, when you receive an INIT chunk, you 
> include all the addresses of the endpoint in the INIT ACK 
> chunk... But we have to be careful, because in this case, 
> when receiving the COOKIE ECHO, we have two options:
> > 
> >         a) It is directed to IPb. From our point of view, 
> it comes from an unknown peer, and then we should make a new 
> association. The problem is that we will create a new 
> association A2 that will use IPa as well, and this would be 
> in conflict with association A1, since the peer is the same one.
> > 
> >         b) It goes to IPa. Then, it will be treated as a 
> duplicate COOKIE ECHO. The local tag and the peer's tag 
> should not match the existing TCB, and the tie tags will be 
> set to 0. Thus, we are not in any of the cases that Table 2 
> considers, and we will silently discard the datagram. The 
> conclusion of this is that if the peer established an 
> association and we delete one of our source addresses, if the 
> peer actually restarts, we will be discarding the datagram 
> all the time and it will never be able to restart. Even if we 
> send DATA or HEARTBEAT, the peer will not send us back an 
> ABORT because they won't be OOTB datagrams...
> > 
> >         As when you create a new association you always 
> include all the address of the endpoint, there is no way 
> there could be another association A2 [(IPb; Port 1), (IPz; 
> Port 65535)] (unless you recognize this case when receiving 
> the INIT and you only include IPb in the INIT ACK, which I 
> don't think is a good idea at all), so I think that this 
> situation should be handled as a restart in any case... i.e., 
> if a COOKIE ECHO comes from an unknown peer, check inside the 
> State Cookie to see if we are in case a) below... However, I 
> don't know what should be done in the b) case... :-/
> > 
> >         What do the people of the list think about this?
> > 
> >         Thanks!
> > 
> >         BR Iván Arias Rodríguez
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 

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

---

From: Randall Stewart <[email-masked]>
Date: Fri, 26 Apr 2002 08:27:05 -0500

>         I did, but later on I deleted it using the AddIP extension... :-) So now I don't use it anymore...

Ok, but I don't get why you would do that... AddIP is intended for
when you add and delete interfaces... Using it to "tune" your 
interface addresses to have a different binding set then
your interface is not what it is intended for. I would think
you should have subtracted from the associations AND the endpoint.

Now if you think about this, you COULD have the same thing
occur when binding all (without AddIP)... i.e. you have bound all..
setup
an association.

Then you plug in a NEW card ifconfig it up and add an address.

Now your peer of the association sends a INIT()---> to your new address
and your existing port... which now showed up in your endpoint
since you are bound to ALL addresses...

AddIP fixes this in that you can add the address when it is ifconfig'd
up... 

I think that:

A) This is a real real corner case .. why would the peer endpoint try
    to communicate with you AGAIN .. remember it MUST be the same
    socket.. .when you already have an association?

 B) If you don't allow a delete of a address from an association unless
    it is also deleted from the endpoint.. the problem goes away.. hmm
    maybe this needs to be a rule for add-ip? not sure on this.. I want
    to think about it.. maybe not.. after all endpoints vs associations
    in some ways are a implementation issue...hmm..

 C) This can occur in current SCTP when you have the ability to
dynamically
    add a card...

Hmm thinking about it somemore.. if you are bound-all to the endpoint
you
won't have this problem.. since even if you deleted the address you most
likely will FIND the association and it will then look like a restart.

It will really confuse the other endpoint though.. since his old
association
will not work quite right.. it also will find the old association when
it gets your address list... hmm...

I will have to run this one around in my head for a bit..

R