Subject: RE: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-02.txt

From: [email-masked]
Date: Tue, 27 Nov 2001 17:52:35 +0200

Hi David!

> Some typos:
> 
> In "New text: (Section 7.2.4)", there are two "5)" paragraphs.
> 
> In "New text: (Section 8.3)", there is a reference to "COOKIE-SENT".
> I think that should be "COOKIE-ECHOED".

	Yep, both typos will be corrected. Thanks!

	BR Iván Arias Rodríguez

> -David

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

---

From: "V.N.Sriram Chintalapati" <[email-masked]>
Date: Tue, 27 Nov 2001 10:22:54 -0800 (PST)

Hi,

According to RFC 2960 section 5.2.2, "Unless otherwise
stated, upon reception of an unexpected INIT for this
association, the endpoint shall generate an INIT ACK
with a State cookie."
I have the following doubt. 
If an INIT is received in ESTABLISHED state with same
value of Initiate Tag
a) Should the INIT be dropped since value of Initiate
Tag is same(not a peer RESTART)? This can be a stale
INIT packet sent long before.
b) Should an INIT ACK packet be sent? This may  follow
steps similar to peer RESTART, although from (a) it is
sure that peer did not RESTART.
c) Is it possible for an attacker to resend an INIT
packet with an invalid value for a mandatory
parameter, so that association will be aborted.

Any pointers to where I can get more information for
this scenario will be helpful.

Thanks,
Sriram

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

---

From: Randall Stewart <[email-masked]>
Date: Tue, 27 Nov 2001 14:53:38 -0600

> INIT packet sent long before.

Yes, a INIT-ACK should be sent... even if it is a stale packet.
If it is stale the peer endpoint will drop it since it
is required to drop any INIT-ACK if it is in the ESTABLISHED state.

> sure that peer did not RESTART.

Well, the peer actually COULD have restarted... at least
in a mathimatical sense it is possible... and if the
random number generator used by the peer is not good and the
peer is not time-waiting tags, it is even more probable... i.e
that the peer restarted and picked the same tag.  If not
the peer will drop it.

> parameter, so that association will be aborted.

This is where the implementors guide comes in.. notice
that in this document, if new addresses are added (i.e. the
evil attacker) you are to silently discard the INIT. If
no new addresses are added and the hacker somehow just
sends in a INIT (I will assume the tag is different) it
does not harm anything to send a INIT-ACK to the peer where
it will be dropped. Oh if the hacker can sniff your tag
you have worse problems...

R

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