Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Tue, 11 Mar 2003 12:00:02 +0200

Brian,

> Ivan.Arias-Rodriguez,
> 
> On Mon, 10 Mar 2003, [email-masked] wrote:
> 
> > 	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):
> 
> Ivan, our implementation works in both cases if A supplies 
> address C and D
> to the connect().

	Of course!!

	And mine, and Randall's, and everybody's!

	This is NOT what we are discussing... You are saying that you don't have to take a look to the address parameters in ANY case... You fail to agree that knowing all the addresses beforehand is a need to avoid it...

	Of course I don't need to take a look to the address parameters in that case? Why? I already know what's inside!

	Brian, please, stop going around! I'm too tired of you saying something without proving anything, catching you and showing that what you were saying is not completely true and that it is based on some assumptions... and then you changing the topic again, and again, from one point of view to the opposite, and never admitting that *something* that you said might be wrong (I know your answer to this "I was never wrong")...

	So, as we were speaking about that case, DON'T CHANGE it again, please...

	This conversation is stupid... Of course if you know all the addresses since the beginning this case WON'T EVER happen. Please, Brian, stop changing your "problematic case" every time we find (or at least is seems so, we might be as well wrong) that such problematic case is not what seems to be, or that there is even a worse one that you didn't show...

	So, PLEASE, answer to what I write and don't change AGAIN the initial conditions...

> > 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
> >               \--------------------\  /--------------------/
> 
> This is where the difference is, when (C,D) is supplied to 
> connect() in
> our implementation, the TCB starts out as:

	Of course your implementation knows about the addresses... We have ALL this time saying that, of course, if you know the addresses in advance you don't need to take a look to them again... You don't even have to include them in the State Cookie... you already know them... you have already seen them...

> 
>   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,D:1000                                               
>    /    A:1000
>   VTloc:W    \                                                
>   /     VTloc:X
>   VTpeer:0    \                                               
>  /      VTpeer:0
>   C-WAIT       \                                              
> /       C-WAIT
>                 \--------------------\  /--------------------/
>                                       \/
>                                       /\
>                                      /  \
>      (1)  <-------------------------/    \-------------------------> X
> 
> 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.

	This is a DIFFERENT case to the one you initially proposed. Since you haven't found yet anything better to answer me, you just change the case...

	I have already seen that when you don't answer to something, it means that you admit that you might be wrong... Because, in any case, you basically never admit it...

> 
>                                       \
>                                        \
>                                         \
>                                          \------------------------->
>   
>                                                 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
>              \----------------------------------------------------->
> > 
> > 	At (1) your implementation as usual doesn't recognized 
> the peer and
> > 	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.

	My implementation is also able of doing so... and everybody's... The problem is that supplying all the addresses is not a MUST...

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

	Of course...

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

	Look more closely to your initial words and don't change them now... Brian, why being and engineer when you could be a politician? :-)

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

	He didn't say it was common... At least what I understood was that it wasn't uncommon, which doesn't mean the same as far as I know...

	Saying that there is a case where it used to happen, doesn't mean that it is common...

	But again, you are changing words... :-/

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

	That's precisely what I think... Just state that iff you provide the list of addresses you don't need to inspect the address list... otherwise... it is your own risk... it may work most of the times... but it may not work sometimes...

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

	Your application works?

	Please, tell me how it does so, WITHOUT knowing in advance the list of addresses... This is what you shown... You show the case, you say your implementation is better, and everybody claps... What you didn't say is that your implementation is better IFF you have MORE information than the other implementation... Of course then it is better... of course!

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

	So?

	Either you look at the address list or you know the addresses... But since you CANNOT know the addresses in advance in all the circumstances, you have to take a look to the addresses...

	The point of all this discussion is that you have to know all the addresses of the peer when you receive the INIT to be able to act consistently. You knew them before? Ok, don't look at them again, they are the same ones...

> > > 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
> 
> Yes, I believe you have it wrong, take a look again above.

	Same applies to you...

