Re: [Tsvwg] EndPoint and Association Address conflict

[Randall Stewart <[e-mail]>]

A comment in line and then some more thoughts..

Qiaobing Xie wrote:
> 
> Hi, Randy,
> 
> I think we are still using slightly different endpoint definitions (as
> you also realized below).
> 
> ...
> >
> > I still view it as adding to an endpoint but I think we must
> > re-think about this... I put this down in a private email discussion
> > but I think I will put it out here now ... even though the
> > thoughts are only partially baked :>
> >
> > We have basically 4 types of endpoints/sockets (note I think of
> > an endpoint as a socket aka open FD).
> 
> I think of an endpoint as an abstract logical entity (as dryly defined
> in RFC2960). I see three levels of address sets involved here:
> 
> Level 0: host addr set "S" = all the network addresses assigned to a
> host (host is logically represented by a single OS instance). A host can
> harbor multiple sockets/open FDs.
> 
> Level 1: addr set bound to a socket/open FD "s" = a subset of S bound to
> the FD (this is the logical representation of an SCTP stack). An open FD
> can harbor multiple endpoints. But some implementation, for simplicity
> reason, may support only one endpoint.
> 
> Level 2: addr set of an endpoint "e" = yet a subset of "s". This is the
> set of addresses actually used (or to be used) in an association.
> 

I don't get your Level 2 definition.. it is unclear to me
what you are saying...

> In summary, e <= s <= S.
> 
> All my previous discussions were based on the "e" definition (including
> the rules I proposed).
> Therefore, the following statement from Ivan
> 
>   - An association, can use a subset of the source addresses of the
>     endpoint to which it belongs.
> 
> becomes correct if Ivan's "endpoint" here implies a socket/open FD, but
> incorrect if the "endpoint" here is defined as "e" above.
> 
> I will think more about the socket implications.

This may help.. think on what I have said about socket descriptors (or
fds if you like) and what type of socket api model we have..

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...

                    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--->

                 
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


> 
> >
> > Now we have:
> >
> > 1) A UDP model socket/listener that A) accepts new associations and
> >    has some number of associations under it (fanned out is the term
> >    I think Qiaobing used).
> >
> > 2) A TCP model listener. This guy will have NO associations under
> >    it accept maybe onces waiting to be accepted ... nothing can
> >    happen on those though.. until AFTER they are accepted.
> >
> > 3) Accepted and or peel'ed off ones.. these are a single association.
> >
> > 4) A TCP model connect() caller. This guy can NOT accept any.. but is
> >    going to have a single "association" to a peer... note this may
> >    be (in the end) to a <1> or <3> type guy.. it does not matter.
> >
> > Now lets look at each case..
> >
> > First, an easy one, <3> is something that can NEVER get any new
> > associations. INIT's don't go to it... they go to whoever was the
> > listner... so in this case this association COULD have add-ip go
> > against it. .thoughts/notes...{I believe in our implementation of add-ip
> > this
> >                                guy MAY auto-add IP if it is setup via an
> >                                sockopt to do it.. default may be on
> > especially
> >                                if the parent (listener) is bound all
> >                                }
> >
> > Now lets look at another easy one.. <4> the connector.. this guy
> > IS NOT LISTENING.. it TOO can't get a INIT in.. an ABORT() would be
> > sent back... At the termination of its association, however, it MAY
> > do a listen() call..  so here we would ADD the address to the endpoint
> > (if it was turned on socketopt wise to do so..) and the attempt if
> > possible to add it to the peer.
> >
> > Now this leaves case <1> and <2>. The only real difference between
> > these guys is that we have one that has a cluster of associations
> > tied to it.. the other does NOT. Now we here ADD the address to the
> > endpoint. For <2> we are done.. when the next INIT comes in the new
> > association will form... and we are ok... For <1> new associations
> > will use the new address.. (all of this assumes that the option
> > to add automatically is enabled.. for bind-all this is probably
> > the default.. it may not be for sub-set bound). Now for the
> > existing "fan" of associations we would individually attempt to
> > add the address to them..
> >
> > Now for the big question .. what happens if we get our silly endpoint
> > (peer) that sends an INIT while holding an association to us (either
> > a TCP one or a fanned out one). Well some observations:
> >
> > a) First you must be able to find the old associations, if you
> >    can't then your INIT collision and RESTART code is NOT working.
> >
> > b) When you find the "old" associations it is going to look like
> >    a restart condition... especially for <1> since you locate the
> >    endpoint (and you have added the address here hopefully) and then
> >    you look for the association via one of the peers addresses. For the
> >    TCP model you also must switch the socket you are associated with
> >    in this hunt... hmmm lets look at both sides..
> >     - If you find it then you would actually go through the
> >       restart scenario as long as the peer used the same addresses
> >       it would appear to be a restart.. this would be very interesting
> >       and of course the peer would get very messed up I bet... but its
> >       a silly endpoint anyway.. in the end the old association would
> >       die, one way or another... Now if we add a restriction that we
> >       can't add any new addresses on either side (aka like our current
> >       peer can't add new addresses) then no problem.. we would ABORT()
> >       with new addresses...
> >     - If you can't find it then what would happen is when the COOKIE
> >       arrives you could since you could look at all your addresses
> >       and validate that a collision is not at hand... and then send
> >       an abort...
> >
> >    Pesonnely I prefer the no new addresses on either side during a
> >    collision.. this solves the problem as long as you can locate your
> >    associations.. which I think you should be able to..
> >
> >  Well .. there are some of my 1/2 baked thoughts... need to mull on
> >  them a bit more..
> >
> > R
> >
> > --
> > Randall R. Stewart
> > [e-mail] 815-342-5222 (cell phone)

-- 
Randall R. Stewart
[e-mail] 815-342-5222 (cell phone)


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