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

From: "Khan, Mohammad" <[email-masked]>
Date: Wed, 24 Apr 2002 22:54:49 -0700

Hi Arun,
Now to control ur source IP address considering the case for generic
solution across all the OS where few OS do not guarantee whether the header
source address shall remain same or not. In this scenario SCTP has to
maintain the status of all local interface addresses. Even if SCTP does so
should SCTP take decision on Association Status based on this local
interface address status.
Regards
kashif

-----Original Message-----
From: Arun Prasad [mailto:[email-masked]]
Sent: Wednesday, April 24, 2002 10:28 AM
To: Balani, Sandeep
Cc: 'Randall Stewart'; 'Qiaobing Xie'; Khan, Mohammad; [email-masked]
Subject: Re: [Tsvwg] End point and association Address conflict

hi sandeep,

"Balani, Sandeep" wrote:

> Thanks Randy & Qiaobing,
>   Although i would like to add something here.
>
> So the inference of this discussion is : The source IP Addresses in an
> association can be subset of Endpoint addresses.   Is this statment
correct
> ?
>
> In the above case an Implmentation "MUST" make sure that whatever source
IP
> addresses are communicated during association intialisation should be used
> while sending outoing packets. ( I.e. control U'r Src IP Addresses )
>

    Yes thats true, but its not always that easy to implement ie., if we
implement
a generalised SCTP stack, covering many OS... then its really tough to keep
track
of this feature (full control of Src IP Addresses) in the OS....
for example:
    Windows 2000 supports IP_HDR_INCL option ( ie., adding our own Source
Ip Addresses) in its raw socket implementation, but it doesnt guarentee that
the
Src address filled by the user will be going in the IP Packet sent from that
machine...
In this case the subset concept will fail.....
But for Linux, the OS guarentees the source Ip Address given by the user
will be
filled in the IP packet sent.....
So Its more of the OS dependent... (and the OS can change this
implementation
any time....) ... The thing is, we should have a generalised API for Raw
sockets, as
we have for other protocols (like TCP, UDP etc...)

>
> Also to extend the same logic, In the example I have shown below If i
> terminate Association A1, I should also delete the entry of IP-C address
in
> Endpoint E1 Correct ?????
>

>
> Lastly this may never be TRUE but I would like to ask this question
anyways.
> In the example below I did'nt communicated IP-C on Association A2, But
Lets
> take a wild case that somehow I receive a SCTP packet on [ IP-C, Port-X,
> D2, Port-P2] then SCTP will accept this Packet Is'nt it ?  As u will find
> endpoint valid & Association  also .
>

    The Receiving endpoint will search the Association for which the packet
has
come with the following parameters { SrcAddr, SrcPort, RemAddr, RemPort}
In the above case since the SrcAddr is a different one (that is not in the
Association's
pool) the received packet will not hit on the Association A2...
So no probs....

Thanks
-arun

>
> Thanks
> Sandeep
>
> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 5:46 PM
> To: Balani, Sandeep
> Cc: 'Qiaobing Xie'; Khan, Mohammad; [email-masked]
> Subject: Re: [Tsvwg] End point and association Address conflict
>
> The same scenario could exist outside of addip..
>
> If I bind-all addresses.
>
> setup an assocation (with IP-A/IP-B .. the ones I have)
>
> now we hot-plug in a card.
>
> I now setup a second association with all the
> addresses I have (now IP-A/IP-B and IP-C).
>
> You end up in the same place.. .and you must,
> as Qiaobing said, assure that you only use IP addresses
> that the peer knows about for sources..
>
> Our ADDIP/DEL-IP allows this to happen as well.. we make
> it so the user has to disable auto-asconf though to reach this state.
>
> R
>
> "Balani, Sandeep" wrote:
> >
> > Hi Qiaobing,
> >     I think the reason for asking such question was we have ADDIP &
> DELETEIP
> > procedure on an Association.
> >
> > Now Assume we have an Endpoint
> >
> > E1 =  [ IP-A, IP-B, and Port-X ] .
> >
> > Now lets say i have 2 associations on endpoint E1.
> >
> > A1 = [ Endpoint-E1 , DstAddr= D1, DstPort-P1 ]
> > A2 = [ Endpoint-E2, DstAddr=D2,  DstPost-P2 ]
> >
> > Now when i do an  ADDIP [ for Address IP-C ] on association A1, actually
i
> > am adding a source  IP address in Endpoint E1 i.e. [ IP-A, IP-B, IP-C,
> > Port-X ], so that I will find an Endpoint for an incoming packet.
> >
> > But IP-C is only used by Association A1, Not by A2.  That's the reason
we
> > have an Association using Subset of IP addresses from an Endpoint.
> >
> > My Question is : Is it the intended behaviour in ADDIP/DELETEIP case
????
> >
> > Many thanks
> > sandeep
> > -----Original Message-----
> > From: Qiaobing Xie [mailto:[email-masked]]
> > Sent: Tuesday, April 23, 2002 7:50 AM
> > To: Khan, Mohammad
> > Cc: [email-masked]; Pillai, Hari
> > Subject: Re: [Tsvwg] End point and association Address conflict
> >
> > Hi, Kashif,
> >
> > Yes, you are allowed to do so, as long as you can guarantee that this
> > endpoint will never use Z as the source IP address in any packet sent
> > over this association. This is not hard to prevent if the endpoint has
> > full control over the source IP address selection routine.
> >
> > -Qiaobing
> >
> > "Khan, Mohammad" wrote:
> > >
> > > Hi All,
> > > I have following querry regarding endpoint and association source
> > addresses.
> > >
> > > Suppose an Endpoint has three addresses X, Y and Z.
> > >         An association which uses this endpoint and specifies only X
and
> Y
> > > addresses as source IP addresses. Is it allowed?
> > >
> > > Regards
> > > kashif
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/tsvwg
> >
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> >
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
>
> --
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.

Contact # : 9144 - 2334174
            9144 - 2334181
            extn : 233
****************************************************************

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

---

From: "Balani, Sandeep" <[email-masked]>
Date: Thu, 25 Apr 2002 15:28:38 -0700

hi all, 
 
My comments inline, 
  
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, April 25, 2002 3:07 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Tsvwg] End point and association Address conflict

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

	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