> > > (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...
> > 	:-/
> 
> I don't see how this is so different from what our 
> implementation does.  It

	But knowing the addresses before the peer tells you them is not a need... and most of the times it will be even impossible...

> allows the ULP to provide a list of "known addresses" to the 
> connect().  This

	It seems that the connect() at the socket API for SCTP only takes one address. I don't follow this API so I do whatever I want. However, I think that it would be a good idea to modify it so instead of providing a sockaddr_in or sockaddr_in6 you can provide a list of them...

	Randall? (I doubt that other authors of the API draft are following this loooong thread)

> 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

	If you already know all the addresses of the peer you don't have any problem at all... But knowing all the addresses of the peer is not possible in all the situations...

	BR Iván Arias Rodríguez

> > 
> > > 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
> 
> -- 
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Mar 2003 04:38:59 -0700

Ivan.Arias-Rodriguez,

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

2.6 tells me I MUST send INIT-ACK to the same place as the
INIT was sent regardless of which addresses were known in
advance.

My point was that by sending INIT-ACK to a known address
our implementation was better than 2.6 on this point in that
it provided reliable initialization.

So, yes, please change 2.6 to say "known" address rather
than the same place as the INIT was sent.  And please define
"known" address in the IG too.

But I still have a problem considering the source address
list when looking for the TCB on INIT as regards 2.6.

Consider the following case:

Host A

INIT A:1000 -> C:1000       INIT X:1000 -> A:1000 (C)
----------------------\    /------------------  Host X
                       \  /                             
INIT A:1000 -> X:1000   \/
----------------------\ /\
                       X  \-------------------> Host C
                      / \
                     /   \
<-------------------/     \-------------------> Host X
(1)                   

Assume that Host A has no "known" addresses for either of
its TCBs.  At (1), where is the INIT-ACK sent?  There are
two TCBs in the COOKIE-WAIT state that match the addresses.

INIT A:1000 -> C:1000        INIT D:1000 -> A:1000 (C)
----------------------\    /------------------  Host D
                       \  /                             
INIT A:1000 -> X:1000   \/
----------------------\ /\
                       X  \-------------------> Host C
                      / \
                     /   \
                    /     \-------------------> Host X
                   /    INIT-ACK X:1000 -> A:1000 (C)
<-----------------/---------------------------  Host X
                 /
<---------------/
(2)

At (2), where is the INIT-ACK sent?  There is one TCB in
the COOKIE-WAIT state that matches address C in the INIT,
and one TCB in the COOKIE-ECHOED state that matches C in
the INIT, neither match D.

INIT A:1000 -> C:1000        INIT D:1000 -> A:1000 (C)
----------------------\    /------------------  Host D
                       \  /
INIT A:1000 -> X:1000   \/
----------------------\ /\
                       X  \-------------------> Host C
                      / \
                     /   \
                    /     \-------------------> Host X
                   /    INIT-ACK X:1000 -> A:1000 (C)
<-----------------/---------------------------  Host X
COOKIE-ECHO      /
----------------/---------------------------->  Host X
               /                    COOKIE-ACK
<-------------/-------------------------------  Host X
             /
<-----------/
(3)

At (3) there is one TCB in the COOKIE-WAIT state that
matches address C in the INIT and on TCB in the COOKIE-ECHOED
state that matches D in the INIT.  What is done about
the INIT-ACK?  Is it discarded?  Is it sent to C?

Also consider n TCBs in various states, all that match
the address various addresses in the INIT.  What is done
with the INIT-ACK in these cases of multiple matches?

Also there is a vulnerability in the COOKIE-ECHO state
in a separate mail.

So, I don't know that I agree with 2.6.  That is why I
do not yet follow it.  I believe that it places too heavy
a reliance on a spoofable source address list in the INIT.

I am not convinced that ever considering the spoofable
source address list in an INIT or INIT-ACK is wise from
the standpoint of security.  Spoofing the source address
list is the easiest way to dream up vulnerabilities in
the INIT process.

A procedure which thinks that one TCB will exist for a
given source address list address has not considered
source address list spoofing, and is likely insecure.

See separate mail on COOKIE-ECHO state which exposes
a new vunlerabilty for that state based on INIT-ACK
source address list spoofing.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Mar 2003 04:50:00 -0700

Ivan, Randall,

Here is a new source address spoof (DoS and hijack) attack
on the COOKIE-ECHOED state.  2.6 does not have this correct
yet (and neither does the RFC).

IG Section 2.6

   Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
   respond with an INIT ACK using the same parameters it sent in its
   original INIT chunk (including its Initiation Tag, unchanged)
   provided that no NEW address have been added to the forming
   association. If the INIT message indicates that a new address(es)
   have been added to the association, then the entire INIT MUST be
   discarded and NO changes should be made to the existing association.
   An ABORT MUST be sent in response that SHOULD include the error
   'Restart of an association with new addresses'. The error SHOULD list
   the addresses that were added to the restarting association.

Host A/B                                       Host X   Host C/D
  |                                               |        |
  |INIT A:1000 -> X:1000                          |        |
  |---------------------------------------------->|        |
  |TCB1:                                          |        |
  |VT: X                                          |        |
  |PT: 0                                          |        |
  |Loc: A:1000                                    |        |
  |Rem: X:1000                                    |        |
  |State: COOKIE-WAIT                             |        |
  |                                               |        |
  |                  INIT-ACK X:1000 -> A:1000 (D)|        |
  |<----------------------------------------------|        |
  |(TCB1 is found)                                |        |
  |                                               |        |
  |COOKIE-ECHO A:1000->X:1000                     |        |
  |---------------------------------------------->|        |
  |TCB1:                                          |        |
  |VT: X                                          |        |
  |PT: W                                          |        |
  |Loc: A:1000                                    |        |
  |Rem: X:1000, D:1000                            |        |
  |State: COOKIE-ECHOED                           |        |
  |                                  X does not   |        |
  |                                  send (or delays)      |
  |                                  COOKIE-ACK   |        |
  |                                               |        |
  |T1-cookie timeout                              |        |
  |COOKIE-ECHO A:1000->X:1000                     |        |
  |---------------------------------------------->|        |
  |                                               |        |
  |T1-cookie timeout                              |        |
  |COOKIE-ECHO A:1000->X:1000                     |        |
  |---------------------------------------------->|        |
Note that X can keep the T1-cookie timeout initially high by
responding to a retransmitted INIT instead of the first INIT
above.  T1-cookies doubles with each retransmission up to 60
seconds, so the sequence is 3sec, 6sec, 12sec, 24sec, 48sec,
60sec, 60sec, 60sec which is 273 seconds or about 4 minutes.
There are ways to extend this period longer.
  |                                               |        |
  |                              INIT C:1000 ->  A:1000 (D)|
  |<-------------------------------------------------------|
  |                                               |        |
  |ABORT ERROR (Restart with new addresses)       |        |
  |------------------------------------------------------->|
  |                                               |        |
  |T1-cookie timeout                              |        |
  |COOKIE-ECHO A:1000->X:1000                     |        |
  |---------------------------------------------->|        |
  |                .                              |        |
  |                .                              |        |
  |                .                              |        |
  |                                               |        |

Following IG Section 2.6 provides for  DoS attack with spoofed
addresses in address list.

Host X can refuse access to A for an arbitrary number of multi-homed
hosts, should A form an association with X.

Here is a reverse hijack:

Host A/B                                       Host X   Host C
  |                                               |        |
  |INIT A:1000 -> X:1000                          |        |
  |---------------------------------------------->|        |
  |TCB1:                                          |        |
  |VT: X                                          |        |
  |PT: 0                                          |        |
  |Loc: A:1000                                    |        |
  |Rem: X:1000                                    |        |
  |State: COOKIE-WAIT                             |        |
  |                                               |        |
  |                  INIT-ACK X:1000 -> A:1000 (C)|        |
  |<----------------------------------------------|        |
  |(TCB1 is found)                                |        |
  |                                               |        |
  |COOKIE-ECHO A:1000->X:1000                     |        |
  |---------------------------------------------->|        |
  |TCB1:                                          |        |
  |VT: X                                          |        |
  |PT: W                                          |        |
  |Loc: A:1000                                    |        |
  |Rem: X:1000, C:1000                            |        |
  |State: COOKIE-ECHOED                           |        |
  |                                  X does not   |        |
  |                                  send (or delays)      |
  |                                  COOKIE-ACK   |        |
  |                                               |        |
  |T1-cookie timeout                              |        |
  |COOKIE-ECHO A:1000->X:1000                     |        |
  |---------------------------------------------->|        |
  |                                               |        |
  |T1-cookie timeout                              |        |
  |COOKIE-ECHO A:1000->X:1000                     |        |
  |---------------------------------------------->|        |
  |                .                              |        |
  |                .                              |        |
  |                .                              |        |
  |                                               |        |
  |                          INIT (IT: Y) C:1000 ->  A:1000|
  |<-------------------------------------------------------|
  |                                               |        |
  |INIT-ACK (IT: X, no tie tags)                  |        |
  |------------------------------------------------------->|
  |                                               |        |
  |                           COOKIE-ECHO C:1000 -> A:1000 |
  |<-------------------------------------------------------|
  |Action B                                       |        |
  |COOKIE-ACK A:1000 -> C:1000                    |        |
  |------------------------------------------------------->|
  |TCB1                                           |        |
  |VT: X                                          |        |
  |PT: Y                                          |        |
  |Loc: A:1000                                    |        |
  |Rem: X:1000, C:1000                            |        |
  |State: ESTABLISHED                             |        |

X now knows A's verification tag for its association with C.
X can know that the association is established with C because
COOKIE-ECHOs stop prematurely, or if A does not kick X out of
the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will
eventually tell X that it is in the established state.  DATA
or a HEARTBEAT would also tell X C's verification tag for the
association.  Or, if X is not kicked out of the TCB, it could
send an INIT and read C's verification tag out of the tie tags
in the cookie in the INIT-ACK.

If X is not kicked out of the TCB then one-way
eavesdropping is possible.

  |                                               |        |
  |DATA (VT: Y)                                   |        |
  |---------------------------------------------->|------->|
  |                                               |        |

Even if X is kicked out of the TCB, X knows A's verification tag
for the association between A and C.  A simultaneous attack on
C could yeild C's verification tag for the association.

A DoS attack would be to send an ABORT to A with the known VT
when the COOKE-ECHO is not received, and start the process again
with a new INIT.  This DoS attack has the difference over the
previous one that no ERROR message is sent to C.

To avoid this problem, INIT received in the COOKIE-ECHO state
needs to be treated the same as INIT in the ESTABLISHED state
(new verification tag chosen), or COOKIE-WAIT (sent to X or
known address of X).  The former is preferrable because it
does not cause a new denial of service attack.

Closing this latter vulnerability also removes the need to find
the existing TCB in the COOKIE-ECHO state based on the source
address list, because a new IT is generated and no tie tags
populated.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 11 Mar 2003 07:01:59 -0600

Ivan:

>	But again, you are changing words... :-/
He does tend to do that .. I said it was far more likely.. it is easy
actually.. send a INIT to my web server at sctp.org... if you use the
alternate address of the server you will likely get the INIT-ACK
from the default route that points out the other interface...

This is a more likely issue.. depending on how the default routes
are placed and which address the peer chooses to send the INIT to, this
case can happen quite often.... far more often than then a
peer being unreachable on an address.. when I setup my network
I use a little tool to test which addresses I can reach .. its called 
ping...
this tends to be commonly used by folks and eliminates the "unreachable"
issues often times... However routing tables get set the way folks put them
in and often times are not as throughly tested. And most don't care which
way the traffic is flowing.. as long as ping is responding...

It always amazes me how when you discuss a subject, laying out carefully
in a thread that

a) addresses are NOT pre-known
b) here is the scenario..
c) paint it carefully
d) show where things break

