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

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

Michael,

1) The attack in section 2 does not affect any non-SCTP capable hosts, and that is what we are discussing about.
2) It is NOT a MUST to send an ABORT as a reply for OOTB packets, but for an SCTP-aware host it may be much more important because it may receive a huge amount of pakets e.g. as a result of an lost association. 

Best Regards
Wolfgang

> -----Ursprüngliche Nachricht-----
> Von: Michael Tuexen [mailto:[email-masked]] 
> Gesendet: Dienstag, 20. September 2005 15:44
> An: [email-masked]
> Cc: [email-masked]; Vlad Yasevich; Schruefer, Wolfgang; 
> Randall Stewart; Kacheong Poon; Scott Bradner; Coene, Lode
> Betreff: Re: [Tsvwg] ICMP issue with SCTP IG
> 
> Brian,
> 
> two comments:
> 
> 1. Only verifying one address at a time helps in Attack 5 and 6
>     but does exactly the opposite to the attack in section 2.
>     So there are situations where it is better to use more HEARTBEATs
>     and other where less is better. That is why we limited them
>     by Max.Burst.
> 
> 2. Do not restrict the discussion to the threat ID. This documents
>     only what is currently known by the authors.
> 
>     So if you say ICMP handling is not necessary, the same would
>     apply the sending an ABORT for OOTB packets. It is the same
>     reaction of a host, just by sending 'different packets'. But
>     basically it means: Stop sending packets, I do can not handle
>     them.
> 
>     If you would also say ABORT handling for OOTB packets is not
>     necessary, then SCTP aware and SCTP unaware host would be treated
>     the same.
> 
> Best regards
> Michael
> 
> On Sep 20, 2005, at 14:51 Uhr, Brian F. G. Bidulock wrote:
> 
> > Michael,
> >
> > The amplification in 5 and 6 of that document can be handled 
> > differently.
> >
> > Simply verify one address at a time, and do not verify 
> another until 
> > the first one checks out. (Remove amplification in number 
> of addresses 
> > sent in INIT.) Force reverification of the INIT address on each 
> > failure of an unverified address (forces attacker to send 
> one packet 
> > for each packet sent to victim, removing amplification on 
> > retransmission for verification.)
> >
> > Then amplification is removed and ICMP handling is then moot.
> >
> > --brian
> >
> > On Tue, 20 Sep 2005, Michael Tuexen wrote:
> >
> >> Wolfgang,
> >>
> >> section 6 of
> >>
> >> http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpthreat
> >> -03.txt
> >>
> >> describes an attack where the victim stops an attack by itself by 
> >> sending an ABORT in case of being SCTP capable. If it does not 
> >> support it can only send ICMP(protocol unreachable) to stop the 
> >> attack.
> >>
> >> If a network administrator enabled filtering for these 
> ICMP messages, 
> >> the ICMP message will not reach the sender of the SCTP 
> packets. But 
> >> this was then done by manual intervention. However, if the 
> sender of 
> >> the SCTP packets does not process the ICMP there is no way 
> that the 
> >> victim can secure itself (by sending an ICMP(protocol 
> unreachable)) 
> >> the same way a SCTP capable node would do.
> >>
> >> Without the ICMP handling the attack in section 6 is more 
> efficient 
> >> against non-SCTP aware hosts than it is against SCTP aware hosts.
> >> The difference is, what bothers me.
> >>
> >> I also think that we should no restrict our decision (MUST 
> vs SHOULD) 
> >> on the attacks currently known and documented in the above ID. As 
> >> said above, the difference between SCTP-aware and 
> SCTP-unaware hosts 
> >> is what makes me think that MUST is appropriate. However, 
> if someone 
> >> presents some valid reasons in particular circumstances that the 
> >> difference does not matter, I could think about this again.
> >>
> >> Best regards
> >> Michael
> >>
> >>
> >>
> >> On Sep 20, 2005, at 12:38 Uhr, Schruefer, Wolfgang wrote:
> >>
> >>> Randy:
> >>>
> >>> We need to clarify whether your statement is true: Is it possible 
> >>> -without ICMP handling- to misuse an SCTP-stack as a tool 
> to attack 
> >>> hosts that do not support SCTP?
> >>> In my opinion SCTP MUST NOT be a security risk without ICMP 
> >>> handling, because there will be SCTP servers behind 
> Firewalls that filter ICMP.
> >>>
> >>> And I can tell you one (theoretical) reason (beside implemetation 
> >>> specific ones) not to handle ICMP:
> >>> The ICMP message can be seen itself as a security risk 
> (e.g. behind 
> >>> a Firewall that seperates SCTP but not ICMP ... or imagine a DOS 
> >>> attack by ICMP messages, ...).
> >>>
> >>> Nevertheless, I agree that ICMP handling SHOULD be implemented ...
> >>> because that is exactly why it is made for ... but it causes no 
> >>> severe consequences if it is not implemented.
> >>>
> >>> Best Regards
> >>> Wolfgang
> >>>
> >>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Randall Stewart [mailto:[email-masked]]
> >>>> Gesendet: Dienstag, 20. September 2005 10:54
> >>>> An: Schruefer, Wolfgang; Scott Bradner
> >>>> Cc: Vlad Yasevich; Coene, Lode; Kacheong Poon; [email-masked]
> >>>> Betreff: Re: AW: [Tsvwg] ICMP issue with SCTP IG
> >>>>
> >>>> Schruefer, Wolfgang wrote:
> >>>>> 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
> >>>>>
> >>>>
> >>>> 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)
> >>>>
> >>>
> >>> _______________________________________________
> >>> tsvwg mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/tsvwg
> >>>
> >>
> >>
> >> _______________________________________________
> >> tsvwg mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/tsvwg
> >
> > -- 
> > 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 ¦
> >
> 
> 

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Sep 2005 13:02:15 -0400

