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

From: Tuexen Michael <[email-masked]>
Date: Wed, 13 Feb 2002 14:09:08 +0100

Dear all,
see my comments below.
Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Balani, Sandeep [SMTP:[email-masked]]
> Sent:	Wednesday, February 13, 2002 2:55 AM
> To:	[email-masked]'; Qiaobing Xie
> Cc:	Balani, Sandeep; [email-masked]
> Subject:	RE: [Tsvwg] SCTP Implementer's guide question...
> 
> 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. 
	[Tuexen Michael]  My understanding of the RFC 2960 and
	the Implementors guide is the following:
	The intruder sends an INIT with an additional address. The
	verification tag in the SCTP common header is 0, the initiate
	tag in the init chunk is some value which is not the correct
	tag. The receiver of this INIT will send an Abort chunk with
	the initiate tag as a verification tag. It will not inform the
	user! The receiver of the Abort will discard it because it has
	not the correct tag. The user of that endpoint will also not
	be informed.
	There is no security problem and not user will be informed. This
	behaviour should be OK.

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

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

---

From: [email-masked]
Date: Wed, 13 Feb 2002 21:17:28 +0200

Hi Balani and the rest,

... snip...

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

	You are an endpoint who has a normal association with another endpoint. Suddenly you receive an INIT chunk that seems to be part of this association (but it could be an attacker, and old packet...). You don't terminate or abort anything until you are sure that the peer restarted. That's the reason why you normally make the whole 4-way handshake before you considere that the peer restarted, because you need to check that you are not in any of the other situations (i.e., attacker, old packet...)

	Besides, if you are going to abort an association as soon as you receive an INIT, which kind of protocol do you have? The first guy wanting to close your association does not have more to do than sending you an INIT forging the source address... :-0

> 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

	You named it, in case of RESTART... But you don't consider that your peer has restarted until you finish the whole 4 way algorithm. If you finish it, then you say, ok, the peer restarted, and you tell it to the upper user...

	However, in this case you will never terminate the 4-way handshake, because it is risky... You send the ABORT to the peer... But you send the abort to the one who sent you the INIT... If the peer restarted, nothing changes... you will notice it with a HB or other way. If the INIT was sent by an attacker, then nothing changes either, but you don't give it any more information about things such as your VT and stuff...

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

	The ABORT is telling you what are the extra addresses... You just simply have to subtract them from your INIT chunk (the one you have just sent).

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

	But you must be sure that it is your peer and nobody else the one closing your association...

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

	But, you send your INIT ACK to the source of the INIT chunk. If the attacker included an address parameter with one of the addresses or your peer, you will recognize the INIT chunk as being part of that association. Then, if you would send back the INIT ACK, it will go directly to the attacker hands... The attacker may use the information in the INIT ACK to know more about your association that it should...

	I hope this helps a little...

	BR Iván Arias Rodríguez

> that means No need
> to send ABORT.
>  
> Although i agree that extra cpu cycles are utlized. 
> 
> - Sandeep 
> 
> > 
> 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
> 
> 
> 
> 
> > > > > >    with an ABORT copying the 'Initiation Tag' of 
> the unexpected
> INIT
> > > >
> > tag an a valid peer address of the association.  If the intruder
> > > > > >    with an ABORT copying the 'Initiation Tag' of 
> the unexpected
> INIT
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
>

---

From: [email-masked]
Date: Thu, 14 Feb 2002 11:32:16 +0200

Hi Qiaobing!

> Hi, Randy, Ivan and others
> 
> I guess I must have missed those discussions overhauling the 
> unexpected
> INIT handling in RFC2960.

	They were offline comments... :-0

> A couple of comments here:
> 
>  - The section title
> 
>   "5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, 
>          COOKIE-WAIT and SHUTDOWN-ACK-SENT" 
> 
> seems really cryptic now. If it means what it says, would it be better
> to change it to:
> 
>   "5.2.2 Unexpected INIT in ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-
>          SENT, or SHUTDOWN-RECEIVED State"

	Probably... :-/

	The problem with the title is that it has been growing... I think initially the CLOSED and SHUTDOWN-RECEIVED state didn't appear...

>  - The impl-guide new text says:
> 
>   "Note: Only when a TCB exists and the association is not in 
> a COOKIE-
>    WAIT, COOKIE-ECHOED or SHUTDOWN-ACK-SENT state are the Tie-Tags
>    populated with a value other than 0. For a normal association INIT
>    (i.e. the endpoint is in the CLOSED state), the Tie-Tags 
> MUST be set
>    to 0 (indicating that no previous TCB existed)."
> 
> This becomes quite cryptic, too. Would it be better to say:
> 
>   "Note: The Tie-Tags in the state cookie MUST be set to 0 in an 
>    outbound INIT ACK when the association is in CLOSED, COOKIE-WAIT, 
>    COOKIE-ECHOED or SHUTDOWN-ACK-SENT state. In other states, the 
>    Tie-Tags MUST be populated with a value other than 0."

	Maybe too... I prefer this one... Or maybe better something like "... INIT ACK when the INIT chunk was received in CLOSED...". An association being in the CLOSED state is maybe a little bit tricky thing... :-/

	Thanks!

	BR Iván Arias Rodríguez