We seem to get a circle back to eliminate one of the conditions..

We have been discussing the above.. in conjunction with <a> highlighted.

>	That's precisely what I think... Just state that iff you provide the list of addresses you don't need to inspect the address list... otherwise... it is your own risk... it may work most of the time…

exactly

>>Yes, I believe you have it wrong, take a look again above.
No, I think Brian knows what you mean.. he is just changing the subject...

>	Randall? (I doubt that other authors of the API draft are following this loooong thread)
I doubt that:

a) My fellow co-authors of the socket-api will bother reading this 
looong thread.. not unless
    they are gluttons for punishment, and

b) Will be to much in favor of adding a method to add "pre-known" 
addresses to the connect
     call... this really is not to feasable...One would need a special 
sctp_connect() and thus
     you would always have the possibility that connect() would still be 
called and you would
    not "pre-know" all the addresses.. and still need to deal with this 
case...

Now here is my conclusion to this thread.. note I say conclusion .. I 
will not answer in
it anymore.. My silence is not agreement... we have beat this topic to 
death!!  I don't
feel like re-hashing this argument.

1) I will go back through this looong thread and gather up the security 
issues
    that are in it. I will take these to Steve Bellovin and discuss with 
him (over drinks)
    what is and what is NOT issues to be concerned about.

