Subject: RE: [Tsvwg] SCTP Implementer's guide question...

From: "Balani, Sandeep" <[email-masked]>
Date: Wed, 13 Feb 2002 10:10:00 -0800

Hi Randy,
 
Some Comments, 

-----Original Message-----
From: Randall Stewart [mailto:[email-masked]]
Sent: Wednesday, February 13, 2002 6:40 AM
To: Balani, Sandeep
Cc: [email-masked]'; Qiaobing Xie; [email-masked]
Subject: Re: [Tsvwg] SCTP Implementer's guide question...

Balani:

It is quite unusal for me but I am in complete agreement
with Brian :-)

"Balani, Sandeep" wrote:
> 
> Hi Brian,
> 
>   Somehow i still think that we should do this check when we receive
> COOKIE-ECHO.
> Because, even though It send ABORT with vTag=iTag of INIT chunk, It still
> means that Association is terminated.
> 
> When the receiver of INIT respond with ABORT it also send TERMINATION-IND
to
> upper user to close the socket. which means that although u may be right
> that peer won't accept ABORT because of mismatching vTag but this end
still
> assume the association to be TERMINATED.

No it SHOULD NOT send anything up to the upper layer. The ABORT it sends
with the iTag would NOT be for THIS association. As far as the local
endpoint that receives the abort is concerned the association has
NOT restarted, the vtag is incorrect. 

[ Balani Sandeep] Randy, Can u please explain Why would we not send
Termination Indication to local user when association is ABORTED. 
If there was an SCTP exception locally or some illegal event occured in
which case u send ABORT to peer & terminate the association. 

One more reason for Terminating the association is in case of RESTART
because the peer loses all its context it may not remember what addresses it
sent during first time of association. So in that case even though he
receives ABORT ( with additional addresses) he has to guess that what
addresses i sent previously. In that case it will be hit & trial for peer to
send IP addresses.
 
On the other hand if u teminate the assocition he can start with whatever IP
addresses it wants. Is'nt it ?  

Brian, I am sorry for my foolishness, but i still don't understand. 

Lastly the reason to wait for COOKIE-ECHO is because INIT-ACK would be send
to genuine user because it matched with its association, & that peer will
dump the INIT-ACK so we would never receive COOKIE-EACHO. that means No need
to send ABORT.
 
Although i agree that extra cpu cycles are utlized. 

- Sandeep 

> 
> On the other hand, If we wait till COOKIE-ECHO,  the intruder can never be
> able to pass thru the association.
> 
> In my understanding getting srcIPaddress and port number (which are
> standard) is easy.  U r correct that vTag are difficult to guess.
> 

I considered this for a LONG time before deciding the right way to
do it is in response to the INIT itself here is why:

We have two basic cases:
1) The peer has restarted
and
2) An attacker or STRAY INIT is arriving.

Now for case 1) I think we all will agree it does not
matter if I wait to send the abort at the cookie-echo or INIT. In
both case the "restart" is NOT going to happen until one of two
things occur:
a) A HB on the now dead association causes an abort (HB from
   Endpoint-Z to Endpoint-A)
<or>
b) The peer drops the extra address and resends its INIT. It could then
   later use add-ip to add the new address (if it supports the
   extension) or shutdown the association properly and restart again
   with the new address.

So just considering case 1) sending the abort from the INIT makes
sense (remember it DOES take a bit of cpu to do the hash .. depending
on the hash algo the implementation is using it can be QUITE a bit
of cpu). And it quickens the recovery time.

Now lets consider case 2) the one in contention..

We have an association:

Endpoint-A                                 Endpoint-Z
IP-1                                        IP-3
    +port5000 <--------------------------->+port6000
IP-2                                        IP-4

Now our evil attacker Endpoint-E sends in an INIT 
after guessing the association is up.

Endpoint-E-----srcip:INIT(Vtag=0,
                          iTag=N, 
                          IPaddress IP-1,
                          IP-2,IP-E)--->Endpoint-Z

Now Endpoint-Z sees a NEW address in the list. It can do one of 
two things:
a) Respond with a ----Abort(Vtag=N)----->src-ip
or
b) send a  -----Cookie()--->src-ip
   
If it does a)
--1) if src-ip is IP-1/IP-2 what happens? Endpoint-A gets the
     abort() checks the V-tag and dumps it on the floor since
     it is a old stale Abort .. not this association.
--2) if src-ip is IP-E then the attacker has failed.

   In either case Endpoint-Z would NOT tell the application
   that anything happened. It would possibly LOG the event to
   a security log. Which would then help point a finger at
   IP-E but it would not tell the app.

If it does b)
--1) It would send a cookie back that it KNOWS that it
     will reject. Thus wasting some CPU cycles to sign
     a bad cookie.
--2) If src-ip is IP-1/IP-2 the peer would get a cookie
     it did not send and discard it.
--3) If src-ip is IP-E the evil endpoint would then send
     the cookie-echo... which would of course be rejected
     with an abort in the same fashion as if we caught
     it early.

So the bottom line is that if you do the detection early 
it just saves CPU cycles on the victim AND CPU cycles on
the peer of the vicitim in the attackers case.

