Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Mon, 10 Mar 2003 23:13:23 +0200

Brian,

> 
> Ivan,
> 
> I don't know that I agree with 2.6 yet...

	We finally agreed that the peer is not "able to establish associations in certain circumstances"... My mother tongue is not English, but I understood that from your "at very minor expense of this one unnecessary corner case [the INIT collision]" in one of your mails...

> Consider your last case.  If Interface C is unreachable
> from A, and following 2.6 and sending the INIT-ACK to C
> instead of D, the association will fail to form.
> 
> INIT A:1000->C:1000              INIT D:1000->A:1000
> ----------------------\     /-----------------------
>                        \   /
>                         \ /
>                         / \
>                        /   \        C unreachable
> <---------------------/     \--------------X
> 
> INIT-ACK A:1000->C:1000             C unreachable
> ------------------------------------------>X
> 

	And if C is unreachable, why including it in the INIT? Ok, let's say that SCTP doesn't know about the state of the interfaces...

> Following RFC 2960, the association would form regardless
> of whether C was reachable from A.
> 
> INIT A:1000->C:1000              INIT D:1000->A:1000
> ----------------------\     /-----------------------
>                        \   /
>                         \ /
>                         / \
>                        /   \        C unreachable
> <---------------------/     \--------------X
> 
> INIT-ACK A:1000->D:1000                    
> ---------------------------------------------------->
>                            COOKIE-ECHO D:1000->A:1000
> <----------------------------------------------------
> COOKIE-ACK A:1000->D:1000
> ---------------------------------------------------->
> 
> Section 2.6 appears to sacrifice reliability in the INIT
> process by treating all interfaces except the interface
> that A has sent an INIT to as though they were an attacker.

	It seems that the case of INIT collision AND an unreachable (but still included in the list of valid addresses) is more probable than the case of INIT collision AND... nothing else... :-/

> Is it the intention of 2.6 to sacrifice this collision case
> if interface C is temporarily unreachable?

	Come on, Brian, you are sacrificing the other more general case... your implementation works in this case, but not in the other, so?

	Or... let me see... hmmm... I *think* this is actually what your implementation does (I might be wrong):

Host A                                                              Host C/D
                                                                   
TCB     \   INIT VT:0 IT:W                      INIT VT:0 IT:X   /  TCB
A:1000   \  A:1000->C:1000                      D:1000->A:1000  /   C,D:1000
C:1000    \                                                    /    A:1000
VTloc:W    \                                                  /     VTloc:X
VTpeer:0    \                                                /      VTpeer:0
C-WAIT       \                                              /       C-WAIT
              \--------------------\  /--------------------/
                                    \/
                                    /\
                                   /  \
   (1)  <-------------------------/    \-------------------------> X

        \   INIT ACK VT:X IT:Y
         \  A:1000->D:1000
          \ VTloc:Y VTpeer:X
           \TTloc:0 TTpeer:0
            \
             \
              \--------------------\
                                    \
                                     \
                                      \
                                       \------------------------->

                                              COOKIE ECHO VT:Y   /  TCB
                                                D:1000->A:1000  /   C,D:1000
                                              VTloc:Y VTpeer:X /    A:1000
                                              TTloc:0 TTpeer:0/     VTloc:X
                                                             /      VTpeer:Y
                                                            /       C-ECHOED
                                      /--------------------/
                                     /
                                    /
                                   /
  (2)  X<-------------------------/

	At (1) your implementation as usual doesn't recognized the peer and sends an INIT ACK with a new IT.

	At (2), the VT doesn't help you to find any TCB. However, there is already a conflicting TCB... I think there are two possibilities:

	a) If you go through the address list inside the COOKIE, you will find it, but, since none of the VT match and the Tie Tags are set to 0, you discard it. Bad, the association doesn't come up...

	b) You create a new TCB (and send back a COOKIE ACK not included in the drawing), and then you take a look to the other existing TCBs (you must do this, otherwise you take the risk of having two conflicting established associations) and you see one in conflict. So, you happily decide that this new TCB "includes" the old one, and you tell to the upper user that its association with C is established. Everything looks perfect.
	However, so far Host C/D has not proven at all that it owns address C. Conclusion? Much worse. Host A thinks that it is speaking with C, while he could be speaking with an attacker that simply included address C in the list. This possibility needs: 1) either the adapter C is broken or at least the INIT from Host A is delayed enough time, 2) the attacker knows you are about to connect with C.
	You have insisted that these scenario is possible (and even more, you were scared about the possibility of not only all this happening, but also trying to connect with the "real" C and with the attacker, D, at about the same time). I hope you don't say now that this is an extreme corner case, since yours was even more weird.

	So, which option does your implementation choose, the bad or the worse?

> Our current implementation does not sacrifice this case

	As I think, it sacrifices both, or it is open to attacks... As I said above, I might be wrong as well... it is late and I'm tired... :-0

> (or the case where C is reachable) if D is supplied to
> connect().  The current implementation sacrifices the cases
> where D is not supplied to connect().

	See above...