2) We will get modifications for these issues into the IG as needed if there
     are any issues at all..

3) I will discuss with my co-authors of the socket-api this 
sctp_connect() issue.

R

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 11 Mar 2003 07:41:35 -0600

This one may be worth responding to since
there is one new scenario...

>  |INIT A:1000 -> X:1000                          |        |

This is incorrect. You don't have an association yet.. you
must reach established before you "restart with new addresses".. but
as I said I think killing the "new addresses" error cause may
be worthwhile to eliminate.. The abort without this
error cause is better.. but its not applicable here...

>  |COOKIE-ECHO A:1000->X:1000                     |        |
So here, you are just illustrating (if you let the cookie-ack go from
X) a camped-on address scenario.. other than that, you have
a collision case.. and again having a auditing mechanism for
this case may be worthwhile... aka the HB of suspect
associations... at startup...

But this next case is the "new" one worth looking at...

>  |INIT A:1000 -> X:1000                          |        |

So the association is not fully formed and you are in
COOKIE-ECHOED state.. not established...

>  |COOKIE-ECHO A:1000->X:1000                     |        |
And I believe RFC2960 states:
"
   For an endpoint that is in the COOKIE-ECHOED state it MUST populate
   its Tie-Tags with the Tag information of itself and its peer (see
   section 5.2.2 for a description of the Tie-Tags).
