Subject: SCTP and ICMP Protocol Unreachable

From: Stephane Chazelas <[email-masked]>
Date: Mon, 18 Sep 2006 11:41:58 +0100

Hi guys,

I'm posting to both the SCTP and [email-masked] mailing lists,
as I could find a related discussion in that latter one
archives.

The SCTP implementor's guide, RFC 4432 and 2960bis (that is the
latest SCTP specifications) say that when receiving an ICMP
Protocol Unreachable for a packet sent for an association, the
association should be aborted (considered aborted actually).

Now, please consider that scenario (and that's a real life one
as I could observe it):

A and B have two interfaces, one being a normal ethernet one
on a company network protected by a firewall (two different
companies) and a second being on some VPN that link them
together.

The firewall of either or both of those companies doesn't
support SCTP so replies an ICMP Protocol Unreachable for  every
SCTP packet that one attempts to send through it.

Both A and B have SCTP stacks configured to used both their
interfaces.

If A wants to initiate a connection with B over the VPN, it will
send an INIT to the address of B's interface on that VPN
(mentionning its other address). Everything will go fine up to
the COOKIE-ACK. Then B will try to confirm A's other address
(the one not on the VPN) by sending a HEARTBEAT. Unfortunately,
the route to A's other address from B is via its company
firewall that doesn't support/track/let-through SCTP.

So the association will be aborted even though there is one sane
path (the VPN) between the two hosts.

     A                            B
                INIT
  192.168.1.1 --------------> 192.168.1.2
                INIT-ACK
  192.168.1.1 <-------------- 192.168.1.2
                COOKIE-ECHO
  192.168.1.1 --------------> 192.168.1.2
                COOKIE-ACK
  192.168.1.1 <-------------- 192.168.1.2
                HEARTBEAT
      1.2.3.4 <-------------- 4.5.6.7 (firewalled)
               ICMP proto unreachable
      1.2.3.4 --------------> 4.5.6.7 (B treats that as an ABORT)
                DATA/HEARTBEAT
  192.168.1.1 --------------> 192.168.1.2
                 ABORT
  192.168.1.1 <-------------- 192.168.1.2

Why is that so? Why doesn't the spec just say that the address
should be considered unreachable when an ICMP Protocol
Unreachable is received?

I understand it makes sense for an INIT as there's no point
waiting for an INIT-ACK if you receive that ICMP message.

I also read about the SCTP security draft that stated that it
was there (together with the requirement to confirm an address
before sending some data to it) to avoid an attacker to have
some server flood someone else by using that someone else's
address in its INIT. But I don't see why an abortion (rather
than marking the address unreachable) is necessary in that case.

Could someone please clarify what was the purpose of aborting an
association upon receiving an ICMP Protocol Unreachable?

Here is a wireshark capture:

From one end:

 80.804125 192.168.13.2 -> 192.168.13.1 SCTP INIT
 80.805116 192.168.13.1 -> 192.168.13.2 SCTP INIT_ACK
 80.848242 192.168.13.2 -> 192.168.13.1 SCTP COOKIE_ECHO
 80.849651 192.168.13.1 -> 192.168.13.2 SCTP COOKIE_ACK
 80.849930 10.95.129.182 -> 82.26.164.146 SCTP HEARTBEAT
 80.850257 82.26.164.146 -> 10.95.129.182 ICMP Destination unreachable (Protocol unreachable)
118.446137 192.168.13.2 -> 192.168.13.1 SCTP HEARTBEAT
118.446727 192.168.13.1 -> 192.168.13.2 SCTP ABORT

From the other:

 58.628384 192.168.13.2 -> 192.168.13.1 SCTP INIT
 58.672853 192.168.13.1 -> 192.168.13.2 SCTP INIT_ACK
 58.673289 192.168.13.2 -> 192.168.13.1 SCTP COOKIE_ECHO
 58.716704 192.168.13.1 -> 192.168.13.2 SCTP COOKIE_ACK
 58.717212 192.168.13.2 -> 193.195.26.66 SCTP HEARTBEAT
 61.714867 82.26.164.146 -> 10.95.129.182 SCTP HEARTBEAT
 96.273016 192.168.13.2 -> 192.168.13.1 SCTP HEARTBEAT
 96.312713 192.168.13.1 -> 192.168.13.2 SCTP ABORT

The VPN being 192.168.13.{1,2}