---

From: "Balani, Sandeep" <[email-masked]>
Date: Fri, 26 Apr 2002 10:06:48 -0700

my comments..

-----Original Message-----
From: Randall Stewart [mailto:[email-masked]]
Sent: Friday, April 26, 2002 9:45 AM
To: Balani, Sandeep
Cc: [email-masked]; [email-masked]; Khan, Mohammad;
[email-masked]

"Balani, Sandeep" wrote:
>   My comments inline...
> -sandeep
> Sent: Friday, April 26, 2002 6:31 AM
> To: [email-masked]
> >         Hi Sandeep!
> >         See my comment inline...
> >         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...
> 
> 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...
> 
> [ Sandeep ]   Can we delete an IP address from an Endpoint first & then
> delete It from Association. According  to the procedure, Between the time
we
> have send ASCONF( Delete IPb) & the time we receive ASCONF-ACK(Delete IPb)
> we should accept all packets destined to IPb ????
> 

I would think it would be ok.. remember the Endpoint is only
used for basic things like new assocaitions... the actual
"what addresses are in the association" can be kept in association
specific instances...

[ Sandeep ] I probably don't understand this point.  But i don't agree with
this 100%.  
This may be very implemenataion specific but For all incoming DATAGRAM i
should check if the Endpoint exist or Not, If Endpoint does not exist i will
not proceed .. So in case i deleted the IPb Address from the Endpoint, I
will never be able to accept the packet for that association which has IPb
in its source address. 

Moreover i think that its illegal to have a Source Address not present in
Endpoint & present in Association ( if that's the case ) ???  

> Also deleting an IP address from an Endpoint means, Deleting it from
> multiple associations simultaneously ( Or One-By-One ) , What if on One
> association  this DeleteIP procedure fails ???

Well.. I don't see an issue.. so you are stuck with a deleted IP address
in your assocaition. 

A) Chances are you won't receive packets on it (since it is off the
   machine).