"

>  |INIT-ACK (IT: X, no tie tags)                  |        |
So you would have tie-tags... But I still think you would
end at action B..

>  |COOKIE-ACK A:1000 -> C:1000                    |        |
And here is where you make a mistake.. and maybe because action-b's
wording needs some updates.

When the COOKIE-ECHO arrives and you take Action-B you would
update your address list with only those addresses in the COOKIE.
So your association would NOT include X. And of course you
have two TCB and would need to collapse one of them... this
again is where possibly having a special "hold" state to see
who is who may be warrented... but, curently, the way our
implementation works.. the other assocation (the one with
X) would get aborted at least internally... and the other
would hold VT's X/Y but the Address X would NOT be
a part of the association... so if X did send in the
a message it would be rejected... since X does not belong
to the association.. no matter if the Vtag is correct or
not...

R

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 11 Mar 2003 11:37:49 -0600

On 3/11/03, Brian F. G. Bidulock wrote:

<< scenario deleted>>
>
>Host X can refuse access to A for an arbitrary number of
>multi-homed hosts, should A form an association with X.
>

As a general rule attackers do not provide a valid return
address. But it is true that an attacker could pre-empt
a large number of IP addresses by falsely claiming they
were valid endpoints for it.

But it's not a real concern. Some de facto standards
that are very relevant...

    A network administrator SHOULD be able to determine
    which of their users was the source of any packet
    originated from their network. When presented with
    solid evidence that these packets were part of an
    attack, the user's accont SHOULD be terminated.
    
    If a network administrator does not comply with the
    above, other network administators MAY blacklist
    the entire network.
    
    Legitimate customers of the blacklisted network
    SHOULD get angry with their network administrator,
    who SHOULD find themselves in need of new employment.
    
Only the most idiotic attacker in the world would send
packets designed to cause a Denial of Service *after*
their victim has successfully sent a return packet.

Basically, existing administrative procedures are already
in place that would prevent this strategy from being used.
It does not need an SCTP specific solution.

That does leave a minor issue of mistaken configuration.
The address block was recently split, and host X hasn't
updated its INIT-ACK initialization to reflect the change
yet. Unlikely, but still slightly valuable as a scenario.
Personally, I would expect more problems from delays in
updating routing tables.

But anyway, I could see adding the following language
somewhere along these lines:

    An SCTP implementation MAY choose to test a specific
    endpoint listed for its peer if it has reason to believe
    that the endpoint might not legitimately belong to the
    peer. Reasons for suspecting a problem would include
    prior configuration data, or conflicting information
    from other INITs.
    
    An SCTP implementation SHOULD NOT verify all peer
    addresses based simply on lack of confirmation. This
    could result in excessive network traffic.
    
More realistically, it would probably be a good strategy
to log conflicts on which remote IP addresses are bound
together for inspection by the network administrator,
provided that the logging is rate limited so that it
cannot be an avenue for a DoS attack. If the set of
addresses for a remote host is unstable it probably
represents a configuration error or change. Actual
changes should be rare enough that logging them is
not much of an issue. And while there is certainly
no obligation, passing along a probable configuration
error for human review is certainly a nice thing to do.

Caitlin Bestler
http://asomi.com/CaitlinBestler/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Mar 2003 14:06:46 -0700

Randall,

> error cause is better.. but its not applicable here...

Please read the quote from Section 2.6 of the IG above again.  Host
A is in the COOKIE-ECHOED state.  C is trying to add the new address
"C" to the TCB in the COOKIE-ECHOED state.  The quote from the IG 2.6
above tells Host A to send the abort with the specified error code.

> associations... at startup...