Best regards,
Stephane

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 18 Sep 2006 19:51:56 +0200

I should have used the correct e-mail account....

Begin forwarded message:

> From: Michael Tuexen <[email-masked]>
> Date: September 18, 2006 4:11:54 PM GMT+02:00
> To: Stephane Chazelas <[email-masked]>
> Cc: IETF Transport Area Mailing List <[email-masked]>, SCTP  
> Implementors <[email-masked]>
> Subject: Re: [Tsvwg] SCTP and ICMP Protocol Unreachable
>
> Hi Stephane,
>
> see my comments in-line.
>
> Best regards
> Michael
>
> On Sep 18, 2006, at 12:41 PM, Stephane Chazelas wrote:
>
>> Hi guys,
>>
> Correct. RFC 792 describes, that this message may be sent from
> the destination host in case it does not support SCTP.
>>
> So the firewall is lying... How can it know that the destination
> host does not understand the protocol. All it knows that it
> is configured (implicit or explicit) to drop SCTP packets.
> If you configure the Firewall to send protocol unreachable
> you really do not say "You can not send these packets via
> this path" but "the destination host does not understand
> this protocol".
>>
> Because the semantic of protocol unreachable is: the destination
> host does not support SCTP. This is not path specific.
> The firewall should not lie... It is wrong to send this message.
>>
> If you receive an ICMP Protocol unreachable you know that the
> endpoint does not handle SCTP at the time he received the
> included SCTP packet (could be a crashed userland stack). So
> can not continue to communicate anymore. If the stack would
> support SCTP, he would send an ABORT in that case. That is
> why we handle this ICMP message like an ABORT.
>>
> The problem is really the firewall stating that the endpoint does  
> not understand
> SCTP at all. Is this a common error in firewall configurations?
>>
>> Best regards,
>> Stephane
>>
>>
>

---

From: Stephane Chazelas <[email-masked]>
Date: Tue, 19 Sep 2006 14:43:59 +0100

On Mon, Sep 18, 2006 at 04:11:54PM +0200, Michael Tuexen wrote:
[...]
> >SCTP packet that one attempts to send through it.
[...]
> this path" but "the destination host does not understand
[...]

Hi Michael,

thanks for this information. I did jump a little too quick to a
conclusion after my observation indeed, and I understand how
this firewall (or whatever that sends that ICMP message) is
wrong to do so, at least as far as RFC1122 compliance is
concerned.

