Re: [Tsvwg] EndPoint and Association Address conflict

[Qiaobing Xie <[e-mail]>]

R, 

A couple of comments...

Randall Stewart wrote:
...
> Now I have done a bit more thinking on this. The corner case that
> we were worried about was this (if I remember right):
> 
> Host A                                          Host Z
> IP-A/IP-B                                       IP-Z
> (An UDP model Endpoint
>  Listening on Port 2222)
>         IP-A:Port-2222<-----------------INIT(From IP-Z:Port 3333)
>         ----------INIT-ACK(IP-A,IP-B:Port 2222)-------->
>         <--------------COOKIE-ECHO----------------------
>         ----------------COOKIE-ACK---------------------->
> 
>             Now at this point A-1 is up.
> 
> Now along the line we do
> 
> ifconfg New-Intf IP-C
> 
> and magically do
> 
> --------------ASCONF(ADD-IP:IP-C)------------------------>
>     <---------------------OperationalError(Unknown Chunk ASCONF)-----
> 
> So here we have a potential problem...

At this point, would our local stack (I am avoiding to use endpoint
here) actually start to use IP-C as the source addr in any outbound
packets in the current association? If so, that would trigger an abort
from the peer and kill the current association. If not, then strictly
speaking, IP-C has not yet been added to the local **endpoint** that the
current associaiton is using. It has only been made available to the
local stack for future use. 

> 
>                     now our silly peer does
> 
>  <------------------------IP-C:2222 INIT(IP-Z:Port 3333)
> 
> What do we do?
> 
>  --------INIT-ACK(IP-A,IP-B,IP-C: Port 2222)---------->IP-Z:Port
> 3333--->
> 

When the local stack does this, it starts to manage two logically
different local endpoints - the one used by the old association that has
only IP-A and IP-B; the other is intended for the new association, as
advertised in this INIT-ACK, that has IP-A, IP-B, and IP-C.

To have multiple logical endpoints here is not a problem. But the
problem is that they are sharing IP-A and IP-B. This not only goes
against RFC2960 definition, but also becomes the root cause that opens
the door for the "corner case" and potential danger of other "duplicate
association" cases.

Of cause, as you showed below, if a solid implementation is vigorously
checking and double-checking for dup associations at multiple points
during the initiation process, you may eventually weed them out. But I
am not sure about just relying on the implementation to catch dup
associations.

-Qiaobing

> 
> Now what we have forgotten about is what our silly endpoint is going
> to do.
> 
> The SCTP stack on Host-Z must look to see if a collision is
> happening.. this is required in RFC2960. So what happens will depend
> on where the INIT-ACK is sourced from..
> 
> If by chance its source is IP-A or IP-B ... guess what? the lookup
> at Host-Z will return the OLD association which is NOT in a COOKIE-WAIT
> state.. so what will Host-Z doe? Discard the INIT-ACK... This will
> happen again (i.e. the INIT-timer will expire on Host-Z and this will
> then repeat until we fail).... No problem..
> 
> Now what happens if by chance it IS sourced from IP-C? We find the
> newly forming association. Now it goes throughs its procedures
> to attempt to gather all the valuable goodies out of the INIT-ACK.
> In the process it must load its peers addresses to the association.
> And here is where it SHOULD detect the other association. I know
> in our implementation one of the first things I do when loading
> an address is do a lookup on the address I am loading.. I want
> to make sure it is in the association only ONCE. In the process
> I get back the association ... one of the checks I do is verify
> that it is the same association that I am working on loading
> address to .. if not.. guess what ? I detect the error and
> bail out.. dropping the INIT-ACK... so .. same result.. we continue
> to send out INIT's and drop the result.. thus the IP-C association
> just never forms..
> 
> Now is this clear in any document that you must look for addresses
> as you load them.. no its not specified since it is an implementation
> detail. I will admit it is an important one.. Should it be documented
> that you SHOULD attempt to detect this? Maybe but I am not sure
> where this would fit..
> 
> But in the end my basic premise is that if the implementation is
> coded right the silly endpoint will self-correct and NOT bring up
> this strange association.
> 
> I don't think we can dis-allow adding an new address... otherwise
> a true restarting association could not come up if I just added
> an address until it aborted ... so I don't like that idea...
> 
> Let me also note .. say my implementation hits a peer that does
> NOT catch this.. guess what.. the same code is going to run to
> load the addresses from the cookie.. It too will find this
> double association setup and drop the cookie...
> 
> So my contention is that this corner case is NOT an issue if
> the address loading is done properly by the implementation...
> 
> R
>


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