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

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

Brian, I never said that we will send INIT-ACK to Intruder.
 
Pls Let me clarify my understanding then u can correct me. 

> 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 at ENDPOINT Z, because it matches the existing assocaition,with IP-1,
IP-2, Endpoint-Z  will send INIT-ACK not to intruder but to ENDPOINT-A. 

 Endpoint-A     <---------- INIT-ACK-------------- Endpoint-Z 
 ( It dump this
   INIT-ACK )                                      
             
                                                   Endpoint-Z
                                                   ( Never Rcv COOKIE)
  Endpoint-E (Intruder) 
  (IT will never receive 
   any message from Endpoint-Z)

ENDPOINT-A should dump this INIT-ACK so that Endpoint-Z will never receive a
COOKIE-ECHO message. 

Thanks
Sandeep 

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

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

On Wed, 13 Feb 2002, Balani, Sandeep wrote:

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

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

---

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

Sandeep,

All the intruder need do is use source address Endpoint-E
in the INIT.  Then it will get INIT-ACK.  The intruder
uses the tie tags to break both Endpoint A and Endpoint
Z's verification tag generation algorithms.  Then the
intruder sends an ABORT with correct source addresss derived
from the cookie to Endpoint Z and correct verification
tags and destroys a whole bunch of Endpoint Z's existing
associations.  The intruder can do the same for Endpoint
A.

There is no reason to send INIT-ACK at all.  ABORT is
appropriate here as required by the imp guide.

--brian