Now, my wonder is: what should this firewall send instead then
(especially when it doesn't know anything about SCTP)? I
understand it could simply drop that packet, but giving back a
notification to the sender is quite a nice thing to do, at least
to prevent the source to send unnecessary packets (the source
would keep trying and sending more HEARTBEAT/INIT in the drop
case, and the association establishment (in case of INIT)
failure would be detected a lot more slowly)

From what I read of RFC1122, it's the same thing for "port
unreachable". I think the idea in RFC1122 is that the pieces of
equipment on a path from a source to destination are
gateway/routers, with a stack up to IP/ICMP only. They are not
supposed to deal with the higher levels (what the IP packet
payload contains). So there's no reason why they should be
discriminating on the transport protocol or on source or
destination port of the transport protocol.

But now, we have firewalls. Firewalls do filter at transport
level (and above and below), by filtering on source and
destination port and keeping track of the state of the transport
level connections.

I can see that the REJECT rule for Linux ipfilter uses a port
unreachable ICMP destination unreachable message by default.

It is the same kind of /error/. When you do a telnet foo 123,
and get a "connection refused", you understand it as there's
nobody listening to that port on the destination. While
actually, the firewall is the one that tells you that, so is
lying to you again. But, still that's what the administrator of
the remote network wants you to think (that that port is not
available to you).

And it's the same idea for "protocol unreachable", your network
administrator doesn't want you to use any unknown protocol to
access the /internet/, so lets you know it with the tools
available to him: the "icmp protocol unreachable". Now, is there
any better tool?

Also, the new SCTP RFC draft says:

| The stricter handling of the "protocol unreachable" message is
| due to security concerns for hosts that do NOT support SCTP.

What are they refering to?

Best regards,
Stephane

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 20 Sep 2006 08:59:34 +0200

Hi Stephane,

see my comments in-line.

Best regards
Michael

> destination port of the transport protocol.
The problem here is that SCTP support multihoming. For TCP and
UDP the firewall admin know if the firewall drops the packet,
there will be no communication to the destination.

For SCTP it is different (as in your example): There is no
way to reach the destination via that firewall, but possibly there
are other paths. Since there are no ways of sending an ICMP
packet which says you can not reach the destination with this
transport protocol via me, there are only two ways the
firewall can react with two different consequences:
- Just drop the packet. Do not send anything back.
   SCTP will work fine. It will continue to send HB, but at
   a low rate. The admin should configure the firewall like
   this when he want to forbid SCTP based communication via
   this firewall but allows it via other paths. Especially he
   does not forbid the SCTP based communication of a host within
   his network completely, only via this firewall.
- Drop the packet and send back ICMP, Destination unreachable,
   Protocol unreachable. The admin should configure the firewall
   like this if he wants to forbid the SCTP based communication
   of host inside his network at all.

In your example there was a different path and you wanted to
communicate via it. If this is within the policy of your
network, the first configuration should be used and the
second one is wrong...
> available to him: the "icmp protocol unreachable". Now, is there
Not one I know of? I would just prefer that the SCTP packets are
dropped and nothing is sent back. So SCTP can figure out what
is going on. There is no explicit way of saying "No SCTP via
this path" I'm aware of.
> What are they refering to?
The point is that an host not supporting SCTP may sent back
an ICMP, Destination unreachable, Protocol unreachable, when
it receives an SCTP packet. An host supporting SCTP will
sent back an ABORT for an SCTP packet which it does not
want to process. This happens, for example, when a host is
attacked. And we wanted the the host not supporting SCTP is
not put on a higher risk than a host supporting SCTP.
There should be some example in the trat ID.

---

From: Stephane Chazelas <[email-masked]>
Date: Thu, 21 Sep 2006 14:26:57 +0100

On Thu, Sep 21, 2006 at 06:17:59AM -0400, Randall Stewart wrote:
[...]
> If we are <a> then tearing down the association seems right.. you
> try to fool me I won't talk to you..
> 
> If we are <b> and validly own the address and yet have
> a F/W that is mis-configured (sending ICMP protocol unreachable)
> then this seems to me to be either
> 1) A problem with the F/W (i.e. vendor go fix it)
> <or>
> 2) An administrative problem at the SCTP host (don't
>    list IP-B if you want your F/W configured this way).
[...]

Well, in my case, that was the other end that had the broken
firewall. I start an association saying that I have another
(perfectly valid from my point of view) address. The other end
establishes the association, but upon confirming my secondary
address, gets a ICMP DUPU (dest-unreach proto unreach) message
from *his* broken firewall (there, the firewall filters on the
outgoing packets) which tears down the association.

And nevertheless, if it was my end and one of my interfaces goes
through a /broken/ firewall for some destination networks, I
may still want to use it for destinations that don't go through
that firewall.

> If you instead remove the ICMP message treated as an ABORT
> you loose the ability to penalize attackers..

But what harm could the attacker do?

> in fact chance
> are you don't want that state (asoc with IP-A)
> hanging around anyway if its
> an attacker... And you would loose this all for the sake
> of either a broken middle-box (I don't see how any F/W
> should be sending a host level ICMP message).. or a
> misconfigured SCTP endpoint...
[...]

I can see firewalls send "port unreachables" when filtering on
TCP services, that's a host level ICMP message as well.

Best regards,
Stephane

---

From: Randall Stewart <[email-masked]>
Date: Thu, 21 Sep 2006 15:07:25 -0400

> But what harm could the attacker do?
Go take a look at the bombing attacks listed
in the threats draft...

Generally we don't code around broken middle boxes IMO.. we
get the broken middle boxes fixed :-0

> TCP services, that's a host level ICMP message as well.

Port unreachable is even a stretch IMO.. but announcing
that a host does not support a protocol is way over
the top.. and is just plain broken.

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 22 Sep 2006 10:51:57 +0100

On Thu, Sep 21, 2006 at 03:07:25PM -0400, Randall Stewart wrote:
[...]
> Go take a look at the bombing attacks listed

Hi Randall,

Maybe I'm not reading it correctly, but for some of those
bombing attacks, there's more of a justification to drop the
Protocol Unreachable.

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpthreat-01.txt

5) is taken care of by the change to the RFC that every address
must be confirmed first. So that only heartbeats are sent to the
victims

