Subject: AW: [Tsvwg] ICMP issue with SCTP IG

From: "Schruefer, Wolfgang" <[email-masked]>
Date: Tue, 20 Sep 2005 10:24:20 +0200

Randy,

like Vlad I am convinced that it is sufficient to say SHOULD or RECOMMENDED.

Imagine an SCTP host behind an Firewall filtering the ICMP messages:
Viewed from the network side this SCTP host would behave not compliant! 
We must decide whether that is a security risk or not ...

Best Regards
Wolfgang

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Vlad Yasevich
> Gesendet: Montag, 19. September 2005 18:41
> An: Randall Stewart
> Cc: Coene, Lode; Kacheong Poon; [email-masked]
> Betreff: Re: [Tsvwg] ICMP issue with SCTP IG
> 
> 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
> 
> Randall Stewart wrote:
> > 
> > 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
> > 
> > 
> 
> _______________________________________________
> 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: Randall Stewart <[email-masked]>
Date: Tue, 20 Sep 2005 04:54:28 -0400

> We must decide whether that is a security risk or not ...

Wolfgang:

Not everyone has a firewall up and believe it or not
some f/w's even let ICMP unreachables through.. depending
on configuration of course.

No network, no matter how you plug it together will have
SCTP supported everywhere. Thus if your SCTP stack
does NOT process ICMP's then it can be used as a
tool to attack hosts that DO NOT support SCTP.
This alone is sufficent grounds IMO to make it a
MUST...

What valid reason, other than being lazy, does an
implementation have in not handling ICMP?

Scott: I would like your opinion?

R

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Sep 2005 13:40:55 +0200

Hi Wolfgang,

the ICMP(protocol unreachable) handling brings non-SCTP aware hosts
to the same level of protection as SCTP-aware hosts. They are capable
of sending something like an ABORT without being able to support SCTP.

Since you are suggesting SHOULD and RFC 2119 states:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

it would be necessary to know some 'valid reasons in particular 
circumstances'
under which it is sufficient that a non-SCTP aware host has no 
mechanisms to
interact with SCTP-aware hosts.

Best regards
Michael