Subject: RE: Address List Change on Restart

From: <[email-masked]>
Date: Thu, 6 Mar 2003 23:51:10 +0200

Brian,

> Ivan.Arias-Rodriguez,
> 
> On Thu, 06 Mar 2003, [email-masked] wrote:
> 
> > 	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)...
> 
> 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.

	Exactly, you send back an INIT ACK chunk containing a new IT (because you couldn't find the association, right?)... Also the peer's is new, since it restarted...

> > > 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... :-/
> 
> Sorry, not C, but D.  Our implementation performs Action D, 

	Why D? What am I missing? Both the local and the peer's tag don't match, and the Tie Tags are set to 0, so there isn't any row in the Table 2 of the RFC 2960 for this case.

	In any case, you are right, you discard the COOKIE ECHO...

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

	And then? How is the peer then able to re-establish the association? Is not that what we want?

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

	Since the new Error Cause will be included in the new basic specification, the peer should know what is happening and has a chance of fixing the whole thing... This may not be the best way of doing but...

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

	Yes, and it seems to me that due to that, in this situation you will discard the COOKIE ECHO and the peer will never be able to restart... So, if the peer sends the INIT from any of the new addresses, it might not be able to establish the association... right?

	BR Iván Arias Rodríguez

> > 	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
> 
> > 
> > 	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 ¦
> > > 
> 
> -- 
> 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 20:25:46 -0700

Ivan.Arias-Rodriguez,

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

> 	Exactly, you send back an INIT ACK chunk containing a new IT (because
> 	you couldn't find the association, right?)... Also the peer's is new,
> 	since it restarted...
> 
> 	Why D? What am I missing? Both the local and the peer's tag don't
> 	match, and the Tie Tags are set to 0, so there isn't any row in the
> 	Table 2 of the RFC 2960 for this case.

Table 2 is only for when a TCB exists.  No TCB is found so the response
to the COOKIE-ECHO is the same as if no TCB existed, which also happens
to be the same as Action (D) in the Table 2.

> 	Is not that what we want?

It will retry the COOKIE-ECHO until it times out.  If the sender of
COOKIE-ECHO is an attacker, they will time out and never receive a
COOKIE-ACK while the existing association remains.  If the sender
is legitimately the host restarting, a HEARTBEAT will abort the existing
association (30 seconds) before the Cookie expires (60 seconds plus
cookie preservative) and the association will be formed.

This actually works quite well: the attacker gets dead air, the
legitimate host, even with an INIT with a poorly chosen source
address on a static allocated port pair (I don't know how that
would even happen in practice will connect.

This is far preferable to refusing the the INIT, surrending information
about active associations and their source addresses to attackers,
barring legitimate hosts and expecting their user programs to be written
to be able to recover once given the information that the ULP couldn't
get right in the first place.

> 	Since the new Error Cause will be included in the new basic
> 	specification, the peer should know what is happening and has a chance
> 	of fixing the whole thing... This may not be the best way of doing
> 	but...

Yes, it also tells the attacker which addresses it sent in the INIT
for part of the association and which do not.  This is far too much
information to give to hand out to an attacker.

> 	Yes, and it seems to me that due to that, in this situation you will
> 	discard the COOKIE ECHO and the peer will never be able to restart...
> 	So, if the peer sends the INIT from any of the new addresses, it might
> 	not be able to establish the association... right?

It will establish the association for legitimate restarts, because if it is
a legitmate restart the HEARTBEAT (or DATA or SACK) will drop the existing
association before the cookie expires.  With recommended protocol parameters,
the existing association will be dropped own its own before the connect()
times out.  If an implementation sets its time outs too low, then it can
always expect to have to retry, even in normal circumstances, and will retry
in this circumstance as well.

There is even a way that I could force the existing association down.
That is to issue a HEARTBEAT on the conflicting association when discarding
the COOKIE-ECHO.  If it is a legitimate restart, an should ABORT be received
before the COOKIE-ECHO is resent.  But I think it wouldn't be worth the
effort.  The normal heartbeat interval should suffice.

--brian