Subject: Re: Address List Change on Restart

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 05 Mar 2003 19:09:26 -0600

Caitlin Bestler wrote:

>On 3/5/03, Randall Stewart (cisco) wrote:
>
>
>  
>
>>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.
>>
>>    
>>
>Thanks, I totally missed that on a quick scan because I
>was focused on the COOKIE-ECHO, not the INIT.
>
>Having thought about it, the INIT is the correct place
>to catch this. The security hole can be closed at either
>place, but when the extra address is legitimate the other
>host should get the error feedback as early as possible.
>
>If there's a further update to the draft you might consider
>clarifying the rationale for catching this error during the
>INIT as opposed to later.
>
>There is one unresoled gotcha here though. Section 5.1.2 of
>RFC2960 states:
>
>  
>
>>The time at which the receiver of an INIT resolves the
>>host name has potential security implications to SCTP. 
>>If the receiver of an INIT resolves the host name upon
>>the reception of the chunk, and the mechanism the
>>receiver uses to resolve the host name involves potential
>>long delay (e.g. DNS query), the receiver may open itself
>>up to resource attacks for the period of time while it is
>>waiting for the name resolution results before it can
>>build the State Cookie and release local resources.
>>
>>Therefore, in cases where the name translation involves
>>potential long delay, the receiver of the INIT MUST
>>postpone the name resolution till the reception of the
>>COOKIE ECHO chunk from the peer.  In such a case, the
>>receiver of the INIT SHOULD build the State Cookie using
>>the received Host Name (instead of destination transport
>>addresses) and send the INIT ACK to the source IP address
>>from which the INIT was received.
>>    
>>
>
>Presumably the requirement to reject the restart remains
>even if the hostname resolution is deferred to the
>COOKIE-ECHO state.
>  
>

Yep,

Not that you will find many people implementing the Host-Name
address... it is just a bit difficult when you consider the kernel
implementation ramifications.. and there are other ways
to get through nats (which was the reason it was put in)...

So far NO implementation at any bakeoff as demonstrated
this capability (let alone two implementations).

R

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

-- 
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:47:25 -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

On Wed, 05 Mar 2003, Caitlin Bestler wrote:

> 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

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