Subject: RE: Address List Change on Restart

From: <[email-masked]>
Date: Thu, 6 Mar 2003 16:47:54 +0200

Hi all!

> 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

	And create a new VT... And of course, the peer's VT is also a new one... Remember that you are treating this case as a completely new association and that the peer has restarted (so the peers VT cannot match)...

> sends a COOKIE-ECHO, as it has tie tags of zero and there is an
> existing association we apply Action (C) and discard the

	Why C? Neither VT matches, and Tie Tags are set to zero so you go to... oops! no one... Thus you discard the COOKIE ECHO... So this invalidates your whole mail... Unless, of course, I'm missing some other special trick... :-/

	The peer will keep resending the COOKIE ECHO until it concludes that you are down and stops trying. Following the IG you will at least warn the peer what is the reason... giving him a chance for "rectification" (either wait for a while, or start a new association not using the "extra" addresses, and then either tear it down and start with all the addresses, or use AddIP if both ends support it)...

	Of course this will happen only if you check all the source addresses included in the COOKIE ECHO (so at the end you have to check anyway, and apart from it, you have recalculated twice the MAC of the State Cookie, and sent an extra datagram)... Otherwise you might end up having two associations sharing some of the pairs (source address/port, destination address/port), with unknown consequences... But of course, in your case, relying on the VT to identify the associations, will make these two associations easy to differentiate and you might even live with both of them, even though they are illegal...

	BR Iván Arias Rodríguez

> 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
> > http://asomi.com/CaitlinBestler/
> 
> -- 
> 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: Thu, 6 Mar 2003 08:49:54 -0700

Ivan.Arias-Rodriguez,

On Thu, 06 Mar 2003, [email-masked] wrote:

> 	And create a new VT... And of course, the peer's VT is also a new
> 	one... Remember that you are treating this case as a completely new
> 	association and that the peer has restarted (so the peers VT cannot
> 	match)...

I am assuming that I have a listening socket on C:9999.

Our implementation looks for a listening socket/stream.  If there
is no listening socket/stream it looks for a TCB match on IP/SCTP
header information (which will not find the existing association)
and the INIT would then be treated as out of the blue.  So either
a new VT is selected and sent, or the INIT is discarded.

> 	Why C? Neither VT matches, and Tie Tags are set to zero so you go
> 	to... oops! no one... Thus you discard the COOKIE ECHO... So this
> 	invalidates your whole mail... Unless, of course, I'm missing some
> 	other special trick... :-/

Sorry, not C, but D.  Our implementation performs Action D, however, it does
not send the COOKIE-ACK.  The passive open attempt is queued to the listening
socket.  When an accept() is performed on the listening socket, the connection
attempt is checked for conflicts before being placed into the TCB hashes.
(I.e. a TCB doesn't exist yet.)  This COOKIE-ECHO will fail the conflict
check as an existing association conflicts with the association that would be
established.  At this time the COOKIE-ECHO is discarded and no COOKIE-ACK
is sent in response.

> 
> 	The peer will keep resending the COOKIE ECHO until it concludes that
> 	you are down and stops trying. Following the IG you will at least warn
> 	the peer what is the reason... giving him a chance for "rectification"
> 	(either wait for a while, or start a new association not using the
> 	"extra" addresses, and then either tear it down and start with all the
> 	addresses, or use AddIP if both ends support it)...

The attacker gets ETIMEDOUT, which is good.  The non-attacker using a source
address in the INIT that is within the addresses in the current association
will succeed on the restart where the IG would have you fail that connection
indefinitely for users that simply bind with INADDR_ANY.

> 
> 	Of course this will happen only if you check all the source addresses
> 	included in the COOKIE ECHO (so at the end you have to check anyway,

I never use the source address lists "[w]hen searching for the TCB" which is
what the IG foolishly says.  After the TCB is found, I search for conflicts
using the source address list on COOKIE-ECHO, but never on INIT or INIT-ACK
as the IG states.

> 	and apart from it, you have recalculated twice the MAC of the State
> 	Cookie, and sent an extra datagram)...

I did not send an extra datagram, the attacker did.

The cost of calculating the MAC (which is almost always necessary) is less
than searching for conficts "[w]hen searching for the TCB" (which is never
necessary).  This is because I would have to lock the hashes while searching
recursively for conflicts on arbitrarily long address lists on each INIT or
INIT-ACK or COOKIE-ECHO if conflicts where checked "[w]hen searching for the
TCB".  MAC calculations run without locks.

>       Otherwise you might end up
> 	having two associations sharing some of the pairs (source
> 	address/port, destination address/port), with unknown consequences...

The only requirement is that two associations not be ESTABLISHED.  This
is best determined at receipt of COOKIE-ECHO and checking for conflicts
before moving the association to the ESTABLISHED state.

> 	But of course, in your case, relying on the VT to identify the
> 	associations, will make these two associations easy to differentiate
> 	and you might even live with both of them, even though they are
> 	illegal...

We only ever have 1 association between endpoints because a conflict check
is made before the association is moved to the ESTABLISHED state.

--brian

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 6 Mar 2003 15:31:45 -0600

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

>> and apart from it, you have recalculated twice the MAC
>> of the State Cookie, and sent an extra datagram)...
>
As should be clear from the examples cited, the source of
the redundant INIT can be a host that lacks perfect
knowledge of which IP address corresponds to which host
for the entire IP network. It is not necessarily an
attacker. And no matter how common you might think attackers
are, I would submit that hosts lacking perfect knowledge of
IP Address to Host mappings are far more common.

