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

From: "Balani, Sandeep" <[email-masked]>
Date: Tue, 12 Feb 2002 10:34:36 -0800

Hi Brian, 

Should'nt INIT will have ( vTag == 0 )  ?  

So INTRUDER, only needs correct set of addresses & port numbers to mess up
an association. 

-sandeep

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, February 12, 2002 10:03 AM
To: Balani, Sandeep
Cc: [email-masked]'
Subject: Re: [Tsvwg] SCTP Implementer's guide question...

Sandeep,

For an intruder to abort the association, the intruder would also
have to place the verification tag of the existing association in
the INIT.  That is rather difficult.

--brian

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, 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.
> Correct me here please . 
> Thanks
> sandeep 

-- 
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 13:15:34 -0600

Sandeep,

> >    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.
The ABORT will arrive with the T-bit clear and a vTag that corresponds
to the Initiate Tag from the INIT.  If the vTag in the ABORT does
not match the local tag, the receiver ignores the ABORT.

So your intruder must guess the verification tag associated with the
existing association to perform this attack.  If the verification tag
is known or discernable, there are easier ways of aborting an existing
association (just send ABORT).

--brian

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 12 Feb 2002 18:54:46 -0600

Brian/Sandeep:

I believe Sandeep is right. The impl-guide should be corrected. See
below for more...

> > >    with an ABORT copying the 'Initiation Tag' of the unexpected 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.

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

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.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 12 Feb 2002 19:31:23 -0600

Qiaobing,

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

> 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