Subject: [Tsvwg] ICMP handling with SCTP

From: Randall Stewart <[email-masked]>
Date: Thu, 20 Oct 2005 08:36:49 -0400

All:

Ok, I have once again re-drafted the ICMP handling text for SCTP's I-G.
Now, for those others of you on the to list you are wondering..
why is this email addressed to me... well its because I think
there is yet one issue that we have not obtained closure on and
it is IMO a security one... (thats why you are on here Eric) and
it also deals with RFC1122 (Bob/Fred thats why you got added). The
chairs to the tsv are also added.. since this is there wg and I
think a chair response (and possibly an AD response is also
warrented :-d)

So at the bottom of this email I will attached the "updated" wording
to the SCTP ICMP handling section of the I-G.. for those of you
following you will see it is only slightly tweaked.. The hot issue
is the MUST's used in ICMP8. For the new folks added that I KNOW
have not been following this long thread.. let me try to summarize the
issue.

RFC1122 specifies that TCP SHOULD observer a protocol unreachable
message and abort the connection. But in SCTP's case we have
been debating between a MUST and a SHOULD.. so why?

Consider this scheme (detailed in the sctp-threats document):

Evil-A                           Server-Z
(owns IP-A only)                  (owns IP-Z)

-------INIT(IP-A, IP-1, IP-2, IP-3)------>
            <... rest of 4-way handshake..>

Now if IP-1/2 and 3 are owned by hosts that DO NOT
understand SCTP.. there are various schemes (I won't
go in to.. you can look at these in
draft-stewart-tsvwg-sctpthreat-xx.txt if you want)
that you can get Server-Z to bombard and amplify data
to IP-1/2 and 3.

If, however, Server-Z's stack observes the ICMP messages
as detailed below.. and we do have a MUST.. then the first
HB (or any msg for that matter) that sends back a ICMP protocol
Unreachable will kill the association thus foiling the
evil attackers schemes :-D.

This is quite a bit different than TCP in that TCP could only
effect the source IP address of the SYN.. where as SCTP
can stuff all these other IP addresses in place... So
IMO handling a Protocol Unreachable really reaches the
level of MUST abort.. not SHOULD abort...

But there-in lies the problem.. this is different than what
RFC-1122 does.. and since it is different we have a running
SHOULD/MUST debate.. that I am looking for your wisdom to
help us decide..

Does this case warrent being more strict on an SCTP implementation?

I think it does..

Thanks in advanced for your kind responses..
---------------------------------------------------
Now.. Here is the actual text for the wg.. Note that ICMP9 and ICMP8
were redundant (they were almost word-for-word identical.. so I
collapsed them down).

For Brian and others.. note I put a lot of MAY's in so that
the only ICMP binding thing is
1) use the data in the ICMP msg to find the assoc
2) use the Vtag to validate that the ICMP is not forged
3) treat the protocol unreachable message as an ABORT.

All others become just "MAY"

*********************************************************
Whenever an ICMP message is received by an SCTP endpoint the
following procedures MUST be followed to assure proper
utilization of the information being provided by layer 3.

ICMP1) An implementation MAY ignore all ICMPv4 messages
        where the type field is not set to "Destination
        Unreachable".

ICMP2) An implementation MAY ignore all ICMPv6 messages
        where the type field is not "Destination Unreachable,
        "Parameter Problem" or "Packet Too Big".

ICMP3) An implementation MAY ignore any ICMPv4 messages
        where the code does not indicate "Protocol Unreachable"
        or "Fragmentation Needed".

ICMP4) An implementation MAY ignore all ICMPv6 messages
        of type "Parameter Problem" if the code is not
        "Unrecognized next header type encountered".

ICMP5) An implementation MUST use the payload of the
        ICMP message (V4 or V6) to locate the association
        which sent the message that ICMP is responding to.
        If the association cannot be found, An implementation SHOULD
        ignore the ICMP message.

ICMP6) An implementation MUST 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 or, the chunk type or the
        initiate tag does not match, silently discard the packet.

ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
        "Fragmentation Needed" an implemenation MAY process this
        information as defined for PATH MTU discovery.

ICMP8) If the ICMP code is a "Unrecognized next header type
        encountered" or a "Protocol Unreachable" an implementation
        MUST 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.

ICMP9) If the ICMPv6 code is "Destination Unreachable" the
        implementation MAY mark the destination into the unreachable
        state or alternatively increment the path error counter.

*************************************************************************

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

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 20 Oct 2005 23:13:05 +0200

Dear all,

RFC 1122 also says:

             A transport protocol
             that has its own mechanism for notifying the sender that a
             port is unreachable (e.g., TCP, which sends RST segments)
             MUST nevertheless accept an ICMP Port Unreachable for the
             same purpose.

Should this also be done by SCTP? As Randy already pointed out that he
prefers a difference between the RFC 1122 handling and the SCTP Impl  
Guide,
I also prefer to NOT follow RFC 1122 on ICMP(port unreachable)and use  
the
handling for ICMP(port unreachable) as described by the ICMP rules  
below.
However, I think adding a sentence making this difference clear would  
help the
reader finding the text below and RFC 1122 contradicting each other.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Oct 2005 17:35:02 -0600

Michael,

I agree, the distinction should be highlighted.

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