Indeed an attacker might be more likely to have that
information that an honest client.

The point is that the client host did not have enough
information to avoid sending the "redundant" INIT. The
responding server has enough data to avoid sending the
excess INIT-ACK.

Further, sending an excess INIT-ACK on the justification
that the sender of the INIT was probably some attacker
anyway would seem to be inviting a denial-of-service attack.
"Take THAT you vile scum, I'll flood the network with even
MORE unneeded datagrams!"

>The cost of calculating the MAC (which is almost always
>necessary) is less than searching for conficts "[w]hen
>searching for the TCB" (which is never necessary).  This
>is because I would have to lock the hashes while searching
>recursively for conflicts on arbitrarily long address
>lists on each INIT or INIT-ACK or COOKIE-ECHO if conflicts
>where checked "[w]hen searching for the TCB".  MAC
>calculations run without locks.

A well designed index, even if hashed, can be referenced
without locking the entire structure.

I will also point out that nobody has questioned the value
of using V-TAGs to expedite searches. I believe they can
especially expedite lookups within an Established
Association. For optimizing performance I would generally
assume that Data Chunks had better greatly outnumber INITs,
INIT-ACKs or COOKIE-ECHOes.

Caitlin Bestler

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 06 Mar 2003 16:38:09 -0600

Caitlin,

I just love the way you put the above :))

And of course the fact that it is true makes it even funnier :>

>without locking the entire structure.
Yep...

>INIT-ACKs or COOKIE-ECHOes.
And I agree with this too. One can still use Vtags to optimize
most of the lookups (valdiating the addresses as well) but I think
the big thing is you really need to validate the addresses.. and once
you start doing this you must look in the INIT/INIT-ACK.

I am going to see if I can have a chat with Steve Bellovin on this.. and get
his feedback. He may, from the security side, want some wording in
the IG to NOT depend solely on the V-Tag but to be sure to
validate the addresses as well.

And the information Brian mentioned about firewalls is silly..
A Firewall can not protect you from this for two reasons..

a) Firewalls (ones that I am familiar with at least) do not do 
multi-homing aka
    I don't know of any inter-firewall communicaiton protocol.. Thus a
   firewall can only protect a singly homed site. We are not restricting
   our discussion to a singly homed site.

b) How TCP works in a firewall is the server is listening, in comes a 
SYN. The
    server responds with a SYN-ACK and this enables the hole in the 
firewall. I
    can't say for sure how SCTP firewalls will be implemented, but if it 
is like
    TCP then the INIT-ACK will open the hole in the firewall. Note TCP also
    has cookies but it  has not modified firewall behavior to my 
