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

From: "Balani, Sandeep" <[email-masked]>
Date: Tue, 12 Feb 2002 17:54:35 -0800

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. 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 12 Feb 2002 20:22:29 -0600

Balani,,

> assume the association to be TERMINATED. 

Where is it required to send termination to the user?  That could be
foolish behavior and might open up all manner of DoS attacks.  Perhaps
the receiver of the INIT should respond with ERROR rather than ABORT,
but I don't see where RFC 2960 requires the imp to send termination
to the user.

> able to pass thru the association.

What does waiting for COOKIE-ECHO accomplish?  I don't believe the
receiver has any more information upon the receipt of COOKIE-ECHO
than it does upon receipt of INIT in this case.

--brian

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 12 Feb 2002 23:57:59 -0600

Brian,

Probably we are talking about two diff. scenarios. Please see below.

....
> but I don't see where RFC 2960 requires the imp to send termination

It is defined clearly in RFC 2960 that the receiver of an INIT responds
with an INIT-ACK, not an ABORT nor an ERROR, period.

> than it does upon receipt of INIT in this case.

By design, the receiver has zero information until receiving the
COOKIE-ECHO. Why bother to worry about sending an ABORT or ERROR before
the COOKIE-ECHO arrives.

-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 13 Feb 2002 00:55:50 -0600

Qiaobing,

> with an INIT-ACK, not an ABORT nor an ERROR, period.

We are talking about the implementation guide.  I asked where in RFC 2960
it requires an imp to send termination to the user when sending an ABORT:
the point being that it doesn't say any such thing.

Besides, your statement above is false:  RFC 2960 Section 5.1 says:

   If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
   decides not to establish the new association due to missing mandatory
   parameters in the received INIT or INIT ACK, invalid parameter
   values, or lack of local resources, it MUST respond with an ABORT
   chunk.  It SHOULD also specify the cause of abort, such as the type
   of the missing mandatory parameters, etc., by including the error
   cause parameters with the ABORT chunk.  The Verification Tag field in
   the common header of the outbound SCTP packet containing the ABORT
   chunk MUST be set to the Initiate Tag value of the peer.

It looks to me like there are circumstances in which in implementation
"MUST" send an ABORT in response to an INIT according to RFC 2960.

> COOKIE-ECHO. Why bother to worry about sending an ABORT or ERROR before

To avoid the resource consumption of generating the cookie.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Wed, 13 Feb 2002 08:39:48 -0600

Balani:

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

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

> 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

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 13 Feb 2002 08:42:05 -0600

Qiaobing:

Brian is ABSOLUTLY correct... please see my previous mail 

R