6) the attacker will be able to resend its cookie quickly because
the server considers the ICMP DUPrU as an ABORT. If it didn't it
would have to close the association first.

8,9) unrelated.

So it looks like an attacker can always have a server send a
burst of heartbeats to victims whether or not the ICMP DUPrU is
considered as an ABORT or not.

[...]
[...]

Given that firewalls work at transport level, it may be
considered legitimate that they inpersonate the destination. A
firewall is a bit of a hack anyway. The problem is that IP
doesn't provide them with tools to do their job, so they have to
use hacks/work around. There's no ICMP to say "sorry, no TCP
telnet on that path", so they have to fake a DUPoU from the
destination instead. Similarly, there's no way to tell "sorry,
no SCTP on that path", so they use the ICMP DUPrU.

I'm not trying to push in either direction, I'm just pointing
out that potential issue. The behavior of SCTP (considering the
ICMP DUPrU as an abort) conflicts with that behavior of some
firewalls. Now, we may question ourselves whether that bahavior
is necessary. Maybe the right approach is to come up with new
ICMP codes for usage by the firewalls.

Best regards,
Stephane

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 22 Sep 2006 04:13:32 -0600

Stephane,

Stephane Chazelas wrote:        (Fri, 22 Sep 2006 10:51:57)
> must be confirmed first. So that only heartbeats are sent to the

Well, no.  That was Michael's point (I believe): if you only mark the
destination unusable you will be sending another nonce-HB to the next
destination soon.  If you aborted the association in response to the
ICMP, only one nonce-HB would be sent.  Thus you reintroduce the
amplification if you mark destinations or ignore ICMP.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 22 Sep 2006 11:24:06 +0100

[...]

Yes, but in that case the next HB is only sent after a timeout
(getting longer and longer) while in the 6) case, because the
association is aborted immediately, the attacker is able to
cause another HB to be sent straight away.

Another question is: what would be the motive of the attacker?
Can he clog a network that way? A HB would be rather harmless to
the victim, especially if it doesn't support SCTP.

Best regards,
Stephane

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 22 Sep 2006 04:41:23 -0600

Stephane,

Stephane Chazelas wrote:              (Fri, 22 Sep 2006 11:24:06)
> cause another HB to be sent straight away.

The amplification come from the fact that the attacker need not
send another message to you to get to send another to the vicitim.

When the association is aborted, the attacker can cause you to
send one packet again, but he is going to have to send you two
first.

> the victim, especially if it doesn't support SCTP.

Where there is amplification, a script kiddie can quickly mobilize
the bandwith of her machine times the amplification factor.  So,
as some implementations will easily handle 10 addresses in the
address list, amplification could be 10 or 20.  When the victim
receives 10 to 20 times it available bandwidth in heartbeats, it
will not be doing much useful communication.  It will be spending
all its time sending ICMP messages that you are going to ignore.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 22 Sep 2006 11:51:55 +0100

> send one packet again, but he is going to have to send you two

Why two? Isn't it just the COOKIE-ECHO?

And in the other case, he needs to send a HEARTBEAT-ACK for the
association to stay up.

[...]

But I think that even with the considering of a ICMP DUPrU as an
ABORT, the attacker can do the same and better and cheaper as
with section 6 in the threat draft.

Best regards,
Stephane

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 22 Sep 2006 05:08:05 -0600

Stephane,

Stephane Chazelas wrote:                    (Fri, 22 Sep 2006 11:51:55)
> Why two? Isn't it just the COOKIE-ECHO?

That's 6).  Keep the cookie life-time down and she needs to
send INIT and COOKIE-ECHO.  You send INIT-ACK and nonce-HB.
No amplification.

> And in the other case, he needs to send a HEARTBEAT-ACK for the

I didn't think that Michael and Randall put my suggestion in
(heartbeating the potential attacker with each nonce-HB failure).
Could you point that out?

> with section 6 in the threat draft.

Just keep cookie life-times low.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Sep 2006 07:24:58 -0400

Stephane:

I just do not see the value in continuing to converse
with an attacker that is potentially camping on
other folk's addresses... it will take you a
while to continue to send HB's and time-out.

The ICMP message is a clear sign that the
HOST does not support the protocol.. hey thats
what it means right?

If a F/W is broken. then fix it.. i.e.
be silent.. don't send anything...
If it really had to send back a reply
it could, much more closer to the truth,
send a "network unreachable".. Since it IS
prohibiting you from reaching the network
that you want :-0