B) If it is NOT off the machine your code STILL should work in that
   it had better be keeping a list of addresses on the association that
   are valid... (when there is a deviant case such as this).

> 
> This may be prevented if We can put such recommendation which Randall
> indicated in earlier mail, I.e. DELETEIP procedure is only recommended in
> cases when NIC card assocaited with that Ip address is actually going
down.
> In that case we have to remove IP address from  Association & Endpoint .

Yes.. but you still can end up with a IP address stuck in your
association if the peer does not do ADD-IP.. 

> 
> I am really not sure whether the statment I made in previous mail should
be
> assumed TRUE/Correct  : "  An Association Can Use SUBSET of IP Addresses
> from its Endpoint ".
> 
> What do u guys think ??????

I think you CAN do this but it WILL cause you grief.. if by using
a subset you are saying making a decision that I am NOT going
to include IP-C in my address list (even though it is reachable
and should have normally been included).

R

---

From: Tuexen Michael <[email-masked]>
Date: Mon, 29 Apr 2002 14:24:30 +0200

Brian,

looking at the RFC I say that RFC 2960 uses the
definition I have posted before. But that is my
understanding, you can have a different one. 

I think you are implying to much from the term
end point used in natural language. Look at it as
a technical term 'SCTP end point' as only defined in RFC
2960.

This only indicates that there might be some clarification
necessary in the impl. guide.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CC SE 7    E-mail: [email-masked]

> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Monday, April 29, 2002 2:16 PM
> To:	Tuexen Michael
> Cc:	Qiaobing Xie; Balani, Sandeep; 'Qiaobing Xie'; [email-masked]; [email-masked]; Khan, Mohammad; [email-masked]
> Michael,
> You may as well let the RFC talk for itself, then.
> 
> --brian
> 
> On Mon, 29 Apr 2002, Tuexen Michael wrote:
> 
> > Brian,
> > 
> > I'm talking ONLY about an 'SCTP endpoint', as being defined in
> > RFC 2960. I agree, that the term endpoint is used with a lot
> > of meanings in natural language. I'm using it not implying any
> > other meaning (for example for TCP or so), it is just a term
> > defined in RFC 2960. 
> > 
> > I do understand your examples and I only say that the notion 
> > defined in RFC 2960 does not apply to them in a way you are using
> > them. 
> > 
> > Maybe you think that is the wrong notion, but I think that is the 
> > one used in RFC 2960 and the extension IDs. Since it is necessary
> > to use the same one, Randy or Qiaobing could state which one they
> > had in mind when writing the RFC. Then we can all use the same.
> > 
> > Best regards
> > Michael
> > Michael Tuexen    Tel.:   +49 89 722 47210
> > Siemens AG        Fax:    +49 89 722 48212
> > ICN WN CC SE 7    E-mail: [email-masked]
> > 
> > > From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> > > Sent:	Monday, April 29, 2002 1:31 PM
> > > To:	Tuexen Michael
> > > Cc:	Qiaobing Xie; Balani, Sandeep; 'Qiaobing Xie'; [email-masked]; [email-masked]; Khan, Mohammad; [email-masked]
> > > Michael,
> > > Please see comments below...
> > > 
> > > On Mon, 29 Apr 2002, Tuexen Michael wrote:
> > > 
> > > > > On Mon, 29 Apr 2002, Tuexen Michael wrote:
> > > > > 
> > > > > > Hi Brian,
> > > > > > 
> > > > > > if a host A has two IP-addresses IP' and IP'' and two associations
> > > > > > from (IP', Port) to a peer (IP, Port) and (IP'', Port) to the peer
> > > > > > (IP, Port) then 
> > > > > > - host A has two IP-addresses
> > > > > > - there are two end-points (IP', Port), (IP'', Port), each of them
> > > > > >   uses only one IP address available at host A.
> > > > > > This 'splits' (in your terminology) host A into two end points.
> > > > > > The difference between IP addresses of the end point and IP addresses
> > > > > > of the host is also the reason why it is valid to say
> > > > > > - you MUST include all IP address of the end point in the INIT INIT-ACK.
> > > > > > - you include a subset of all addresses of the host in the INIT INIT-ACK.
> > > > > 
> > > > > Why do you call (IPA, Port) one endpoint?  I view an endpoint as
> > > > > half an association.  When two associations are formed from (IPA, Port),
> > > > > there are two endpoints, not one.  When adding IPB and IPC and can
> > > > > add IPB to one endpoint to form (IPB, IPA, Port) and IPC to another
> > > > > to form (IPC, IPA, Port).  Why restrict this?  Particularly if that is
> > > > > the way I would have bound them if IPB and IPC where available in the
> > > > > first place?
> > > > 
> > > > [Tuexen Michael]  I think we are not using the same definition of end> 
> > > > point. I'm using an abstract one based on RFC 2960. 
> > > > Def.: An SCTP end point is a pair of a set of IP addresses and a port
> > > >       number.
> > > 
> > > We all agree that an endpoint is a set of IP addresses and a port.  This
> > > does not say that an endpoint is a unique set of IP addresses and a
> > > port.  The cardinality of endpoints is not defined.
> > > 
> > > > This means, considering a server, I have only one end point for the
> > > > server.
> > > 
> > > Your interpretation.  I have given an example where more than one server
> > > can service the same endpoint.  This is typical and true even for TCP
> > > (where multiple HTTP servers, for example, service the same IP/Port).
> > > 
> > > > Mulitple clients can conncect to the server.  These associations share
> > > > the same end point.
> > > 
> > > Depending on how one views the cardinality of endpoints, these
> > > associations can be viewed as connecting to different endpoints (even
> > > though those endpoints were orginally bound to the same IP...IP/Port,
> > > that is they had the same name).
> > > 
> > > > 
> > > > This definition is in tune with the sentence "Two SCTP end points MUST
> > > > not have more than one SCTP association between them at any time
> > > > given" RFC 2960, page 13, defintion of SCTP association.
> > > 
> > > This gives no clues as to the cardinality of endpoints.  It only states
> > > the cardinality of associations.
> > > 
> > > > 
> > > > Using your definition as an end point is "half of an association" The
> > > > sentence cited abover would be trivial.
> > > 
> > > The sentence above is what makes an endpoint half an association...
> > > 
> > > > 
> > > > That is why I'm still thinking that my notion of SCTP end point is the
> > > > one the authors of RFC 2960 had in mind.
> > > 
> > > Endpoint has had far more before RFC 2960.  An endpoint for
> > > communication is the full duplex communications endpoint which occurs at
> > > either end of the association.  When we bind and endpoint (give it a
> > > name) we associate the IP...IP/Port with the endpoint.  When we connect
> > > an association, we form a unique connection to another endpoint.  That
> > > endpoint also has an name: IP...IP/Port, but we only contact it using
> > > one IP address.
> > > 
> > > Just as with TCP, if we make an active connection from an endpoint only
> > > (that is, we are not listening) then multiple sockets/streams can be
> > > bound (named) with the same IP...IP/Port combination.  In fact, with
> > > dynamic port allocation, IP/Port combinations are reused on TCP every
> > > day between multiple connecting TCP endpoints (sockets/streams) that
> > > have no clue that the magic port number `0' has yeilded the same IP/Port
> > > combination as another TCP endpoint (socket/stream).
> > > 
> > > This is also the case of SCTP.  I have two sockets which I have bound
> > > to IPA/IPB/Port`0'.  I connect from one socket to Host B and the
> > > implementation assigns me port 10000.  I connect from the other socket
> > > to Host C and the implementation also assigns me port 10000  (knowing
> > > that there is no conflict because one IPA/IPB/Port10000 socket is
> > > connected to HostB and the other IPA/IPB/Port10000 socket is connected
> > > to HostC).  Now how can you call these the same endpoint?
> > > 
> > > --brian
> > > 
> > > > 
> > > > Best regards
> > > > Michael
> > > > 
> > > 
> > > -- 
> > > Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> > > [email-masked]    ¦ world; the unreasonable one persists in  ¦
> > > http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> > >                         ¦ Therefore  all  progress  depends on the ¦
> > >                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    > ¦>  worl> d; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