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

From: "Balani, Sandeep" <[email-masked]>
Date: Mon, 29 Apr 2002 14:19:44 -0700

hi all, 
  Please see my responses below: 

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Monday, April 29, 2002 1:58 PM
> To: Qiaobing Xie
> Cc: Qiaobing Xie; Tuexen Michael; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] End point and association Address conflict
> 
> 
> Qiaobing Xie wrote:
> > 
> > ...
> > > I don't agree with this rule.. just because a peer in a UDP model
> > > endpoint on one of its assocaitions is NOT capable of add-ip why
> > > should the rest be stuck. Yes you have an abnormality here in
> > > that that peer COULD send a INIT to the new address.. 
> again I repeat:
> > > 1) This is such a corner case it is almost silly.
> > > 2) If it happens it is not that hard to handle... Looking at
> > >    the code Peter and I wrote you would end up finding 
> the endpoint
> > >    (since the address WAS added there) and you would then LOOK at
> > >    its associations. This would then appear to be a 
> RESTART where the
> > >    peer added addresses. You would then SEND IT an ABORT 
> saying restart
> > >    while adding addresses. This would leave the other association
> > >    un-touched and would elimiate the error on the peers part...
> > 
> > Randy,
> > 
> > Let's walk through this example in detail:
> > Say, local endpoint E1 has two associations to different peers,
> > 
> >      E1             A1     E2
> > [IPA,IPB:Port1] <-------> [...]
> >      E1             A2     E3
> > [IPA,IPB:Port1] <-------> [IPZ:Port2]
> > 
> > We do add-ip (IPC) to E1. After sending ASCONF to both E2 and E3, we
> > succeeded with E2 but failed on E3.
> > 
> >      E1'               A1'     E2
> > [IPA,IPB,IPC:Port1] <-------> [...]
> >      E1'               A2'     E3
> > [IPA,IPB,IPC:Port1] <-------> [IPZ:Port2]  /* E3 rejected 
> add-ip and */
> >                                       /* hence knows nothg 
> about IPC */
> > 
> > My understanding is that you would like to allow this.
> > 
> > Now, several things could happen,
> > 
> > 1) E3 may get a packet from E1' with src addr=IPC. This packet will
> > becomes an OOTB to E3 and E3 will send back an ABORT to kill the
> > ill-fated A2'. This is ok.
> > 
> 
> Why would E1' use IPC... in this case it knows that it is NOT
> part of the association. So it MUST NEVER source things from
> IPC as long as this holds true .. no problem.. only if
> E1's implementation is so bad it sources from IPC that a
> problem will occur.
> 

[ Sandeep ] Hi Randy,  It is possible because some implementation don't
control source IP address the same example u used for INADDR_ANY. In that
case if one don't control source IP address A2 might receive packet from
IPc. 

> 
> > 2) E3 may send an INIT to IPC/Port1. Is this the corner case you
> > described above? If so, I can see E1'1 will find the 
> association A2' and
> > take this E3 INIT as a restart, but I don't see why E1' 
> will consider it
> > as a "restart with added address" (E3 didn't add any 
> address, it still
> > uses only IPZ).
> 
> Yes.. this is a very corner case.. 
> 
>  A) E3 must be very confused to want two associations.. so in
>     my mind this is a corner case.
> 
>  B) We would need to expand the rules that you must also check
>     the your addresses in a COOKIE-ECHO to see if you have
>     hit such a collision.. if so send an ABORT... 
> 
> I don't see this is a problem.. ABORTING your funny association
> with E3 should leave A2 alone and all should be well.
> 
> It seems to me we need to add this new rule for ADD-IP.
> 
> R
> 

 [ Sandeep ] Actually this type of rule bring out various possiblities.
Please consider below : 

Let assume the same example given by Q : 

      E1             A1     E2
 [IPA,IPB:Port1] <-------> [...]
     E1             A2     E3
 [IPA,IPB:Port1] <-------> [IPZ:Port2]
 
 We do add-ip (IPC) to E1. After sending ASCONF to both E2 and E3, we
 succeeded with E2 but failed on E3.

     E1'               A1'     E2
[IPA,IPB,IPC:Port1] <-------> [...]
     E1'               A2'     E3
[IPA,IPB,IPC:Port1] <-------> [IPZ:Port2]  /* E3 rejected add-ip and */

Now as we are adding the IP addresses on Endpoint basis there are more
collision cases in these sceinarios : 

Scenario 1) 
============== 
1) U  have an Endpoint E1 [ IPa, IPb, Port1 ] with Assocations A1, & A2. 
2) Then u receive another INIT chunk for endpoint E1, U send INIT-ACK[ with
IPa, IPb ] to for Assoc A3. 
3) In the mean time u receive COOKIE-ECHO back from A3, lets say we receive
ADDIP for Endpoint E1 to add another IP address IPc, Now We add IPc in E1
and send ASCONF chunk to A1. 
4) After this step lets say we receive COOKIE-ECHO with from A3 and in worst
case our association will be established with subset of address IPa, IPb,
which was not intended. 

Sceinario 2) 
=============
1) U  have an Endpoint E1 [ IPa, IPb, Port1 ] with Assocations A1, & A2. 
2) Then u receive another INIT chunk for endpoint E1, U send INIT-ACK[ with
IPa, IPb ] to for Assoc A3. 
3) In the mean time u receive COOKIE-ECHO back from A3, lets say we receive
DELETEIP for Endpoint E1 to delete address IPa, Now We delete IPa from E1
and send ASCONF chunk to A1. 
4) After this  lets say we receive COOKIE-ECHO with from A3 and if i apply
Randall's rule i will be sending ABORT for this association A3, Which also
was not intended. 

umm ... there may be some more cases left ...... But is'nt there any
simple/clean solution for all this  ??????

thanks
sandeep 

> -- 
> 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: Mon, 29 Apr 2002 18:05:40 -0500

Sandeep:

comments below

> collision cases in these sceinarios :

Why would you do this? You just added IPc to your E1.. you would
send an INIT-ACK with [IPa,IPb and IPc]... however if you are
saying it is inbetween.. i.e. you send the INIT-ACK and
THEN IPc is added.. yes that can happen and in such a case
I believe you must look at the cookie and recognize you must
do a ADD-IP on the IPc.. I think you will find this is what our
BSD code does :>

> and send ASCONF chunk to A1.

Ok.. 

and then you would also queue up the ASCONF for the A2 and A3..

> case our association will be established with subset of address IPa, IPb,

But you MUST look at the cookie echo and when you unpack it figure
out that you are missing an address.. I believe Peter put in
a whole module that handles this very race condition.. its part
of coding ... you have to try to cover the corner cases :>>

> Sceinario 2)

I am not convinced now we need a rule for it.. I will follow up
in another email... 

Now back to the example (forget my half-baked idea.. I have baked
it some more and don't like it :>) above you would realize (at unpack)
that you need to send a DELETE-IP.

> simple/clean solution for all this  ??????

I will follow up .. after reading some more of the queued emails :-)

There is a big piece we have forgotten in this discussion that makes
it so we DO NOT need a rule like I earlier proposed in my 1/2 baked
thoughts...

R