Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Mon, 3 Mar 2003 20:31:14 +0200

Brian,

	snip...

> > 	Now, Brian, can you tell me how in Earth would you 
> recognize that INIT
> > 	from Host Z as coming from the same host you want to 
> connect with?
> > 
> > 	Of course, I mean WITHOUT taking a look to the 
> parameters of the INIT
> > 	chunk...
> 
> Collision cannot be detected until COOKIE-ECHO is received
> (RFC 2960 5.2.4 (B)).  One does not have to peer into the
> address list of the INIT or INIT-ACK to detect collision.

	You are completely right... You can detect it IF you have started to take measures WHEN answering the INIT chunk. See section 5.2.1 and 5.2.2 (and the modifications included in the Implementer's Guide for these sections), you behave differently if the INIT chunk comes from a known peer or not... things such as using the same VT in the INIT ACK than the one you used in your previously sent INIT, populating or not the Tie-Tags, etc...

	Come on, Brian, I know that you know A LOT about SCTP, so you should perfectly know this... why did you make this comment? don't you have any better answer?

> > > > 	Because, I don't see how are you going to populate the 
> > > Tie Tags or
> > > > 	not, if you don't know if the INIT comes from an 
> > > already established
> > > > 	(but crashed) association (or one that it is being 
> > > formed, i.e., INIT
> > > > 	collision)...
> > > 
> > > You didn't read what I wrote in the last note.  The 
> > > destination address and
> > > port numbers are sufficient to find the existing TCB from 
> > > which the tie tags
> > > are populated.  It is not necessary to dig the address list.
> > 
> > 	I cannot ask you this in a clearer way than written 
> above. Could you
> > 	please answer me to THIS question?
> 
> What has your question to do with lookin in address lists of INIT
> and INIT-ACK?

	:-0

	It seems that you simply want to waste our time... Don't tell me that you didn't understand what I was meaning... In any case, I copy it again here...

> 	I am Host A and I want to establish the following association with
> 	Host Z: (AddrA; PortA):(AddrZ; PortZ).
> 
> 	I send and INIT from (AddrA; PortA) to (AddrZ; PortZ).
> 
> 	Host Z happens to be multihomed. You DON'T know which are the
> 	addresses of Host Z. Knowing this is outside SCTP, and if you happen
> 	to know all the addresses of Host Z (in fact, of all the existing
> 	hosts you could ever have an association with) BEFORE you ever got an
> 	INIT or INIT ACK from Host Z, that's because you are in a SPECIAL
> 	situation. Period.
> 
> 	Host Z happens to have another address, AddrZ'. We are in an INIT
> 	collision scenario, and Host Z sends you an INIT from (AddrZ'; PortZ)
> 	to (AddrA; PortA). That INIT includes AddrZ inside a parameter.
> 
> 	Now, Brian, can you tell me how in Earth would you recognize that INIT
> 	from Host Z as coming from the same host you want to connect with?
> 
> 	Of course, I mean WITHOUT taking a look to the parameters of the INIT
> 	chunk...

	The INIT chunk coming from Host Z carries the information about AddrZ ONLY inside the INIT chunk as a parameter. That INIT comes from AddrZ', SO, you can only know that the host sending from AddrZ' ALSO uses AddrZ IF you take a look to those parameters inside the INIT chunk... Is it clear enough?. Once you know if the INIT came from a known source or not, you can construct the right INIT ACK to send...

	I imagine that you understood the idea some mails ago... And I think you are just trying to deviate the attention, so at the end we feel so tired of answering (and centering again the conversation) that we don't answer anymore, and it seems that "you won"... :-0

	BR Iván Arias Rodríguez

> --brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 11:45:07 -0700

Ivan.Arias-Rodriguez,

On Mon, 03 Mar 2003, [email-masked] wrote:

> 	You are completely right... You can detect it IF you have started to
> 	take measures WHEN answering the INIT chunk. See section 5.2.1 and
> 	5.2.2 (and the modifications included in the Implementer's Guide for
> 	these sections), you behave differently if the INIT chunk comes from a
> 	known peer or not... things such as using the same VT in the INIT ACK
> 	than the one you used in your previously sent INIT, populating or not
> 	the Tie-Tags, etc...
> 
> 	Come on, Brian, I know that you know A LOT about SCTP, so you should
> 	perfectly know this... why did you make this comment? don't you have
> 	any better answer?
> 
> 	It seems that you simply want to waste our time... Don't tell me that
> 	you didn't understand what I was meaning... In any case, I copy it
> 	again here...
> 
> 	The INIT chunk coming from Host Z carries the information about AddrZ
> 	ONLY inside the INIT chunk as a parameter. That INIT comes from
> 	AddrZ', SO, you can only know that the host sending from AddrZ' ALSO
> 	uses AddrZ IF you take a look to those parameters inside the INIT
> 	chunk... Is it clear enough?. Once you know if the INIT came from a
> 	known source or not, you can construct the right INIT ACK to send...

If by "known source" you mean a fully formed TCB exists, then the information
from the IP and SCTP headers is sufficent to identify the existing TCB.  It is
not necessary to look in the address list do this.

If by "rigth INIT ACK" you mean populating tie tags, then all that needs to
be known is whether a TCB exists or not.

There is no choice but to respond to both INITs.  All that needs to be
determined is whether a fully formed TCB exists or not.  The IP and SCTP
header information is sufficient to do this.  No need to look in the source
address list of the INIT.

> 
> 	I imagine that you understood the idea some mails ago... And I think
> 	you are just trying to deviate the attention, so at the end we feel so
> 	tired of answering (and centering again the conversation) that we
> 	don't answer anymore, and it seems that "you won"... :-0

Not at all.  Listen: one does not have to look in the address list of an INIT
or INIT-ACK ever.  The information in the IP and SCTP headers of the INIT and
INIT-ACK can always be sufficient to idenitfy whether there is an existing
fully formed TCB or not.

--brian

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Mar 2003 13:23:29 -0600

Ivan:

I, like you, am frustrated by Brian's failure to see the clear arguments
that You, Caitlin and I have made.

Brian seems to be in one of three catagories:

either:

A) So focused on his own specialized implementation (which has 
pre-knowledge of
     all possible peer addresses) that he can NOT understand the points 
we are making.

B) Just plain does not understand SCTP (this I just can't believe)

or

C) is just making trouble and wasting all of our time.