Schruefer, Wolfgang wrote:
> Michael,
> 
> 1) The attack in section 2 does not affect any non-SCTP capable
> hosts, and that is what we are discussing about. 

I believe it is Section 5 that has the
non-SCTP aware host.

R

2) It is NOT a MUST
> to send an ABORT as a reply for OOTB packets, but for an SCTP-aware
> host it may be much more important because it may receive a huge
> amount of pakets e.g. as a result of an lost association.
> 
> Best Regards Wolfgang
> 
> 
> 
> 
>> -----Ursprüngliche Nachricht----- Von: Michael Tuexen
>> [mailto:[email-masked]] Gesendet: Dienstag, 20.
>> September 2005 15:44 An: [email-masked] Cc: [email-masked];
>> Vlad Yasevich; Schruefer, Wolfgang; Randall Stewart; Kacheong Poon;
>> Scott Bradner; Coene, Lode Betreff: Re: [Tsvwg] ICMP issue with
>> SCTP IG
>> 
>> Brian,
>> 
>> two comments:
>> 
>> 1. Only verifying one address at a time helps in Attack 5 and 6 but
>> does exactly the opposite to the attack in section 2. So there are
>> situations where it is better to use more HEARTBEATs and other
>> where less is better. That is why we limited them by Max.Burst.
>> 
>> So if you say ICMP handling is not necessary, the same would apply
>> the sending an ABORT for OOTB packets. It is the same reaction of a
>> host, just by sending 'different packets'. But basically it means:
>> Stop sending packets, I do can not handle them.
>> 
>> Best regards Michael
>>>> describes an attack where the victim stops an attack by itself
>>>> by sending an ABORT in case of being SCTP capable. If it does
>>>> not support it can only send ICMP(protocol unreachable) to stop
>>>> the attack.
>>>> 
>>>> against non-SCTP aware hosts than it is against SCTP aware
>>>> hosts. The difference is, what bothers me.
>>>> 
>>>> on the attacks currently known and documented in the above ID.
>>>> As said above, the difference between SCTP-aware and
>> 
>> SCTP-unaware hosts
>> 
>>>> presents some valid reasons in particular circumstances that
>>>> the difference does not matter, I could think about this again.
>>>> 
>>>> 
>>>> Best regards Michael
>>>> 
>>>> 
>>>> 
>>>>> We need to clarify whether your statement is true: Is it
>>>>> possible -without ICMP handling- to misuse an SCTP-stack as a
>>>>> tool
>> 
>> to attack
>> 
>>>>> hosts that do not support SCTP? In my opinion SCTP MUST NOT
>>>>> be a security risk without ICMP handling, because there will
>>>>> be SCTP servers behind
>> 
>>>>> And I can tell you one (theoretical) reason (beside
>>>>> implemetation specific ones) not to handle ICMP: The ICMP
>>>>> message can be seen itself as a security risk
>> 
>> (e.g. behind
>> 
>>>>> a Firewall that seperates SCTP but not ICMP ... or imagine a
>>>>> DOS attack by ICMP messages, ...).
>>>>> 
>>>>> Nevertheless, I agree that ICMP handling SHOULD be
>>>>> implemented ... because that is exactly why it is made for
>>>>> ... but it causes no severe consequences if it is not
>>>>> implemented.
>>>>> 
>>>>> Best Regards Wolfgang
>>>>> 
>>>>> 
>>>>> 
>>>>>> -----Ursprüngliche Nachricht----- Von: Randall Stewart
>>>>>> [mailto:[email-masked]] Gesendet: Dienstag,
>>>>>> 20. September 2005 10:54 An: Schruefer, Wolfgang; Scott
>>>>>> Bradner Cc: Vlad Yasevich; Coene, Lode; Kacheong Poon;
>>>>>> [email-masked] Betreff: Re: AW: [Tsvwg] ICMP issue with
>>>>>> SCTP IG
>>>>>> 
>>>>>>> Imagine an SCTP host behind an Firewall filtering the
>>>>>>> ICMP messages: Viewed from the network side this SCTP
>>>>>>> host would behave
>>>>>> 
>>>>>> not compliant!
>>>>>> 
>>>>>>> Best Regards 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?
>>>>>> 
>>>>>> -- Randall Stewart 803-345-0369 <or> 815-342-5222(cell)
>>>>>> 
>>>>> 
>>>>> _______________________________________________ tsvwg mailing
>>>>> list [email-masked] 
>>>> _______________________________________________ tsvwg mailing
>>>> list [email-masked] 
>>> -- 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 ¦
> _______________________________________________ tsvwg mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> 
>

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Sep 2005 19:12:07 +0200

Hi Wolfgang,

see my comments in-line.

Best regards
Michael

On Sep 20, 2005, at 16:56 Uhr, Schruefer, Wolfgang wrote:

> Michael,
>
> 1) The attack in section 2 does not affect any non-SCTP capable hosts, 
> and that is what we are discussing about.
Your are right. But Brian suggested to send a smaller (he suggested 1) 
number HBs.
I only wanted to point out that doing this helps in Section 5/6 but 
does the opposite
in other scenarios where you want a large number. That is why we have 
chosen a number in between.
> 2) It is NOT a MUST to send an ABORT as a reply for OOTB packets, but 
> for an SCTP-aware host it may be much more important because it may 
> receive a huge amount of pakets e.g. as a result of an lost 
> association.
That is correct. And (I guess) it is NOT a MUST to send ICMP(protocol 
unreachable). They
are handled the same.

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Sep 2005 13:24:42 -0400

Michael Tuexen wrote:

>> receive a huge amount of pakets e.g. as a result of an lost association.
> 

Sending may not be a MUST.. but I think processing an
ABORT is a MUST.. and I would need to check the host requirements
document.. but I bet handling a ICMP is a MUST too.. or
equivilant to a MUST if 2119 was not around back then :0

R