Again, I don't think we should be coding around
broken firewalls.. we fix the firewall.. thats the
answer..

R

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 22 Sep 2006 12:56:32 +0100

> while to continue to send HB's and time-out.

The idea is, from my point of view:

Checking for protocol unreachable only makes sense for the INIT.
Any other message sent is sent after that INIT, so if the INIT
went through, there's no reason why the others don't. There may
be reasons due to bad things happening like the SCTP stack at
the other end crashing or the firewall thing or an attacker but
it's not up to a SCTP stack to try and guess what might have
happened.

Now, if there is a security threat and if the threat can only be
worked around at SCTP level, then maybe SCTP should consider
working around the threat.

Now, is there really a security threat in ignoring the ICMP
DUPrU for non-INITs? And does considering the DUPrU as an ABORT
works around that security threat (and can not be worked
around).

> HOST does not support the protocol.. hey thats

Yes, but it has been hijacked by firewalls that use it to say:
no SCTP through me. Just as the ICMP DUPoU have been hijacked to
say "no TCP telnet through me" (for instance).

> be silent.. don't send anything...

But a firewall is being smarter by sending something back
instead, it prevents the sending host from having to timeout
(and hold a resource for several seconds) before dropping the
association.

The problem is just with SCTP because of its multihomed nature.
For every other protocol it's nice to be able to know straight
away that you can't talk.

> prohibiting you from reaching the network

Well, only for that transport protocol. The ICMP message is
intended for the transport stack of the sender, not the IP
stack. We don't want the IP stack of the sender to remove the
route to the destination just because we can't send SCTP we
might still want to send TCP/UDP...

[...]

But is the firewall really broken? The firewall is designed to
work with single-homed transport protocol, can we blame it for
that?

We may now ask ourselves: what should a SCTP aware firewall do?

- send an abort in response to an INIT
- what about other types of chunks. How can you tell a SCTP
  stack: sorry you can't use that path? The only way is probably
  to drop the packets. The sender would keep sending HBs, but
  there may not be anything better that could be done.

Best regards,
Stephane

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Sep 2006 08:17:40 -0400

> it's not up to a SCTP stack to try and guess what might have

A user level stack crashing will cause an ICMP protocol
unreachable.. this is part of the design of IP..

SCTP is not trying to guess what might have happened..
the ICMP message is being interpreted correctly... F/W
vendors need to FIX any F/W that puts this out incorrectly...

> working around the threat.
It does by the rules that were put in.. aka.. use the IP messages
(ICMP) as they are defined.

> say "no TCP telnet through me" (for instance).

First and formost.. its wrong to do this. Second,
I cannot believe that F/W code put in for TCP
is going to do ANYTHING for SCTP... this must
be NEW code added to the F/W to support SCTP.. if
so.. its like any bug in an implementation.. its a BUG..