If its A), then no amount of bandwidth we dedicate to answering Brian 
will make
any difference.

If it is B), which I doubt, then Brian appears not to be listening so 
why waste
everyones time,

and if it is C).. well there is no sense in answering..

I think it is time to forget about Brian's disussion on this subject and
just ignore further posts ...

Otherwise we all will just keep wasting our time...

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 13:03:44 -0700

Randall,

Please show me a case where it is necessary to look in the source
address lists in the INIT or INIT-ACK.  It is not necessary in
Caitlin's example and it is not necessary in Ivan's.

With your wide knowledge of SCTP, can you provide a case where it
is necessary?  (Bear in mind that VT can be used to associate
INIT-ACK with INIT and pre-knowledge of peer addresses is not
necessary).

My point is that it is never necessary to look in the source address
list of the INIT, and with VT approach (fully under the control of the
implementation) it is never necessary to look in the source address
list of the INIT-ACK.

--brian

>      all possible peer addresses) that he can NOT understand the points 

Pre-knowledge of peer addresses is not necessary for proper operation
in Caitlin or Ivan's examples and it is still not necessary to scan the
source address list inside the INIT or INIT-ACK.

> will make any difference.
> 
> why waste everyones time,
> 

Please just provide a case in RFC 2960 where it is necessary to look
in source address lists in INIT or INIT-ACK (remember valid VT approach
for INIT-ACK), or remove the SHOULD from the IG on same.

