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

From: [email-masked]
Date: Wed, 13 Feb 2002 16:04:59 +0200

Hi all! Some comments regarding the received mails so far...

	First of all, I completely agree with Brian about not sending anything to the upper user. The INIT receiver must not send any termination message to its upper user at all.

	As it has been told, to be able to make that attack, you should know the VT, one of the addresses and the port, so it is easier to simply send an ABORT...

	And about why not waiting for the COOKIE-ECHO... I was the one that proposed it :-0. Initially you should wait until you received the COOKIE-ECHO, but...

	The point is that the State Cookie parameter inside the INIT ACK chunk is authenticated, but not encrypted... So, the normal procedure in these cases, when receiving a duplicate INIT is setting the Tie Tags inside the State Cookie parameter to both the values of our VT and our peer's one.

	Ok, the attacker should not know about the internal structure, but the Tie Tags are 32-bit numbers that should always be there set to the same value and if the attacker sends several INITs and compares them, taking into account that some values as the IP addresses and stuff can easily be identified, it would be relatively simple to "guess" the VTs from those State Cookies... Even easier, if it sends INITs to both peers, then checking 32-bit values that are set to the same value inside State Cookies generated by different peers would make things simpler...

	Also, if you send the INIT ACK while in the 5.2.1 section case, it is even worse, as you are sending the "real" VTs inside the INIT ACK itself (ok, there is a really tiny window of time to do it, but still... :-0 it was easy to avoid)... Thus, for the reason stated above, to make things the same way (5.2.1 and 5.2.2), and to save time while calculating the INIT ACK (the MAC might take some time to calculate), I think it is better not to generate the INIT ACK chunk at all...

	The receiver of the ABORT should check which are the new addresses and try to restart not using them, then terminate the association and then start it again if it really need to use those other addresses... It could also do it using the AddIP extension... :-/

	I hope this answers your questions...

	BR Iván Arias Rodríguez

> > 
> > > >
> > > > On the other hand, If we wait till COOKIE-ECHO,  the 
> intruder can never be
> > > > 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.
> > 
> > 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.
> 
> To avoid the resource consumption of generating the cookie.
> 
> --brian
> 
> -- 
> 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: Qiaobing Xie <[email-masked]>
Date: Wed, 13 Feb 2002 17:24:38 -0600

Hi, Randy, Ivan and others

I guess I must have missed those discussions overhauling the unexpected
INIT handling in RFC2960.

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"

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

-Qiaobing