Subject: [Tsvwg] ICMP issue with SCTP IG

From: "Coene, Lode" <[email-masked]>
Date: Tue, 13 Sep 2005 15:27:15 +0200

Folks,

At the SIGTRAN Interop an issue with ICMP processing came
Up: If an ICMP message (protocol unreachable) is received the
IG says that it should be treated like an ABORT with the T-Bit set.
This seems not to be appropiate if the original packet contained an
INIT chunk. The initiate tag inside should be used for association
Verification if it is included in the ICMP packet.

Should this be changed in the IG (even if the last call is over)?

Yours sincerely,
Lode Coene

Siemens COM
atealaan 34          2200 Herentals, Belgium
E-mail: [email-masked]
Tel: +32-14-252081
Fax: +32-14-253212

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

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 13 Sep 2005 16:34:36 -0400

The way I read this, the behavior specified in the IG seems to be
correct.  If someone explicitly prohibited access to the SCTP protocol,
that ABORT with T=1 seems appropriate.

Am I misinterpreting the Protocol Unreachable error?

-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 14 Sep 2005 09:49:13 +0200

Hi Vlad,

if you handle the ICMP packet containing the INIT chunk like an ABORT
with T-Bit set, you are using the verification tag in the common
header for checking. In a packet with an INIT chunk this is 0.

Instead the receiver MUST use the initiate tag from the INIT chunk
for the association verification. This is similar to the case described
in section 2.23 of the IG.

So I think Lode is correct and the requested change is important for
the security reasons pointed out in the security threats ID.

Best regards
Michael

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 14 Sep 2005 16:30:23 +0800

> the security reasons pointed out in the security threats ID.

I agree.  The Solaris SCTP stack already does this.  It checks
the init tag in the INIT chunk if it is included in the ICMP
message.  If the ICMP message does not contain enough data, it
is ignored for security reason.

-- 

						K. Poon.
						[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Wed, 14 Sep 2005 08:14:02 -0400

> is ignored for security reason.
Ahh yes.. I think Michael and  I discussed this in Paris and
I just plain forgot about it :-0

How about if we move ICMP-8 and ICMP-9 to
ICMP-9 and ICMP-10

and have a new ICMP-8 (as a late last call comment):

"
ICMP8) If the ICMP code is an "Unrecognized next header type
        encountered" or a "Protocol Unreachable" and the
        association state is COOKIE-WAIT, the packet must
        be examined to determine if it contains an INIT. If
        it does not, then the packet is silently discarded. If
        it does hold an INIT, then if there is enough information
        to examine the initiation tag, compare it with the
        association tag. If the tags match then the ICMP message
        MUST be treated as an ABORT. If there is NOT enough
        information in the ICMP message to examine the initiation
        tag or the tags do NOT match, then the packet
        MUST be silently discarded.
"

That will mean another spin of the I-G.. I guess I
was to quick in trying to get all the corrections in :->

Comments on this insert?

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 14 Sep 2005 14:44:57 +0200

Dear all,

I think the text is good. I would suggest that if no one objects
just put it in, resubmit the IG and the new version is used for
IESG review...

Best regards
Michael

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 14 Sep 2005 10:49:26 -0400

Ahh. I see. I was looking at it from the wrong angle.

Sounds like the IG may need to be changed....

-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 19 Sep 2005 12:41:11 -0400

Randy

I am thinking, that the new text is placed a bit oddly.

We already have the ICMP6 bullet that deals with verification tag.  It
seems better to me to update that bullet to include checks for the
initiation tag when the verification tag is not available as in the INIT
chunk.

Additionally, for the new section 11.4 (which I gues should be 11.5
since IG 2.11.2 introduced 11.4), I think it's sufficient to say SHOULD
or RECOMMEND.

-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 19 Sep 2005 20:17:41 +0200

Hi Vlad,

reading the stuff again, ICMP6 might need to be clearer what is meant
by 'validate'.
Validating means
if (((presented v-tag == 0) and (you can make sure that the chunk type
is an INIT-CHUNK) and (the initiate-tag is the correct one)) or
((the presented vtag != 0) and (matches the peers vtag)))
continue with ICMP7, else silently discard the packet.

SO a possible text could be:

    ICMP6) Validate that the verification tag contained in the ICMP
           message matches the verification tag of the peer.
           If the verification tag is not 0 and does NOT match,
           discard the ICMP message. If it is 0 and the ICMP message 
contains
           enough bytes to verify that the chunk type is an INIT chunk
           and that the initiate tag matches the tag of the peer continue
           with ICMP7. If the ICMP message is too short, the chunk type
           or the initiate tag does not match, silently discard the 
packet.

ICMP8 must then read like

    ICMP8) If the ICMP code is a "Unrecognized next header type
           encountered" or a "Protocol Unreachable" treat this message
           as an abort with the T bit set if it does not contain an
           INIT chunk. If it does contain an INIT chunk and the 
association
           is in COOKIE-WAIT state, handle the ICMP message like an 
ABORT.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Mon, 19 Sep 2005 15:58:41 -0400

Vlad/Michael:

I like Michael's proposed changes..

Vlad, do these seem like what you had in
mind?

R

Michael Tuexen wrote:
>           or the initiate tag does not match, silently discard the packet.
> 
>           INIT chunk. If it does contain an INIT chunk and the association
>           is in COOKIE-WAIT state, handle the ICMP message like an ABORT.
> 
> Best regards
> Michael
>

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 19 Sep 2005 16:03:15 -0400

Yes, I like Michael's changes as well.

-vlad