X is not in the ESTABLISHED state.  It is in the COOKIE-ECHOED state
and never makes it to the ESTABLISHED state.  I don't think HEARTBEATS
can be sent in the COOKIE-ECHOED state, can they?

Please look again at the above.

--brian

> a part of the association...

Ok, so if you kick X out of the TCB, then X still has the
VT.  It think it would be wise to require or strongly 
recommend that the TCB be reduced in such a way that X gets
kicked out.

> so if X did send in the

Sending an ABORT with the VT is simple, X just spoofs C as the
source address in the ABORT and uses VT:X as the verification
tag.

X can also send HEARTBEATs to A spoofed from C with the proper
VT.  A will dutifully send the HEARTBEAT-ACK with arbitrary
contents of the hb_info to C.  As X has the VT, some ADD-IP
attacks or PR-SCTP attacks might be possible.  Sending SACKs or
DATA to A spoofed from C with the proper VT could have some
interesting effects, because X also knows the A's initial TSN.
Sending DATA with a TSN skipping large blocks of TSN number to A
spoofed from C would canse A to send a pretty weird GAP report
to C that could hang many associations or have them fail
mysteriously.

I think it would be best not to give X the VT of the
association.

Would it cause problems to treat COOKIE-ECHOED the same as
ESTABLISHED?  I don't see much difference between the restart
actions (Action A) and collision action (Action B) for the
COOKIE-ECHOED state?  This would select a new IT and the VT
would not be surrendered in this fashion?  Maybe that would
not work...  But some solution that secures the VT is necessary.
Could we say that if there are fewer addresses (we actually
kick an address out of the TCB) that we choose a new IT?
That would protect the VT in this case.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 11 Mar 2003 16:19:33 -0600

>above tells Host A to send the abort with the specified error code.

Interesting.. this is a mistake in the IG then.. if you read it 
literally you
would only send the abort/error in the COOKIE-ECHOED state.. which
is wrong.. it should be under the existing association.. aka ESTABLISHED.

Not sure why its in the COOKIE-ECHOED state...

We will fix this in the next IG pass...

I will respond to the rest of your email seperately..

R

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 11 Mar 2003 16:48:13 -0600

>recommend that the TCB be reduced in such a way that X gets
As Ivan and I both stated.. this is what is intended, and we need
to beef up all the collision cases with this notation that
you must update all addresses etc.. more grist for the
IG (as Ivan and I both stated)...

In fact, thinking on this case a bit more.. it might be wise in this
case to send a INIT and yourself "restart"... You know from the
matching of addresses that you had a collision set
of associations.. and thus you know things are
amiss. But of course this comes back to the
passive-agressive server case.. i.e. you contacted
X in the first place, you obviously wanted something
from X... so talking to C might not be what you want now...

Before we worry about this case I think we need Mr. Bellovin's
advise as to if this situation warrents attention... (as I have
stated in other emails)... it is an interesting case.. though
far-fetched... as Caitlin and Ivan have all said...

>source address in the ABORT and uses VT:X as the verification
Hmm. that may be, as long as ingress filtering is not in place.. which
most all ISP's have now done.. it is much more difficult to spoof
IP addresses these days...

>to C that could hang many associations or have them fail

This all comes down to the passive-agressive server case... you seem
hung on this case.. If  Steve Bellovin thinks this case
needs attention there are some steps that can be taken.. since
you matched addresses when all of this occured you know
there is a problem.. a number of solutions can be found:

1) Abort both, and let the apps restart
2) Prune out the one (as we mention above) and then
    put it into a restart mode.. aka send a INIT and start it
   with a new VT..
3) And of course some proving of the addresses as well.

Of course all of this depends on being able to detect
up front that it is occuring when the INIT from C arrives... which
can only be done if you match addresses inside the INIT.

I will not discuss further any "passive/agressive" server case until
after the IETF.. if Steve thinks it is not a worry then I see
no reason to wring our hands and be concerned... on the
other hand if not, we will probably go back through and
flesh out the sketch we have of how to fix this..

The key of course will be early detection using the
address lists...

>would not be surrendered in this fashion?  
>
I would need to think on this.. there are a couple of scenarios
that would break I am thinking...

>Maybe that would
I think this is about right.. if this is a concern .. then we want
the side that recognizes an address left the association to send out
a new INIT with new VT... to the address set.. this will then
make the association restart before it ever gets up... but
thats ok.. we will also need to have an "audit/list" scenario
where we HB all suspect addresses in the various Passive/Agressive
server cases... but those we will need to wait to fully flesh
out..

R