knowledge... So an attacker can:

  ----INIT--(from bogus address)----------->
 <wait some time>
   ----ABORT(from bogus address, Vtag-guess-1)-------->
  ----ABORT(from bogus address, Vtag-guess-2)--------->

and a vtag+port implementation like Brian's "Fast but dangerous" 
implementation will
end up with associations dying all over the place..

And if the firewall does wait for the cookie the attacker might even 
consider
using its own address, open the hole and start sending bogus packets..

Oh, and Brian your little change to this code:
 
      if ( sp->daddr ) {
            sp->caddr = sctp_find_daddr(sp, ((struct iphdr 
*)mp->b_datap->db_base)->saddr);
            normal( sp->caddr );
        }

will make INIT-ACK's from an address not listed in the TCB (of the 
sender of the
INIT) be dropped...  Since the INIT-ACK from a peers address IP-B (if 
the INIT
was sent to IP-A and no others are yet listed in the TCB) would cause the
error action and you would jetison the valid INIT-ACK.. and guess
what.. your association would NOT come up..

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 19:55:36 -0700

Caitlin,

> MORE unneeded datagrams!"

The attacker does not send an extra INIT-ACK.  The attacker is
invited to send an extra COOKIE-ECHO for every INIT it sends.
This is just the normal process.  The attacker under all other
circumstances receives an INIT-ACK and is invited to send a
COOKIE-ECHO.

The four message handshake process of SCTP is the mechanism by
which attackers are distinguished from legitimate initalizations
and is also process that legitimate hosts are expected to
follow.  Following the process for all initialization attempts
is not a problem.

The serving host cannot distinguish an attacker from a
legitimate host from the INIT alone.  It must send and receive
its cookie to determine the authenticity of the source address
in the INIT packet headers.  If the serving host sends an ERROR
in response to an INIT, it is denying legitimate hosts along
with attackers.  If the serving host sends INIT-ACK and makes
its decision on the echoed cookie, it has verified the source
address of the sender of the INIT and can make a better informed
decision.

The IG 2.6 exchange is:

   INIT
   -------------------------------->
                           ERROR
   <--------------------------------

Legitimate as well as attackers get the ERROR.

The RFC 2960 exchange is:

   INIT
   -------------------------------->
                           INIT-ACK
   <--------------------------------
   COOKIE-ECHO
   -------------------------------->

Legitimate users get

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

attackers (and completely misconfigured or confused
applications) get no COOKIE-ACK, or could be sent the new ERROR:

                           ERROR
   <--------------------------------

In general, for security sake, it is better to give an attacker
no information.

For example, IG 2.6 says that the addresses that are in error
must be placed in the ERROR message.

What this serves to do is to tell the attacker which addresses
are valid and which are not: a piece of information that can
then be used to escalate the attack.

So what I do as an attacker is send 50 source addresses for a
given port pair and attacked host destination address.  The host
that follows IG 2.6 will kindly oblige and send me my source
address and all the addresses that are not part of the
association in the ERROR response.  This way I can determine
which addresses belong to the association and which do not.

This serves to compromise the VT strength (as Randall puts it)
because I can find at least one valid source address for an
association for a given port pair by interrogating the attacked
host with INITs bearing the attacker's own source address.  Then
I can start breaking the VT by running through the VTs spoofing
the now known source address until the T-bit abort sent to the
spoofed host drops the association.

Collecting many source addresses in this fashion, I could attack
the VT in parallel, by placing the same VT and running through
the VT space for all known associations for the attacked host.

Oh, another piece of information you give away to an attacker in
the ERROR is that an association even exists for the port pair.
So, by sending INITs with my additional address I can discover
which associations the attacked host have, and which it does
not.  (All the while forcing it to lock its TCB database during
the lookup to protect TCB database integrity and eventually
denying legitinate INITs while I probe.)

The more secure scenario for avoiding DoS attacks and not
surrendering information is to send an INIT-ACK that contains no
information about existing associations in it (zero tie tags).
INIT-ACKs can be created without examining the source address
list of the INIT (copied verbatim to the cookie) and requires no
locking.  Yes HMAC calculation does occur, but without locking,
and the HMAC calculation is necessary both for legitimate
senders as well as attackers and is the basis upon which the two
are distinguished.