If its a cisco F/W I would say give me details and I will
put in a Sev 3 DDTS on it... (but I don't think it
is .. since we as yet to my knowledge have not
released code that supports SCTP .. yet when we
do we won't be sending that message...)

> (and hold a resource for several seconds) before dropping the

But how does this F/W message help you not hold resources then?
You are advocating ignoring the message.. your resources are
still held then..

> away that you can't talk.

And in a single homed nature it is just like an ABORT... no
different...

> might still want to send TCP/UDP...

IMO it should send NOTHING back... F/W that support
SCTP should NOT be sending HOST level messages...

> work with single-homed transport protocol, can we blame it for

If that were so the F/W would still NOT support SCTP.. If
you add SCTP support to a F/W then you had better do
the right thing and NOT send back this ICMP message.

You cannot tell me that this F/W did not have code
added to it to support SCTP... if you do I won't
believe you..

They may have just cloned TCP code.. I will grant
you.. but that is incorrect .. they have to look
at what the transport protocol is doing and make
sure they do the right thing...

Its a bug.. I will not support changing a spec for
a F/W bug..

>   there may not be anything better that could be done.

Easy.. drop the packet silently.

You will slowly send packets and then disable the
destination.

R

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 22 Sep 2006 13:09:41 +0100

> send INIT and COOKIE-ECHO.  You send INIT-ACK and nonce-HB.

You can't always keep the cookie lifetime low. You want to let
people connecting via sattelite in China to be able to talk to
your server.

Even if the attacker manages to send only 3 COOKIE-ECHOs before
having to send another INIT, there's still amplification.

> Could you point that out?

I meant that the server will periodically send heartbeats to the
attacker as well. And it will send it sooner than the second HB
to a victim because the attacker replies to the heartbeats
contrary to the victims.

-- 
Stephane

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Sep 2006 08:27:50 -0400

> people connecting via sattelite in China to be able to talk to

Well.. even though the above is Brian's comment.. I will say
hes correct.. if you worry about this keep the lifetime low.
There are procedures in SCTP to ask for longer lifetimes
(when needed)... so this should not be a problem.

A sat link is 550ms RTT for geo-stationary.. setting the
cookie life to 2 seconds will accomplish leting you get
a couple of C-E through.. you could even set it
to 1 second if you desired... and if the guy
gets a stale cookie error he can ask for a longer
time... no problem... you might not grant him
it.. but he can ask :-D
> having to send another INIT, there's still amplification.
-----CE--->
<----CA----
<----HB----
----ABORT/ICMP--->
.. tear down.

I think you point out why you DON'T want to ignore
the ICMP message.. since a windows box that does not
support SCTP (none of them do yet :-( ) will send you
back an ICMP... so in this case the attackers association
will get torn out right away.. if we silently drop
your ICMP's from your buggy F/W (what you advocate) then
we get:
A-----CE--->
V<----CA----
V<----HB----
V---ICMP---> <ignored>
A-----CE--->
V<----CA---
V<---HB-----

So basically the attacker can amplify the CE for as
long as the cookie life is valid as long as you ignore
the ICMP messages the Victim host is sending...

This is EXACTLY why you do NOT want to ignore the ICMP
and broken F/W's will need to fix there code that
handles SCTP to silently drop the packet and NOT
send a host level ICMP back saying the protocol is
unreachable..

> to a victim because the attacker replies to the heartbeats

The first HB's are to NON attacket addresses listed.. i.e. the
unconfirmed ones. Which allows the ICMP's to come back and
tear down the association.

Your "solution" to a F/W bug opens up this very attack.

Broken F/W's should be fixed...

R

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 22 Sep 2006 14:45:30 +0100

On Fri, Sep 22, 2006 at 08:17:40AM -0400, Randall Stewart wrote:
[...]
> so.. its like any bug in an implementation.. its a BUG..

I din't mean that the firewall supports SCTP.

I think there's a rule that says, reject anything but TCP, ICMP
or UDP... Then filter based on ports...

> do we won't be sending that message...)

I believe it's a Cisco one, it's hard to tell who sends that
ICMP message as all the TTLs appear to be mingled with by
something. I'll try and investigate more.

[...]
> You are advocating ignoring the message.. your resources are

I meant on the INIT. Normally (for single homed connection
protocols), there shouldn't be anything sent past the session
initiation request message (SYN/INIT...). So the firewall sends
a DUPrU there where causes the association to be aborted
straight away.

> And in a single homed nature it is just like an ABORT... no

Yes.

[...]
> the right thing and NOT send back this ICMP message.

Yes, we agree, it should send a ABORT (or ICMP DUPrU) in
response to the INIT, and drop any other message. BTW, I think
firewalls send ICMP DUPoU instead of RST-ACK when refusing TCP
connections.

> added to it to support SCTP... if you do I won't

I think there's a rule for "reject anything but the protocols I
know and I'm willing to talk about".

[...]
[...]

If I read the RFC correctly, you mark the destination as
inactive but you keep sending heartbeats in case the other end
wakes up.

Cheers,
Stephane

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Sep 2006 10:06:58 -0400

> something. I'll try and investigate more.

If you can find out.. I will gladly file a DDTS on it... since
sending ICMP-Protocol-Unreachable is a bug plain and
simple...

We have two species of F/W if I remember right.. one
is a PIX and then we have another besides that..

I will ask around internally and see if someone knows...

I know that my BSD F/w does NOT do this :-D

> a DUPrU there where causes the association to be aborted

Yep.. and thats the end...

> firewalls send ICMP DUPoU instead of RST-ACK when refusing TCP

Hmm.. you have me curious.. I will go poking around in
code I try to avoid ;-0
> know and I'm willing to talk about".

hmm... then it should reject by dropping IMO..
> inactive but you keep sending heartbeats in case the other end

Of course... you have to... since you are not
sure.. but its a low rate sending

Besides, consider a F/W that does not answer.. we
continue to HB.. then someone says.. hey look
lan X is down.. analyzie it out.. figure out
its the F/W and then set a rule to allow
SCTP through the F/W... the next probe
re-enables the destination..

R

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 22 Sep 2006 15:11:01 +0100

On Fri, Sep 22, 2006 at 08:27:50AM -0400, Randall Stewart wrote:
[...]
> ... tear down.

The attacker can't reuse that CE in that case it should send
another INIT and wait for wnother INIT-ACK. I'm confused by
your second line. It should be the server (not the victim) that
sends a CA to the attacker.

> the ICMP messages the Victim host is sending...

I don't think that would work, the second CE pertains to the
first association, so would be discarded as per the SCTP RFC
section 5.2.4. You need the association to be closed first,
which the ICMP DUPrU take care of in the current case.

[...]
> tear down the association.

Yes, but with the considering of a ICMP DUPrU as an ABORT, the
server still sends a burst of HB to the victims before receiving
the ICMP DUPrU.

Cheers,
Stephane

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Sep 2006 11:06:36 -0400

> sends a CA to the attacker.
Right.. it should be A... But the CE can be used as
long as the cookie is valid for..

> which the ICMP DUPrU take care of in the current case.

No, you need to re-read the cookie handling .. this will
happen commonly when the C-Ack is lost.. the sender of
the Cookie.. never receives the C-Ack.. so he retransmits
the Cookie.

This is what it looks like to the Server..

> server still sends a burst of HB to the victims before receiving

But at least the ICMP kills the association. If you ignore
the ICMP the association continues to be alive and sending
HB's..

R

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 22 Sep 2006 17:22:59 +0200

Hi Brian,

yes, you are correct. That is my point.

Best regards
Michael

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 22 Sep 2006 16:54:10 +0100

On Fri, Sep 22, 2006 at 05:43:48PM +0200, Michael Tuexen wrote:
> Dear all,
> 
> step back for a moment... When an SCTP capable endpoint (the victim, for example)
> gets an SCTP packet (from an attacker, for example) which it is not expecting it
> will send in most cases back an SCTP packet containing an ABORT chunk which
> will kill the association. Right?
> 
> We do not want than an non-SCTP capable endpoint is treated worse than an
> SCTP capable one.
> 
> So we require that an ICMP DUPU (which is the analog of an ABORT, but using
> ICMP) which is sent by the non SCTP capable receiver of an SCTP packet is
> handled the same way as an ABORT.
[...]

Yes, stricktly speaking.

Except that from the point of view of a firewall, it's not the
analog of an ABORT. The firewall would use the ICMP unreach to
say "not through me", i.e. kill one path of the multipath
association, while an ABORT kills all the paths. For every other
(single-homed) protocol it ends up being the same as there's
only one path per connection.

Now, I agree it's more of a firewall issue than a SCTP issue.

And the better approach is probably to make the firewalls SCTP
aware (ie, only send the proto-unreach for INITs when they don't
want any SCTP through them).

Cheers,
Stephane

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 22 Sep 2006 19:08:24 +0200

Hi Stephane,

see my comments in-line.

Best regards
Michael

>> handled the same way as an ABORT.
OK.
> only one path per connection.
The point is that for single homed transport protocols "not through me"
is equivalent to ICMP, destination unreachable, Port unreachable or  
Protocol unreachable.
But this is not true for transport protocols providing support of  
multihoming.
Discarding a packet is the best in that case.
> Now, I agree it's more of a firewall issue than a SCTP issue.
Yes, I think this is true. We need to educate the admins of
firewalls and possibly the makers of them, too.

I talked to Randy and we will come up with an ID which might
help them.
> want any SCTP through them).
Why not an ABORT?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 22 Sep 2006 12:39:37 -0600

Stephane,

Stephane Chazelas wrote:                  (Fri, 22 Sep 2006 13:09:41)
> people connecting via sattelite in China to be able to talk to

Use low lifetime with ample preservative.

> having to send another INIT, there's still amplification.

Then attacker must send 2 COOKIE-ECHOs for each HEARTBEAT and
your back to 1:1.

> to a victim because the attacker replies to the heartbeats

The attacker doesn't need to reply to HEARTBEATS for the attack to 
continue.  She just goes away.  You keep sending.  Script kiddie heaven.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/