> For applications that can have a knowledge of D (e.g. from
> DNS lookup or static assignment) and requires a reliable
> INIT process our current implementation is superior to

	Now that I think about it... I think this could be an improvement for the INIT collision scenario... We could say that instead of sending the INIT ACK to the destination address of the previously sent INIT, we could use any of the "known addresses". The point is that the RFC always considers that you only know one of the peer's addresses... But this change would be completely equivalent and more general. However, I don't know in how many places the RFC takes for granted that while in the COOKIE WAIT state you know only one of the peer's addresses... :-/

> IG 2.6.  Where the application has no knowledge of D and
> does not care about a reliable INIT process, 2.6 is superior
> to our current implementation.

	See above...

> Is this not a tradeoff that depends on the application?

	See above...

	BR Iván Arias Rodríguez

> --brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 10 Mar 2003 17:06:54 -0600

Ivan:

One or two minor points I will add below :>

>	It seems that the case of INIT collision AND an unreachable (but still included in the list of valid addresses) is more probable than the case of INIT collision AND... nothing else... :-/

One little addition.. consider the case where you just send to C.. with 
it down and
no INIT collision is occuring.. guess what? You have the same problem...

>A:1000   \  A:1000->C:1000                      D:1000->A:1000  /   C,D:1000
Yes, that would be completely consistent with what the IG is attempting 
to do.. I think for
the next pass this little tweak in wording is probably ok... and then 
would allow (if you
knew any other by whatever means) to use it... When we did the telcom 
geneva show
with our proto-type rserpool implementation we had all the addresses 
registered.. so
if an endpoint could not initialize to "C" then when it failed the ULP 
(ASAP) could
re-init to "D"... of course if there was an alternate that might be 
prefereable.. since
C/D is already running degraded (at least from A's  perspective)...

I do have to give Brian credit. He is like the man that screams if a flame
is brought into the house, his whole house will catch fire.. so we MUST
have protection from this fire... then in the next breath screams
 I am cold we MUST  have fire in the house now... :->

I don't know who he is trying to fool... all that he wants is to make what
he is doing in his implementation what is specified... and this is just
not going to happen. Has it is, we have seen through this discussion he
is not following the current RFC2960's requirment to respond to
an INIT (in COOKIE-WAIT state) with the same Initiation Tag... (the very 
section
he is complaining about that the IG is changing above)...

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, 10 Mar 2003 16:42:30 -0700

Randall,

On Mon, 10 Mar 2003, Randall Stewart (cisco) wrote:

> One little addition.. consider the case where you just send to C.. with it
> down and no INIT collision is occuring.. guess what? You have the same
> problem...

Our implementation allows the ULP to send an address list to connect().
In this case (C,D).  If the INIT times out on C, the implementation will
send INIT to D.  This makes the INIT process reliable in the case where
C/D is listening and C is unreachable.  So our implementation handles the
non-collision case as well.

> he is complaining about that the IG is changing above)...

You comments above are an example of the personal attacks and innuendos....

Please do not make remarks about my motives or character and focus on
the technical issues involved.

--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, 10 Mar 2003 18:18:36 -0600

>non-collision case as well.

And I think Ivan's proposed wording covers that case just fine... IMO it
is good for some applications but not suitable for a general purpose
stack...

>You comments above are an example of the personal attacks and innuendos....
Well, why do you argue out of both sides of your mouth.. pick a 
direction and
stick with it .. it becomes real hard to tell where you are sincere when you
will send out conflicting emails.. its one thing if you said:

Gee, I just realized that if we take care of that security issue I was
concerned about it breaks this situation..

But I never see this from you.. if you have a change of opinion then
please so note it.. don't try to argue both sides of an issue admit you
have a change of mind if you do... otherwise you are making
a inuendo that we are stupid and can't see what you are attempting
to do...

Stop the personel attacks and inuendos that you put towards Ivan, 
Caitlin and
myself and you will see all of us treat you the same way...

>the technical issues involved.

I have always focused on the technical issues.. even though you have
repeatedly attacked any postion I have taken.. to quote one of your
previous email as a sample "I am not anti-SCTP, I am anti-Randall"....

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Mar 2003 17:27:33 -0700

Ivan.Arias-Rodriguez,

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

> 	It seems that the case of INIT collision AND an unreachable (but still
> 	included in the list of valid addresses) is more probable than the
> 	case of INIT collision AND... nothing else... :-/
> 
> 	Come on, Brian, you are sacrificing the other more general case...
> 	your implementation works in this case, but not in the other, so?
> 

Ivan, our implementation works in both cases if A supplies address C and D
to the connect().

> A:1000   \  A:1000->C:1000                      D:1000->A:1000  /   C,D:1000

This is where the difference is, when (C,D) is supplied to connect() in
our implementation, the TCB starts out as:

  Host A                                                              Host C/D
                                                                     
  C:1000,D:1000                                                  /    A:1000