Or could someone point out precisely where in Caitlin or Ivan's examples
they think it is necessary to look at source address lists (beyond the IP
header) for proper operation (remember VT approach)?

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Mar 2003 14:29:31 -0600

>implementation) it is never necessary to look in the source address

Brian:

We have all given you cases... once again I will give you one:

E-A                                                                      E-Z

1
------------INIT(IP-A,TagX) to:IP-Z from:IP-A------------------------->
        <-----------------------to:IP-A from:IP-Z' 
V-TagX:INIT-ACK(Vtag:Z, IP-Z,IP-Z')
2

At point 1 Endpoint A does NOT know any address but IP-Z for its
potential peer.

At point 2, yes you can lookup via hash the Tag X to find a endpoint
that sent a INIT recently, but you cannot find the TCB... Your code, I 
looked, will
do the hash and then compare its known addresses (remember its list
ONLY has IP-Z) to the incoming address IP-Z' .. and it will NOT match
and start looking through the alternative hash buckets.. and of course will
NOT find any.

The only reason your code would find the TCB is because you have
pre-stored IP-Z and IP-Z' in E-A's TCB that is forming with E-Z...
This is a specialized case ... yes I understand why you do it.. in a SS7
world this is very very valid to do.. but NOT in a general purpose protocol
stack which may hit any web server out in the Big I that may have any
number of addresses that are NOT listed anywhere...

Please think beyond your implementation.. or at least look what would
happen to your implemenation did not have IP-Z' listed in E-A's list of
addresses of the peer at the time the INIT-ACK arrives..

It just plain does not work.. This is besides all of the other corner type
cases.. they happen but, rarely, that Caitlin and Ivan have brought up.

I would not want to make the requirement to dig through the INIT/INIT-ACK
a MUST.. since this would exclude specialized implementations, like 
yours, making
use of a stricter set of requirements on the user for the sake of an 
optimization.. but for a general purpose
implementation we need to advise implementors to do this..

If you can't understand what I just wrote I am sorry.. I just don't have the
cycles to devote to this anymore..

R

At point 2, when the

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 15:39:21 -0700

Randall,

> and start looking through the alternative hash buckets.. and of course will

I don't know which of the three implementations you are looking at, but
both in the current LiS STREAMS and Linux 2.4.18 kernel implementations
INIT-ACKs are looked up on vtag in function sctp_lookup_vtag called from
function sctp_lookup.  sctp_lookup_vtag hashes on vtag only and matches
only on vtag and sport when configured for fast verification.

So, as you say above, it is not necessary to look in the source address
list when searching for a TCB, contrary to IG section 2.18.

> cycles to devote to this anymore..

Well, the answer to Vijay's question (that started this thread) is:

  1)  Yes, you can ignore the source address list when searching for the
      TCB contrary to IG 2.18 if you have other mechanisms (e.g. unique
      VT generation and lookup, pre-known source addresses, or any number
      of other techniques) to find the appropriate TCB.

  2)  Nothing bad will happen if you don't look in the source address list
      if you otherwise meet the requirements of RFC 2960.

In other words, IG 2.18 is just an implementation suggestion and an
inappropriate use of the keyword "SHOULD."

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Mar 2003 17:01:09 -0600

>      VT generation and lookup, pre-known source addresses, or any number
                                                              
^^^^^^^^^^^^^^^^^^^^^^

                                           and here is the relevant 
thing you MUST do in conjunction with
                                          Brian's method for this...

>      if you otherwise meet the requirements of RFC 2960.

Except you won't have a general purpose stack that can be used except in 
a very very
limited way..

R

Other tr

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 16:39:42 -0700

Randall,

> >      VT generation and lookup, pre-known source addresses, or any number

Wrong.  VT lookup is completely general.

There is no question that one needs to find the TCB, it is just not necessary
to use the source address list to do so.  VT lookup will do.

--brian