Subject: [Tsvwg] Security Considerations addition for 2960bis

From: Vern Paxson <[email-masked]>
Date: Thu, 17 May 2001 00:13:13 PDT

Steve Bellovin has pointed out that SCTP has some of the same issues for
firewalls dealing with fragments that are already documented for TCP in
RFC 1858.  Basically, it would be quite helpful for some firewalls if
they can inspect just the first fragment of a fragmented SCTP packet and
unambiguously determine whether it corresponds to an INIT chunk.  The
SCTP spec already has two requirements that address this need: (1) INIT
chunks must be sent by themselves, with no other chunk in the packet, and
(2) the verification tag of an INIT chunk must be zero.  What we would like
to do is add text like the appended to the Security Considerations for 2960bis
to ensure that these rules are followed, as without such guidance implementers
might not see any pressing need to enforce them.

Comments?  One thing I'm not sure about is whether the packet should be
silently discarded, or treated as a bad out-of-the-blue packet and elicit
an ABORT from the receiver.

		Vern

Security Considerations 

	...
	Per [RFC1858], it is helpful for some firewalls if they can inspect
	just the first fragment of a fragmented SCTP packet and unambiguously
	determine whether it corresponds to an INIT chunk.  Accordingly, we
	stress the requirements stated in 3.1 that (1) an INIT chunk MUST
	NOT be bundled with any other chunk in a packet, and (2) a packet
	containing an INIT chunk MUST have a zero Verification Tag.
	Furthermore, we require that the receiver of an INIT chunk MUST
	enforce these rules by silently discarding an arriving packet
	with an INIT chunk that violates either.

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 17 May 2001 06:49:57 -0500

Vern:

I will add the text to the security section for the next
pass...

and a comment/questions below...

> an ABORT from the receiver.

Currently at the Top of page 26 is an answer to the tag in an INIT not
being 0... it states

"
      The Initiate Tag is allowed to have any value except 0.  See
      Section 5.3.1 for more on the selection of the tag value.

Stewart, et al.             Standards Track                    [Page 25]

RFC 2960          Stream Control Transmission Protocol      October 2000

      If the value of the Initiate Tag in a received INIT chunk is found
      to be 0, the receiver MUST treat it as an error and close the
      association by transmitting an ABORT.

"

The INIT/INIT-ACK is, as you state, required to be non-bundled... but
there is no guidance as to what to do if it is NOT bundled within
the spec. I don't really know how an implementation will act... the
ref-implementation will actually just ignore other chunks and
proceed. The only time it would be skipped (an INIT/INIT-ACK) is
if it was not the first chunk in a packet... 

This is what I would call the easy path in an implementation. When
you  receive an INIT or INIT-ACK you look to make sure you are 
at the first chunk, if not you drop the packet. If you are at the
first chunk, you process it and return looking no further at the
packet.... hmmm... this will be a change.

Now I have a question for you and/or Steve... When you say
fragmentation here are you talking about IP fragmentation?

And a question for the group? Should we silently discard in
the bundled case OR should we send an ABORT?

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 17 May 2001 11:00:02 -0500

Randy and others,

First, I like Vern's text addition. I think it is good and adequate.

More comments below...

>       Section 5.3.1 for more on the selection of the tag value.

I think what Vern's concern is NOT about the Initiate Tag in the INIT,
rather the _Verification Tag_ in the common head of the packet that
carries the INIT.

> if it was not the first chunk in a packet...

Vern's additional text now makes it clear that the receiver MUST drop it
silently. Of cause, the alternative is to send back an ABORT with a bad
parameter error cause (we already have one defined, do we?). Personally,
either will be fine with me.

-Qiaobing

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 17 May 2001 11:48:11 -0500

> either will be fine with me.

Opps.. yep you are right I got the two mixed up :)  Here is the text I
was thinking of... and again I have found a couple of conflicts :/
"
8.5.1 Exceptions in Verification Tag Rules

   A) Rules for packet carrying INIT:

      -  The sender MUST set the Verification Tag of the packet to 0.

      -  When an endpoint receives an SCTP packet with the Verification
         Tag set to 0, it should verify that the packet contains only an
         INIT chunk.  Otherwise, the receiver MUST silently discard the
         packet.
"

Here we have the ...must silently discard if we have two chunks
in a INIT... this means I have some coding to do :/

We probably need to clearify 8.5.1 (if we go the silently 
drop route) that we also drop it if it has an non-zero VT ...

If we go the abort route we need to change 8.5.1 as well..

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 17 May 2001 18:25:16 -0700 (PDT)

> the bundled case OR should we send an ABORT?

I'd suggest to drop it.  If the assumption is that nobody should
do it, then dropping it seems to be a safe choice.  We don't want
to send unnecessary packets out if we can.  This can open a hole
for attack.

							K. Poon.
							[email-masked]

---

From: "Randall R. Stewart" <[email-masked]>
Date: Fri, 18 May 2001 06:58:39 -0500

> to send unnecessary packets out if we can.  This can open a hole

I think I agree with you.. we already drop one of the cases..

Unless I hear strong objection otherwise... I will leave it has a
drop...
and the next pass will have this wording and some touch ups to 8.5

R