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

From: [email-masked]
Date: Fri, 26 Apr 2002 11:43:31 +0300

Hi Sandeep!

	See my comment inline...

> hi all, 
>  
> My comments inline, 
>   
> 
> 	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...
> 
> [ sandeep ] I think this is very interesting proble :-)
>  What i think we can do is When u are doing DELETEIP for IPb, If no
> association is using IPb as source address we should remover IPb from
> Endpoint E1. This way we will not have any such problem. 
> 
> What do u think ????

	No, I don't think this is a good solution... Remember that there can be many associations in that endpoint, and that they might be using IPb as A1 did once... I don't think you can erase that address from the endpoint...

	BR Iván Arias Rodríguez

> 	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:31:29 -0500

>         No, I don't think this is a good solution... Remember that there can be many associations in that endpoint, and that they might be using IPb as A1 did once... I don't think you can erase th…

Hmm.. maybe the real solution is you MUST NOT use the DELETE unless
you are also deleting it from the endpoint.

So... if you do a DELETE IP-B you MUST first delete it from the
endpoint. Then you MAY delete it from any association... ones you
don't delete it from will have to have a variant list of addresses
that it has ...

That way everything still works for those that DO NOT delete IP-B and
your problem goes away...

Of course your problem STILL exists when you HOT-PLUG in a card
and have an existing association and NO ADD-IP extension...

R