Subject: Address List Change on Restart

From: Caitlin Bestler <[email-masked]>
Date: Wed, 5 Mar 2003 14:44:42 -0600

Section 10.1 (Interface with Upper Layer - ULP-to-SCTP)
specifies:

o  local eligible address list - An address list that the
local SCTP endpoint should bind.  By default, if an address
list is not included, all IP addresses assigned to the host
should be used by the local endpoint.

When this default is being reused, it is highly plausible
that a restart would result in the list of IP addresses
being different than previously.

If such a system attempts to restart an association
immediately. Is the peer required to note the changes
in the address list during the peer restart sequence
specified for case A (peer restart) in section 5.4.2
("Handle a COOKIE ECHO when a TCB exists")?

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 05 Mar 2003 15:28:18 -0600

>http://asomi.com/CaitlinBestler/
Actually I believe there is wording in the impl-guide that tells
you that you MUST not accept such an association if it adds
new addresses to it. Otherwise there is a hole that a hacker could
use to take over an association...

So you are not allowed to add new addresses.. but you can
take away addresses from the association.

I believe you will get an Abort back with a error cause
of restart with new address... or something like that.. check the IG
for the "real" procedure...

And if you were to get such a scenario.. where a host restarted
with a new address and then trys to do a INIT (and never sent
an abort or shutdown).. then the only cure is:

a) restart the init with less addresse.. then one could shutdown
   that assoc.. and then restart again with all the addresses (if that
   was desired)
or
b) wait a while and try again.. the HB of the peer would eventually
    illicit a Abort() from the restarted host.. which would then clear
    out the old TCB and then you could bring up an assoc..

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: Thu, 6 Mar 2003 06:24:09 -0700

Caitlin,

IG Section 2.6 would have you refuse the INIT with a new error
code if addresses are added.  But this is not necessary if one
uses the source address of the packet rather than the source
address list.  Consider the following:

 HOST A/B                                    HOST C/D
 --------                                    --------

 Existing assocation (A/B:1000 <-> C/D:9999)
 <==================================================>

         Attacker sends (Z:1000->C:9999, (A,B))
	 ------------------------------------------->

Section 2.6 of the IG says that HOST C/D must refuse this init.
The reason for refusing at the INIT stage instead of waiting for
COOKIE-ECHO is that if HOST C/D sends an INIT-ACK with tie tags
populated, it will be exposing both VTs of the existing
association in the tie tag (the cookie is not encrypted, only
hashed).

However, if we look up on Z:1000,C/D:9999 (only the information
from the packet headers) we will not find the existing
association and will set tie tags to zero (0).  If the attacker
sends a COOKIE-ECHO, as it has tie tags of zero and there is an
existing association we apply Action (C) and discard the
COOKIE-ECHO and the attacker is thwarted.

         INIT-ACK (Z:1000<-C/D:9999, (D/C), tie tags 0)
	 <-------------------------------------------

	 COOKIE-ECHO (tie tags 0)
	 ------------------------------------------->
	                             Discard Action (C)
	                  
Note that if the attacker uses address A or B as the source
address in the INIT, the INIT-ACK will be sent to A or B and
discarded there because there is no oustanding INIT with the
given verification tag.

This approach is superior to that of IG Section 2.6 because it
permits restarts sent from existing addresses (A or B in the
example) to add addresses to the list, but thwarts the outside
attack.  Also, no exhaustive searches of arbitrarily long
address lists is required (searching address lists opens one up
to other attacks).

So, for example,

 HOST A/B                                    HOST C/D
 --------                                    --------

 Existing assocation (A/B:1000 <-> C/D:9999)
 <==================================================>

 HOST A/B Restarts with additional address Z.

 INIT (A:1000->C:9999, (B,Z))
 --------------------------------------------------->

Section 2.6 of the IG would have you refuse this INIT.  If HOST
C/D looks up the association on packet header information only,
it will find the existing assocation, populate tie tags and the
restart will complete:

     INIT-ACK (A:1000<-C/D:9999, (D/C), tie tags set)
 <---------------------------------------------------

 COOKIE-ECHO (tie tags set)
 --------------------------------------------------->
                                   Restart Action (A)

                                           COOKIE-ACK
 <---------------------------------------------------

Of course if HOST A/B restarts and attempts to restart the
association with address Z as the initial primary, then the
initialization attempt will time-out in COOKIE-ECHOED state,
however, a HEARTBEAT should have destroyed the initial
assocation by that time and a simply retry by the ULP will
succeed.

So, if you want to support hosts that restart with additional IP
addresses (quite plausible as you say), IMO you would be best to
ignore both IG Section 2.6 and IG Section 2.18.

This is how our implementation has functioned for years now.

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