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

From: "Meyknecht, Bernward" <[email-masked]>
Date: Thu, 20 Oct 2005 13:32:52 +0200

Hi Randy,

meanwhile I agree with Michael and with his new text, written after 
my email from below, his new text is fine for me.

Bernie

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Randall Stewart
Gesendet: Donnerstag, 20. Oktober 2005 13:24
An: Meyknecht, Bernward
Cc: [email-masked]; [email-masked]; Coene, Lode; Vlad Yasevich; Michael Tuexen; Schruefer, Wolfgang; Kacheong Poon; Scott Bradner
Betreff: Re: AW: [Tsvwg] ICMP issue with SCTP IG

Bernward:

I agree with Michael and Brian.. and I think
most all the other developers that have not
chimed in here objecting (I think you are
alone in objecting to the must)..

This is a MUST

R

Meyknecht, Bernward wrote:
>  
> Hi all,
> 
> I'm not content with the new section on ICMP handling for the SCTP IG, incl. 
> the 'MUST' for ICMP handling within an SCTP specification, and propose to replace 
> it by a weaker wording and moving the section to another place.
> 
> I would of course never propose to delete the ICMP section from the IG, but for me 
> it is something to be described in an appendix of the SCTP specification, as it is 
> done in the actual issue 15 of the IG, without the wording 'MUST', but with 
> something like '...should be followed to assure proper utilization of the information 
> being provided by layer 3', which is the current wording.
> 
> Adding ICMP handling to SCTP was motivated by attack scenarios described in the 
> draft draft-stewart-tsvwg-sctpthreat-03.txt, okay.
> But the other enhancements being described for SCTP within the new IG section, 
> i.e. amplification control, path verification (small hb.max.burst) and aborting 
> when receiving an ack for an unsent TSN, etc.
> these are exactlay the counter measures taken on SCTP level to prevent the 
> attacks. Besides that there is a number of circumstances on which the attacks 
> depend, i.e. which are necessary to allow the attack at all.
> With an SCTP implementation having the SCTP enhancements as mentioned above I 
> don't see the relevance of these attacks on SCTP any more.
> 
> Besides that I see ICMP as something belonging to a layer below SCTP, the SCTP 
> RFC should describe only the SCTP level, hints on ICMP handling could be part
> of an extra document/draft, even in a future RFC.
> 
> Kind regards,

-- 
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: Randall Stewart <[email-masked]>
Date: Thu, 20 Oct 2005 08:14:20 -0400

> my email from below, his new text is fine for me.

As long as you understand that you MUST process ICMP... Even 1122
makes this a MUST:

Receiving ICMP Messages from IP                  |4.2.3.9 |x| | | | |
   Dest. Unreach (0,1,5) => inform ALP            |4.2.3.9 | |x| | | |
   Dest. Unreach (0,1,5) => abort conn            |4.2.3.9 | | | | |x|
   Dest. Unreach (2-4) => abort conn              |4.2.3.9 | |x| | | |
   Source Quench => slow start                    |4.2.3.9 | |x| | | |
   Time Exceeded => tell ALP, don't abort         |4.2.3.9 | |x| | | |
   Param Problem => tell ALP, don't abort         |4.2.3.9 | |x| | | |

                                                            ^
                                                            |
This is the MUST colum... and note Receiving ICMP msg's is
a MUST.

Now how to handle is a LOT of SHOULDs.. but I have an issue
with this.. and I will post it seperate... with a special add
on of Bob Braden.. and a few others...

R