Subject: Re: [Tsvwg] ICMP handling

From: "Schruefer, Wolfgang" <[email-masked]>
Date: Mon, 19 Sep 2005 17:50:27 +0200

I agree to all proposed modifications it the appendix and in the IG, beside this new proposed chapter 11.4. .
>From my point of view it is inappropriate.

Reasons:

1) I think it is not correct that non-SCTP capable hosts are in danger to receive a large number of SCTP packets due to a DOS attack ... at least I know no scenario for it ... and I think a great care was spent to avoid this, e.g. with the path initialisation issue ... now any external reader may think that an SCTP without that ICMP-handling is a serious security risk!
SCTP itself can not trust that ICMP packets receive the sender, due to Firewalls or other restrictions. Therefore the SCTP stack must avoid a security risk without relying on ICMP! 

2) Anyhow I think it is too strong: There may be reasons to deactivate that handling, e.g. for performance reasons in a protected network. 

3) There was already a new RFC-chapter 11.4. introduced in IG chapter 2.11 ... this chapter number does not work.

4) Everything is said in the appendix. Why a new chapter? I would leave it out...

Best Regards
Wolfgang

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Randall Stewart
> Gesendet: Donnerstag, 15. September 2005 19:50
> An: Vlad Yasevich
> Cc: Michael Tuexen; [email-masked]'
> Betreff: Re: [Tsvwg] ICMP handling
> 
> Well.. I don't see why not..
> 
> The CRC32c algorithm is an appendix (and so was the orginal 
> Adler32).. and without any of these you definetly will NOT be 
> able to get any packets accepted from a peer.
> 
> As to ICMP.. its not per.se. part of the protocol.. so I 
> don't see how it would fit in any protocol section... So it 
> seems an ok fit to me :-D
> 
> R
> 
> Vlad Yasevich wrote:
> > Randy
> > 
> > Randall Stewart wrote:
> > 
> >>---------
> >>Old text: Section 11.3
> >>---------
> >>
> >>   SCTP also provides no protection against attacks 
> originating at or
> >>   beyond the SCTP node and taking place within the context of an
> >>   existing association.  Prevention of such attacks should 
> be covered
> >>   by appropriate security policies at the host site, as 
> discussed in
> >>   Section 11.2.1.
> >>
> >>
> >>---------
> >>New text: Section 11.3
> >>---------
> >>
> >>   SCTP also provides no protection against attacks 
> originating at or
> >>   beyond the SCTP node and taking place within the context of an
> >>   existing association.  Prevention of such attacks should 
> be covered
> >>   by appropriate security policies at the host site, as 
> discussed in
> >>   Section 11.2.1.
> >>
> >>11.4 Protection of non-SCTP capable hosts.
> >>
> >>   In order to assure non-SCTP capable hosts are not sent large
> >>   numbers of SCTP packets incorrectly all SCTP stacks MUST
> >>   implement the ICMP handling described in Appendix C.
> > 
> > 
> > Is it OK to require so strongly an implementation of an Appendix?
> > 
> > 
> > -vlad
> > 
> > 
> 
> 
> --
> Randall Stewart
> 803-345-0369 <or> 815-342-5222(cell)
> 
> _______________________________________________
> 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: Michael Tuexen <[email-masked]>
Date: Mon, 19 Sep 2005 18:26:39 +0200

Hi Wolfgang,

see my comments in-line.

Best regards
Michael

On Sep 19, 2005, at 17:50 Uhr, Schruefer, Wolfgang wrote:

> 1) I think it is not correct that non-SCTP capable hosts are in danger 
> to receive a large number of SCTP packets due to a DOS attack ... at 
> least I know no scenario for it ... and I think a great care was spent 
> to avoid this, e.g. with the path initialisation issue ... now any 
> external reader may think that an SCTP without that ICMP-handling is a 
> serious security risk!
> SCTP itself can not trust that ICMP packets receive the sender, due to 
> Firewalls or other restrictions. Therefore the SCTP stack must avoid a 
> security risk without relying on ICMP!
You are right, the text is misleading a bit. How about

11.5 Protection of non-SCTP capable hosts.

    To provide non-SCTP capable host with the same level of
    protection against attacks as SCTP capable ones all SCTP
    stacks MUST implement the ICMP handling described in Appendix C.

>
> 2) Anyhow I think it is too strong: There may be reasons to deactivate 
> that handling, e.g. for performance reasons in a protected network.
>
> 3) There was already a new RFC-chapter 11.4. introduced in IG chapter 
> 2.11 ... this chapter number does not work.
Good catch.
> 4) Everything is said in the appendix. Why a new chapter? I would 
I think it is good to mention the appendix in the main text such that 
it is clear for readers what the
role of the appendix is.

---

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

>    stacks MUST implement the ICMP handling described in Appendix C.

I like the above text MUCH better than the previous... I will
substitute it...

>> 2.11 ... this chapter number does not work.

Yes indeed :-D

> I think it is good to mention the appendix in the main text such that it 
> is clear for readers what the
> role of the appendix is.
> 

No matter how you slice it I do think the ICMP handling MUST be a MUST.
Go look at the sctp-threats draft and you might be convinced.

R