> without locking the entire structure.

But that is an implementation decision, and thus the mis-use
of the SHOULD keyword.  How an implementation searches for a
TCB is its own business.  RFC 2960 clearly states that no two
associations can be formed between the pairing of destination
transport addresses.  How one searches has little to do with
that.  It is which associations that are actually established
(move to the ESTABLISHED) state that counts.

> INIT-ACKs or COOKIE-ECHOes.

Nobody has presumed to tell implementers how then SHOULD
look for TCB for any message other than INIT or INIT-ACK (yet).
It is as inappropriate to say how TCB SHOULD be searched for
INIT and INIT-ACK as it is for the rest of the the messages.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Mar 2003 20:54:37 -0700

Randall,

> validate the addresses as well.

That would not bother me.  I will still look up on VTag and don't
need to examine the source address list in INIT or INIT-ACK when
doing so.  I will validate the source address in the packet
against the TCB once the TCB is found.  But I don't need the source
address list to find TCBs as IG 2.18 foolishly recommends.

Also if IG 2.6 stands, you will be handing the attacker the valid
source address list in the ERROR and also telling the attacker which
associations exist and which do not.  So any checking of source
addresses will be moot as the attacker a can always find a valid
source address by issuing an INIT with its own IP address and an
arbitrarily long list of guesses.

So please have Steve consider the security ramifications of exposing
information in the ERROR message of IG 2.6.

As a general rule an implementation should never send any information
when refusing an INIT outside of the scope of the INIT itself (parameter
errors, etc).  Any information given when refusing an INIT is handling
information to an attacker.  In the case of IG 2.6, valid and invalid
addresses are identified for a port pair and the attacker is told when
a port pair has an existing association and when it doesn't.  Offering
this information is quite naive.

> knowledge... So an attacker can:

Firewalls can be set up so that no SCTP packet can make it to the
server from an external attacker.  If you need advise on setting up
firewalls for security there are some good books on the market. ;)

>   ----ABORT(from bogus address, Vtag-guess-2)--------->

Section 2.6 of the IG will tell the attacker the valid source
addresses and identify existing associations so that the attacker
can use this approach on all your associations with valid source
addresses (without wasting their time on associations that do not exist).

Unfortunately 2.6 offers the attacker the mechanism for discovering
source addresses that you said was so difficult for an attacker to
do in your last security analysis e-mail.  With IG 2.6, finding the
a valid source address for a given association is quite easy: just
send an INIT from your own address with a list of all your guesses for
the port pair in the source address list.  The ABORT/ERROR will tell
you whether an association exists for the port pair with any of the
addresses provided, and will even nicely tell you which address are
invalid (leaving only the valid ones).

With some IP tree searching approaches used by viruses today, one
could query a hosts entire TCB database in short order and then
start the attacks.

2.6 is really a bad idea, and 2.18 is simply unnecessary.

> what.. your association would NOT come up..

Your welcome to skip it for INIT-ACKs.

(It has a GPL license so you are allowed to change your copy...  But
it still doesn't need to look into source address lists and lookups
most things with a tag on tag.)

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 07 Mar 2003 04:53:21 -0600

>firewalls for security there are some good books on the market. ;)
Read quite a few already :> and even looked at some code.. can't find
what you claim though...

>invalid (leaving only the valid ones).

Not that the error cause was my idea :-0  I would have no problem
with removing it ... my idea was to just let the INIT's time-out
if I remember correctly.. Figuring that the old assoc HB's would clean
up the old TCB and eventually it the new would come up :>

>most things with a tag on tag.)
I would not dream of it.. since I would never use it... there are better
implementations ..  the only reason I have a copy of your code
is to know what arguments you are going to make..

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 04:07:00 -0700

Randall,

> Read quite a few already :> and even looked at some code.. can't find

Block protocol 132 on all non-trusted interfaces.  (Gee, that was simple.)