TCB is found (A:1000-D:1000) without looking at source address (D is already
in the TCB as a "known address").
  
          \   INIT ACK VT:X IT:W
           \  A:1000->D:1000
            \ VTloc:W VTpeer:X
             \TTloc:0 TTpeer:0
              \
               \
                \--------------------\

This INIT-ACK is completely compliant with RFC 2960.  It includes the IT of
the existing TCB and it is sent back to the source of the INIT.  By telling
SCTP that D is trustworthy, fully compliant RFC 2960 behaviour is accomplished
without vulnerability.

                                      \
                                       \
                                        \
  
                                                COOKIE ECHO VT:W   /  TCB
                                                  D:1000->A:1000  /   C,D:1000
                                                VTloc:W VTpeer:X /    A:1000
                                                TTloc:0 TTpeer:0/     VTloc:X
                                                               /      VTpeer:W
                                                              /       C-ECHOED
                                        /--------------------/
                                       /
                                      /
                                     /
    (2) <---------------------------/
        \
         \  VT matches, action B from Table 2
          \
           \
            \  COOKIE-ACK
             \----------------------------------------------------->
> 	sends an INIT ACK with a new IT.

When (C,D) are provided to connect(), the TCB is found as above and RFC 2960
compliant behavior is exhibited.

> 
> 	At (2), the VT doesn't help you to find any TCB. However, there is
> 	already a conflicting TCB... I think there are two possibilities:

When (C,D) is provided to connect(), there is only ever one TCB.

> 
> 	a) If you go through the address list inside the COOKIE, you will find
> 	it, but, since none of the VT match and the Tie Tags are set to 0, you
> 	discard it. Bad, the association doesn't come up...

The TCB is found on address D because (C,D) was provided to connect().
It is unnecessary to use C from the source address list.

> 
> 	b) You create a new TCB (and send back a COOKIE ACK not included in

Not, when (C,D) is provide to connect().  Look more closely at the above.

> 	the drawing), and then you take a look to the other existing TCBs (you
> 	must do this, otherwise you take the risk of having two conflicting
> 	established associations) and you see one in conflict. So, you happily
> 	decide that this new TCB "includes" the old one, and you tell to the
> 	upper user that its association with C is established. Everything
> 	looks perfect.  However, so far Host C/D has not proven at all that it
> 	owns address C. Conclusion? Much worse. Host A thinks that it is
> 	speaking with C, while he could be speaking with an attacker that
> 	simply included address C in the list. This possibility needs: 1)
> 	either the adapter C is broken or at least the INIT from Host A is
> 	delayed enough time, 2) the attacker knows you are about to connect
> 	with C.

> 	You have insisted that these scenario is possible (and even more, you
> 	were scared about the possibility of not only all this happening, but
> 	also trying to connect with the "real" C and with the attacker, D, at
> 	about the same time). I hope you don't say now that this is an extreme
> 	corner case, since yours was even more weird.

I agree that being unable to form a connection when an inteface is unavailable
is more rare than the collision case.  But Randall told me that the collision
case was common.  Which is it?  I think that the probability of any vulnerability
case is dependent upon the application and what the attacker does.  Otherwise
why would we spend so much time talking about corner cases?

Besides, mission critical applications that have a high cost associated
with failing to make connections and require 5 or 6 nines of availability
cannot afford to have the INIT process fail because one interface is
temporarily unreachable.  Our implementation is indeed intended to work in
these environments.  It appears that 2.6 is not.

> 	So, which option does your implementation choose, the bad or the worse?

In our implementation, the cost of forming the connection in all circumstances
is having the ULP supply the list of "known addresses" to the connect() command.

> 	As I think, it sacrifices both, or it is open to attacks... As I said
> 	above, I might be wrong as well... it is late and I'm tired... :-0

Yes, I believe you have it wrong, take a look again above.

> 	Now that I think about it... I think this could be an improvement for
> 	the INIT collision scenario... We could say that instead of sending
> 	the INIT ACK to the destination address of the previously sent INIT,
> 	we could use any of the "known addresses". The point is that the RFC
> 	always considers that you only know one of the peer's addresses... But
> 	this change would be completely equivalent and more general. However,
> 	I don't know in how many places the RFC takes for granted that while
> 	in the COOKIE WAIT state you know only one of the peer's addresses...
> 	:-/

I don't see how this is so different from what our implementation does.  It
allows the ULP to provide a list of "known addresses" to the connect().  This
allows the connection to be formed in both circumstances.  It then also
conforms to RFC 2960 behaviour (it sends the INIT-ACK to the source of the
INIT).  Also, it provide a list of addresses that SCTP can try to send an INIT
to if the first INIT illicits no INIT-ACK (the case where C/D is listening
but C is unreachable).

If 2.6 permits me to send the INIT-ACK to any of these "known" addresses, then
our implementation doesn't need to look in the source address list in the
collision case because it can require the user to provide the list of "known"
addresses and in fact does would not need to be changed to comply with 2.6.

--brian