The other neat point is you gain a audit trail of the
events. When sending a Cookie instead of an abort, if the 
attacker uses IP-1/IP-2 as src-ip then we are responding 
normally and create no audit trail for our security people
to track down... if it uses IP-E then we DO have an audit 
trail but have done extra CPU computation to get something 
we could have had with less cost..

In the end the result is the same though..

R

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2002 5:31 PM
> To: Qiaobing Xie
> Cc: Balani, Sandeep; [email-masked]
> Subject: Re: [Tsvwg] SCTP Implementer's guide question...
> 
> Qiaobing,
> 
> On Tue, 12 Feb 2002, Qiaobing Xie wrote:
> 
> > Brian/Sandeep:
> >
> > I believe Sandeep is right. The impl-guide should be corrected. See
> > below for more...
> >
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Sandeep,
> > >
> > > > >  " Before responding the endpoint MUST check to see if the
> > > > >    unexpected INIT adds new addresses to the association. If new
> > > > >    addresses are added to the association, the endpoint MUST
respond
> > > > >    with an ABORT copying the 'Initiation Tag' of the unexpected
INIT
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > >    into the 'Verification Tag' of the outbound packet carrying the
> ABORT.
> > >
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >
> > > The sender of the INIT tag must guess the verification tag of the
> > > existing association and place it in the Initiation Tag field of
> > > the INIT.  It is of no moment that the vTag is zero in the INIT.
> >
> > No. vTag is always zero in the INIT, no matter it's for a fresh
> > association or a re-started one. The endpoint that restarts would most
> > likely lose any memory of its previous life.
> 
> The vTag is not zero in the ABORT.  As the vTag in the received
> ABORT must match the existing association's tag (otherwise the
> ABORT is treated OOTB) the intruder must know the tag of the
> existinging association to abort it.  Not only that, but the
> intruder must also know a source address of the attacked host's
> peer to fake the source address and get it sent there.
> 
> It requires the intruder to know both the existing association
> tag an a valid peer address of the association.  If the intruder
> knows these things, it might as well send an ABORT to the attacked
> host faked from the known source address with the known tag value.
> 
> Sorry, but there is no 'sploit here that is different from the
> normal cases for RFC 2960.
> 
> >
> > .....
> > > > On Tue, 12 Feb 2002, Balani, Sandeep wrote:
> > > >
> > > > > Hi all,
> > > > >   I have a question regarding SCTP implementer's guide. I remember
> this
> > > > > issue was discussed during 2nd Bakeoff.
> > > > >
> > > > > In
> > > >
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-03.txt
> > > > > section 5.2.2. We are describing the case of association RESTART
> when INIT
> > > > > is received in any state other than CLOSED, COOKIE-ECHOED,
> COOKIE-WAIT and
> > > > > SHUTDOWN-ACK-SENT. The text says
> > > > >
> > > > >  " Before responding the endpoint MUST check to see if the
> > > > >    unexpected INIT adds new addresses to the association. If new
> > > > >    addresses are added to the association, the endpoint MUST
respond
> > > > >    with an ABORT copying the 'Initiation Tag' of the unexpected
INIT
> > > > >    into the 'Verification Tag' of the outbound packet carrying the
> ABORT.
> > > > "
> > > > >
> > > > > I think that we should check the additional IP addresses when we
> receive
> > > > > COOKIE-ECHO from the peer not when we receive INIT from peer,
> >
> > Yes, this check on whether "new addresses are added to the association"
> > is only performed *after* the endpoint received the COOKIE-ECHO *and*
> > determined that this is a re-start case.
> 
> There is no need to wait for COOKIE-ECHO when then ABORT can be sent in
> response to INIT.
> 
> --brian
> 
> >
> > regards,
> > -Qiaobing
> >
> > > > > because if we
> > > > > send ABORT when we receive INIT then an *INTRUDER* can break an
> ESTABLISHED
> > > > > association by sending INIT on an existing association with
addition
> of any
> > > > > IP addresses.
> 
> --
> 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 ¦
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 13 Feb 2002 12:25:47 -0600

Sandeep,

Ivan has put forward a very good reason to not send INIT-ACK
to a potential intruder for an existing association.  This
is because the tie tags in the cookie compromise the security
of the verification tag generator.  (For all associations, not
just the one.)

--brian

---

From: Randall Stewart <[email-masked]>
Date: Wed, 13 Feb 2002 13:01:38 -0600

> which case u send ABORT to peer & terminate the association.
Nothing has been termianated in the attacker case. Your association
is still up and thus you would not report it (at least in your view).
If it is NOT an attacker you still think the assoc is up even
though the peer has failed and restarted. Either a HB from you
will get you a valid ABORT that WILL get reported in a message
to the ULP. OR the peer will resend a INIT without the new
address and you will send your ULP a restart notification.

> addresses i sent previously. In that case it will be hit & trial for peer to

That is the breaks.. there is nothing we can do about this.. Otherwise
we have a serious security hole. The guy that did NOT restart will
eventually get cleared up by the HB.. i.e. the restarting guy
will send an ABORT.

Sending a INIT-ACK with the COOKIE will not change this anway.. and
as Ivan as shown you also show the peer what the tag is of
the association.

> Although i agree that extra cpu cycles are utlized.

I don't know how I can explain it to you any better than my
previous email without you in a room and a white board... sigh..
sorry...

R