> up the old TCB and eventually it the new would come up :>

Ok, so remove the error.  Then I don't need to look in the source address
list for 2.6 and there is no need for 2.18.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 07 Mar 2003 05:37:14 -0600

>Block protocol 132 on all non-trusted interfaces.  (Gee, that was simple.)
How does that help you?

You block 132 on non-trusted interfaces? I have two interfaces up out of
my mythical firewall.. I want to accept associaitions from my peers out
there.. maybe a HTTP server ...

Now off these two interfaces come good  INIT's etc from peers..

If I block all the interfaces I can't get any INIT's...  So I guess this is
the ultimate in security.. no communication good/or/bad...

>list for 2.6 and there is no need for 2.18.

2.6 was not the reason for 2.18... Again go back and look at some of the
cases laid out by Ivan and Caitlin...

R

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 07 Mar 2003 05:54:39 -0600

>>>invalid (leaving only the valid ones).
Thinking about this a bit more, I believe I am in agreement with something
Ivan proposed (off list)... What we should do is get rid of the error cause
and the abort stuff.. and instead.. the reciever of such an INIT MUST
send the INIT-ACK back to one of the existing addresses...

If the guy IS an attacker it does not get back the INIT-ACK and thus
cannot take-over the association..

If the guy IS NOT the attacker then it gets the INIT-ACK and the association
comes up...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 05:33:21 -0700

Randall,

> If the guy IS NOT the attacker then it gets the INIT-ACK and the association

What if the existing address *is* the attacker?  That is, the exsiting
association is just waiting to highjack other init attempts (with a spoofed
address list).

Also, if the attacker does not receive an INIT-ACK (as it would in every
other case) it knows that there is an association for the given port pair
and that some address in the address list was correct.  This opens up to
scanning again.  Script kiddies will love you for telling them which ports
have associations and that at least one of the addresses in the address
list is correct by not responding with INIT-ACK.

It is a good idea to always send the INIT-ACK to the source of the INIT.

--brian

---

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

>association is just waiting to highjack other init attempts (with a spoofed

Hmm now the above one I don't understand from you...

I have an association with an attacker

Attacker <-IP-A----------------------------------------------IP-Z-> Server

Are you claiming it did

Atacker <-IP-A/(someother addresses)------------------------IP-Z->server

and hoping for the
            --------------------INIT(someother address)---------->

If so, two comments...

a) A heartbeat that the server sends will generate an abort for some
    other address.. and the other addresses should be the first thing
    that is HB'd since the IP-A was used in setting up the assoc...
   So one HB delay  and the attackers assoc is down.

b) The attacker has to give away its valid IP address... which in 
combination
     with <a> would yeild lots of errors pointing at him.. hopefully in 
a log
    somewhere.. generally attackers are not interested in telling you.. 
here is
   where I am at...

>list is correct by not responding with INIT-ACK.
Ok, so how is this different than the attacker sending a

COOKIE-ECHO--------------------->

repeatedly

and you discarding it?  Does not the same argument apply.. of course
the only difference is you have gotten to run your MD5/SHA-1 code
for every COOKIE-ECHO received.

Other than that.. you still have the same issue..

If I repeatedly send a COOKIE-ECHO the same clue exists... aka
I have someone elses address in my list..

That is what you said you were doing in your earlier email to Caitlin?

I see no difference in this.. since a valid COOKIE-ECHO always generates
a COOKIE-ACK... so you have given the same information

And back on the subject of fire-walls.. you missed my point.. the 
"trusted interfaces"
that are open to INIT's are the very ones the attacker is using.. this 
is a server
running on the Big-I serving up web pages.. all of its interfaces are 
trusted..

I am NOT talking sigtran.. where you have interfaces that are private... 
your
firewall solution does not work for the Big-I

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 05:37:14 -0700

Randall,

> the ultimate in security.. no communication good/or/bad...

I can still receive INITs on trusted interfaces.

> cases laid out by Ivan and Caitlin...

I have addressed all but Ivan's recent case which I will address
in just a moment.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 07:23:45 -0700

Randall,

>    So one HB delay  and the attackers assoc is down.

And back up again.  The attacker can do this all day long.

> combination with <a> would yeild lots of errors pointing at him.. hopefully
> in a log somewhere.. generally attackers are not interested in telling you..
> here is where I am at...

Do you log ABORTS?  Better not, there is a DoS attack right there.

> for every COOKIE-ECHO received.

No.  The think that gives the lack of INIT-ACK away is that is the
only situation in which an INIT-ACK is not received.

There are many reasons to not receive a COOKIE-ACK in response to a
COOKIE-ECHO.  And the attacker cannot distinguish between them.

> I have someone elses address in my list..

No.  I am just not responding to the COOKIE-ECHO.  In STREAMS I do
no sent the COOKIE-ACK until the connection indication is accepted.
Also, I send aborts when they are refused.

> That is what you said you were doing in your earlier email to Caitlin?

Yes, I am currently discarded on conflict addresses in COOKIE-ECHO.

Instead of discarding in the case of conflict, I should really send
ABORT.  Then the attacker will receive ABORT when there is a conflict
and will receive ABORT when the connection indication is refused by
the ULP.  Then the attacker has no information about existing
associations.

Or another thought, I could send COOKIE-ACK but then kick the TCB out
of the hashes so any message sent will be treated OOTB.

I have many choices with COOKIE-ECHO.  I have few with INIT.

> a COOKIE-ACK... so you have given the same information

No, I send ABORT instead of COOKIE-ACK when the connection indications
is refused on listening streams in the STREAMS implemtnation.

But as I said above, one could reply with COOKIE-ACK and abort any attempt
to communicate on the association.

> 
> 
> 
> And back on the subject of fire-walls.. you missed my point.. the "trusted
> interfaces" that are open to INIT's are the very ones the attacker is
> using..

Then they are not "trusted."

> this is a server running on the Big-I serving up web pages.. all of its
> interfaces are trusted..

All of its interfaces would then be "untrusted".

> your firewall solution does not work for the Big-I

Did I say it did?

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 07 Mar 2003 09:23:49 -0600

>And back up again.  The attacker can do this all day long.

But continued failure in the same method could be discovered..

>Do you log ABORTS?  Better not, there is a DoS attack right there.
True.. but some logging must be done somewhere or else security
problems will never  be found out... One could define a set
of counters to figure this out without filling up the syslog

>COOKIE-ECHO.  And the attacker cannot distinguish between them.
Lets see..

    1) You send a ABORT if the peer is not  listening anymore
    2) You send a ABORT if you are out of resources
    3) If the server stops accepting() that can be detected..
                The evil attacker times-out, It immediately sends
                a normal association start.. and gets a cookie-ack and
                thus finds the receiver is listening... it just did not
                accept that association...

What other reasons am I missing that you silently do a discard?

R

>of the hashes so any message sent will be treated OOTB.
No, that would not be good... since then you would have two associations up
with the same addresses.. presuming of course you are leaving the other
tcb alone..

>I have many choices with COOKIE-ECHO.  I have few with INIT.

And one could do the same thing with the INIT-ACK... send an abort()
when you recognize the condition without an error cause.. No information
revealed and to the attacker it will look like several other cases...

Maybe the real solution is to just remove the error-cause from the 
implementors
guide.. and give no clues as to why the abort was kicked out... this way
the state is cleaned up.. the peer, if legitimate, will kick out the 
next HB on the
old assoc.. and presto.. no information given and standard consistent 
behavior given.

No differnt than any of your choices on the cookie-echo resonding with 
an abort..

>Then they are not "trusted."
How will  a general purpose server, say giving out HTTP pages, then 
work... if
every interface has to be trusted... think Big-I not sigtran...

>All of its interfaces would then be "untrusted".
So your firewall rules would kick out all inits and you would get NO 
communication..

Does not work.. sorry..

>>your firewall solution does not work for the Big-I
Your trusted explanation above alludes to it.. web servers MUST work in such
a "untrusted" environment.. shutting out all communication might keep 
out the
bad guys.. but you won't get your web pages out either :-0

R