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

From: Randall Stewart <[email-masked]>
Date: Sat, 01 Oct 2005 06:31:54 -0400

Brian F. G. Bidulock wrote:
> Randall,
> 
> Segment number does not monotonically increase.

But that makes no difference in this case.. since as you
stated.. if I remember this thread right ...  the
"attacker" will be able to know enough about the
app its getting to send data so it can 'predict'
what the segments are going to be ... in TSN's.
This is the same for TCP then.. instead of perdicting
X bytes per TSN.. it changes the scaling.. thats all.

So you end up with the same attack.

I think that if you are really that concerned about this
type of attack (I am not) then you need to join SCTP
into the TCP document that illustrated the same attack
and work with those authors to see if you can get
adjustments made to both TCP and SCTP .. since they
both have the same problem..

I will see if I can't go dig around in my
other email account and find the draft name so then
you can get in touch with those authors...

R

> 
> --brian
> 
> On Wed, 28 Sep 2005, Randall Stewart wrote:
> 
> 
>>Brian F. G. Bidulock wrote:
>>
>>>Michael,
>>>
>>>On Wed, 28 Sep 2005, Michael Tuexen wrote:
>>>
>>>
>>>
>>>>>The purpose of the HB[nonce] is not to verify the IP addresss (it
>>>>>belongs to the peer) but to verify the that the peer actually received
>>>>>the data for which he is sending SACKs, and that he hasn't sent SACKs
>>>>>for data in advance of reception just to increase the server's cwnd and
>>>>>cause him to saturate his outgoing interfaces.
>>>>
>>>>OK. I understand now what your HB(nonce) is for.
>>>>But this is pretty different from the goal of the path verification
>>>>procedure.
>>>>I think it is enough to
>>>>- verify that an address really belongs to the peer (using the path 
>>>> verification)
>>>>- make sending SACKs acking data not yet received as hard as possible
>>>> by requiring the SHOULD for sending an ABORT on reception of a SACK
>>>> for unsent data.
>>>>
>>>>I do not think that there is a need of requiring an authentication for
>>>>SACKs.  If the receiver does not bundle the HB-ACK(nonce) with the
>>>>SACK you might run into problems when packets are reordered in the
>>>>network.
>>>
>>>
>>>No worse than SACKs getting lost by the network (which is the more
>>>common of the two events), and if reordered SACKs turn into lost SACKs
>>>that is not much of a concern.
>>>
>>>I agree with the SHOULD on cumulative acks beyond sent DATA, but don't
>>>think that it will make sending bogus SACKs that difficult at all.
>>>
>>>By controlling arwnd in the bogus SACKs, it is probably possible to
>>>predict exactly how many TSNs you will send: starting small and ramping
>>>arwnd up just a little slower than cwnd would grow.
>>>
>>>Then the TSNs sacked could be what the attacker just received, plus the
>>>number of TSNs in the ramp up, minus a few (or a bunch) so that you will
>>>never ABORT as a result of them being too high.  It does not matter, the
>>>minus a few (or a bunch) will only affect initial RTT calculations, cwnd
>>>can still grow unbounded.
>>>
>>>Sounds like a good demonstration for DoS attack points at the next SCTP
>>>interop.
>>>
>>
>>And tell me how TCP is different please?
>>
>>R
>>
>>
>>
>>>--brian
>>>
>>
>>
>>-- 
>>Randall Stewart
>>803-345-0369 <or> 815-342-5222(cell)
> 
> 

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 1 Oct 2005 05:29:00 -0600

Randall,

I suppose it is not all that much more difficult.

I think that most servers worried about this throttle to
a portion of the outoing bandwidth anyway.  But IMO it is
not something that the application should protect against
but is the obligation of the transport.

I would be interested in joining the draft if someone can
pass its name along.

--brian

-- 
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 ¦

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 1 Oct 2005 21:09:40 +0200

Randy,

see my comments in-line.

Best regards
Michael

On Sep 30, 2005, at 14:18 Uhr, Randall Stewart wrote:

> Brian/Michael:
>
> Ok, still not having written the text :-)
>
> Let me summarize what I think the outcome is for this thread on
> HB's and verfication.
>
> a) We will have a new variable HB.max.burst
> b) This will be set to a default of 1.
> c) It will be used during path verification after
>    association startup... to validate other addresses.
> d) We will also allow an alternative, where instead of
>    doing path verification by starting a timer, instead
Up to here everything is clear and agreed (I think)
>    we will allow a HB+Nonce bundled with data. Only one
>    packet may be outstanding in this case until after
>    the HB+nonce is responded to.. and thus the path
>    verified..
This is an 'optimization' Brian wants to do (which is OK).
>
> One note that Jana and I have discussed in this past week
> (and this IMO is NOT something that needs to be in the I-G),
> is that the sender of the INIT could verify two addresses
> of the peer.
>
> Consider
>
> INIT ---to:IP-A--->
> <---INIT-ACK(IP-A, IP-B)
> A-Verified
> ----COOKIE-ECHO-to:IP-B->
> <----COOKIE-ACK
> B-Verified
No. B is not verified. The COOKIE-ACK is too simple to spoof.
>
> At the end of the above, two paths are verified (IP-A and IP-B). Now
> if the above is not good enough (since the COOKIE-ACK could be
> forged by the server) one could do:
> ----COOKIE-ECHO,HB/nonce-to:IP-B->
> <----COOKIE-ACK
> <-----HB-ACK+nonce (possibly bundled).
Not possibly. IF the right side supports bundling it can send
COOKIE-ACK,HB-ACK and the path is verified.
If the right side does not support bundling the COOKIE-ACK is sent
back and the HB-ACK is dropped (due to the new text ...)
> B-Verified...
>
>
> Similarly the receiver of an INIT can speed up verfication as
> follows:
>
> INIT(IP-A, IP-B)---->
> <-----to:IP-A-INIT-ACK()
> ----COOKE-ECHO----->
>      A Verified
> <--to:IPB-COOKIE,ACK+HB/nonce
> ----HB-ACK/nonce---->
>      B Verified
Correct.
>
> This means one could quickly get two addresses verified... and
> then any remaining addresses could be verified by the
> HB-Verification procedure (or the HB/Nonce+DATA as they
> fail over)...
Correct.
>
> Hopefully sometime today I can get the words crafted for this
> and send it to the list for wordsmitthing ;-D
I think it is important
- to make clear what the goal of the path verification is.
- to require the basic principle shown above (before my first comment)
- allow optimizations, like Brian is bundling a DATA chunk with the
   HB(nonce), or your proposed bundling of the HB(nonce) with COOKIE-ECHO
   or COOKIE-ACK. They are all optimizations, and there might be more...
> One thing I am thinking is that there should be some wording
> on packet conservation in this... i.e. any control type input packet
> that is a request that drives a response must not generate
> more than one output packet...
>
> R
>
>> On Thu, 29 Sep 2005, Michael Tuexen wrote:
>>>> Yes, and that's a good reason for limiting sending DATA with the
>>>> verification HB to 1 packet (i.e. all the DATA you can bundle with 
>>>> the
>>>> verification HB).  But not a good reason not to send the DATA at 
>>>> all.
>>>
>>> One problem is if you send HB,DATA you expect a packet HB-ACK,SACK.
>>> This response consists of two chunks.
>>> If the receiver of the DATA does not support bundling, he would send
>>> back HB-ACK and drop the SACK. This could require a retransmission
>>> of the DATA...
>> I don't know why the reecived would drop the SACK, but even if it 
>> does,
>> the protocol handles SACKs that are dropped by the network.
>> If the peer is going to drop SACKs then it cannot really complain 
>> about
>> the resulting poor performance can it?
>>>> You (or the security guys) say that bundling DATA with the HB will
>>>> somehow expose it to an unverified address; however, it is to where 
>>>> the
>>>> sender of the INIT requested that it be exposed whether it is 
>>>> verified
>>>> or not.  Please provide an example of how this can be a problem on 
>>>> the
>>>> basis of "data exposure".
>>>
>>> I thought about this and think now, that there is no additional risk.
>>> If you get the HB(nonce),DATA packet and can reply, you can also send
>>> a HB-ACK(nonce). After that the path is verified and you can get 
>>> DATA.
>>>
>>> So I'm not against this bundling (anymore), but think that the
>>> path verification is necessary.
>> Good.  I was only looking to have the leeway to send 1 packet of DATA
>> bundled with the verification HB.   I was certainly not wanting to 
>> require
>> others to do it.
>> I think that Randall also agreed that this can be permitted.
>> --brian
>
>
> -- 
> Randall Stewart

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 1 Oct 2005 18:08:39 -0600

Michael,

> back and the HB-ACK is dropped (due to the new text ...)

It is only if the COOKIE-ACK and HB-ACK are sent to an unverified
address that they need to be dropped.  Right?  Both could be sent
to the sender of the INIT (an address already verified by the
COOKIE-ECHO) could they not?  It is packet multiplication towards
a victim that we are concerned about, right?  Not packet multiplication
towards a verified host?

But even if the HB-ACK is not sent because the receiver foolishly
does not bundle, it will eventually be retransmitted, the receiver
will just not reap the benefits of early verification.

>    or COOKIE-ACK. They are all optimizations, and there might be more...

Yes, I think that it makes sense to leave the door open to reasonable
optimizations that do not compromise the principle.

But I'm interested to know whether this mulitple packet response concept
only applies to unverified addresses.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 2 Oct 2005 14:23:53 +0200

Hallo Brian,

see my comments in-line.

Best regards
Michael

> a victim that we are concerned about, right?  Not packet multiplication
That is a very good point!
I think that it is bad so send N packets in response to 1 packet in 
general.
But you are right, for the attacks being discussed it is important
that an endpoint MUST NOT send multiple packets in response to one
on unverified paths and MUST do the dropping.

I'm not sure about the verified paths. Since the sending of the control
chunks is not limited, one side can send a packet and the other side
replies with 350 or so. This is bad for the network, I think.

So I would prefer to use the same rule on verified paths and unverified
paths. In my understanding the verification is mainly for sending DATA
chunks because you will send multiple of them on reception of SACKs
due to CC (I do not consider a DATA chunk a response to a SACK chunk).
The control chunks should follow the 'one packet in, at most one out'
rule.

I definitely do not want to encourage people to reply with 350 packets
to one packet (even if that path is verified).

But you raised a very good point. Randy, others, what do you think?

---

From: Randall Stewart <[email-masked]>
Date: Sun, 02 Oct 2005 08:31:45 -0400

> I would be interested in joining the draft if someone can

I will dig back through my email collection this next week
and see if I can't provide you a pointer to the
draft and the author

R

---

From: Randall Stewart <[email-masked]>
Date: Sun, 02 Oct 2005 08:42:41 -0400

Michael/Brian:

I was thinking that you applied this rule
to verified and un-verified chunks..

And to answer Michaels other question about
the last sentence.. (in his updated version
which i like)...

The point of the note about SACK is that
a SACK is not something that sollicites a response.
We do NOT want someone to interpret the rule so that
they say..

-----DATA--->
-----DATA--->
<----SACK-----
(a sack is soliciting a response
  for more data so only one data
  chunk may be sent)

---DATA---->

The above would be bad... and is NOT meant by
this rule... since a SACK, itself, IS a response
but it does NOT ask for DATA to be sent... it ALLOWs
data to be sent.. but this is differernt than
HB---->
<---HB-ACK

or

unknown chk---->
<----ERROR

The point of the last sentence is to prevent a niave implementation
from doing the wrong thing with SACKs and DATA.. not that they would..
But you want something to make sure no one does an over-strict
  interpretation

R

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 2 Oct 2005 14:56:00 +0200

Hi Randy,

see my comments in-line.

Best regards
Michael

> to verified and un-verified chunks..
OK. I think this is the way to go.
> But you want something to make sure no one does an over-strict
So this is what I stated in one of the last mails:
I do not consider DATA chunks as a response to SACK chunks.
Maybe we should write such a sentence and also give some examples
like
- a HB-ACK is a response to HB
- INIT-ACK is a response to INIT
- COOKIE-ECHO is a response to INIT-ACK
- COOKIE-ACK is a response to COOKIE-ECHO
- SACK is a response to DATA
- SHUTDOWN-COMPLETE is a response to SHUTDOWN-ACK
- SHUTDOWN-ACK is a response to SHUTDOWN
- ERROR is a response to unknown chunks, unknown parameters in INIT-ACK,
   chunks with invalid fields, ...
- ...
but DATA is NOT a response to SACK.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 2 Oct 2005 19:25:34 -0600

Randall,

Thanks.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 2 Oct 2005 19:44:13 -0600

Michael,

But in effect they are.  All these attacks are related.  For unverified
addresses we are allowing only 1 HB[nonce] packet with bundled DATA and
other chunks, limiting packet amplification to 1.  For verified addresses,
Max.Burst (yet to be explained) supposedly limits amplification to 4
(provided that there is no SACK spoofing, in which case the amplification
could be as large as your ERROR chunk example).

But limiting number of packets is not sufficient.  I can send 1 packet
with only enough unknown chunks necessary for you to bundle a full MTU
in response, and I can still cause you to saturate your outgoing
interface and deny service to all other users of the interface.  In all
the other examples, if you respond with a full MTU in response to my
sending a much smaller packet, the amplifiction necessary for a DoS
attack remains.

Perhaps it is necessary to bring other chunks under congestion control,
(i.e., apply cwnd rules to them, but not rwnd rules) and throttle them
on a size (bandwidth) basis rather than a packet count basis.

Otherwise the rule will probably need to state that the response packet
can be no larger than the packet that solicited the response, which is
of course not possible for the unknown error reporting chunks considered.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Oct 2005 10:41:07 +0200

Brian,

see my comments in-line.

Best regards
Michael

> could be as large as your ERROR chunk example).
That is right and I do not think (at least I did not want) to say
anything against it.
> sending a much smaller packet, the amplifiction necessary for a DoS
Currently I'm looking a the ratio of number of packets to define
the amplification factor, not the ratio of number of bytes.
I think we agree that using the rules discussed before we have no
amplification based on the ratio of number of packets.
Looking at the response pairs, it is only the ERROR chunk returned
to an unknown chunk which can be larger. It is, if it includes
the unknown chunk. Maybe we should make this a MAY. So you can
decide if you want to put the unknown chunk in (which helps 
understanding
what is going on) or to leave it out (which avoid longer responses).
> on a size (bandwidth) basis rather than a packet count basis.
I do not think we need this.
> of course not possible for the unknown error reporting chunks 
I think the rules we have right now are enough with the addition of the 
above
MAY and making the consequence clear.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Oct 2005 03:21:39 -0600

Michael,

Please see below...

> what is going on) or to leave it out (which avoid longer responses).

Not just ERROR.

   INIT-ACK can be much larger than INIT.

     Gosh, that's a simple attack, just send little INTIs with spoofed
     source address and let the big cookie laiden INIT-ACK go to the
     victim (or swamp the outgoing interface again).

     Perhaps we need to make the sender of the INIT pad the INIT out
     to match the size of the INIT-ACK.

   SACK can be much larger than DATA.

     Send many 1-byte DATA with many artifical TSN gaps, then send
     steady stream of same TSN 1-byte data spoofed from victim's
     unverified address.  Rule says to send SACKs to where the data
     came from, and must be sent on each data packet when there are
     gaps or duplications.  Boom!  Or use attacker's verified address
     and overload the server's outgoing interface.

     Looks like one can't send any response packet to an unverified
     address not bundled with a HB[nonce].  Also, it looks like the
     rule about sending a response back to where it came from needs
     to be modified.

     Do we refuse to SACK data that is smaller than the resulting SACK?
     Even to verified addresses?

   SHUTDOWN is also a response to DATA.  (And if no bundling, cannot
   report gaps or duplicates.)  (With SACK can be much larger than DATA.)

     Same as SACK above.

The only difference between bundling up a big response and sending
many responses is the SCTP header, IP header and L2 header overhead,
which is no so great.  Although it is true that recievers in the past
were frame rate limited, now they are bit rate limited.  Bit
amplification is worse than frame amplification.  Sending 3 packets
1/4 the size is not as bad as sending 1 full sized packet.

I don't think that it is enough to say that you have no amplification
because you are sending packets 1 for 1.  That might be true enough
for TCP where the control information is contained in a few bits in the
header.  SCTP control chunks on the other hand have to be considered
for size.

For verified addresses, since the user is permitted to send multiple
(DATA) packets in response to a single (DATA) packet, why cannot the
protocol send multiple packets to verified addresses in response?

--brian

---

From: Randall Stewart <[email-masked]>
Date: Mon, 03 Oct 2005 15:19:36 -0400

>      to match the size of the INIT-ACK.

How can an INIT-ACK swamp an outgoing interface? You get
one packet in.. and one packet out.. so what if the
out bound packet is bigger.. I would be more worried that
the Hashing algorithm is going to be more of a problem in
... and a 1:for:1 in/out is NOT an attack IMO...

>      and overload the server's outgoing interface.

But again.. you are in a one packet to one packet scenario...
I just can't see this has an amplification attack... sorry..

And you have similar issues (maybe not as big) with TCP-SACK...
if you are worried about byte counts (which I am not in this case)...

>      Even to verified addresses?

No, I think this is unneded... just like I don't think modifications
to the where responses go is un-needed....

I can see where a cautious implemntation may well NOT send any
response to a un-verified address.. but I don't see anything
you have laid out as an amplification attack...

>    report gaps or duplicates.)  (With SACK can be much larger than DATA.)

Again its a 1-for-1... and the only exception in the rule
we talked about is a DATA in response to a SACK.. so in
my mind SHUTDOWN in response to a DATA packet... WOULD
hit the same new rule we are discussing.. aka only one response
packet.. so you either bundle a SHUTDOWN+SACK or you send just
a SHUTDOWN...

> 1/4 the size is not as bad as sending 1 full sized packet.

I think I disagree with you here...  and more so if you
take this same microscope you are using you can find the
same issues with TCP...

A packet requires an interupt and often a context switch.. these
IMO are far more heavy than if I have 100 bytes or 1000 bytes.

> protocol send multiple packets to verified addresses in response?

I don't see its needed...

R

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Oct 2005 22:29:08 +0200

Brian,

see my comments in-line.

Best regards
Michael

>      to match the size of the INIT-ACK.
I do NOT think that we should discuss on the ration of bytes. I consider
the ration of packets to be the correct way.
BTW, I have no idea as a sender of the INIT how big the INIT-ACK I get 
back
is....
>      rule about sending a response back to where it came from needs
Why? You send the response to the source address of the request.
>      Even to verified addresses?
No. We only say that you only send out one SACK even if it is too small
to hold all gaps.
>    report gaps or duplicates.)  (With SACK can be much larger than 
I think the way to go is the look at the ratio of number of packets. And
the procedures we discussed earlier handle this pretty well.
> header.  SCTP control chunks on the other hand have to be considered
That is why we require in some extension IDs that only one 'request' is
in flight. And why we had
> protocol send multiple packets to verified addresses in response?
Because DATA chunks are subject to flow control and congestions control.
Control chunks aren't.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Oct 2005 23:30:35 -0600

Randall,

> ... and a 1:for:1 in/out is NOT an attack IMO...

Oh really?  Give me two host IP addresses (one host with SCTP, the other
doesn't matter) and permission (from the owner of the hosts) and I will
demonstrate.

Most INIT-ACKs are double the size on the wire as the INIT.  With a
bunch of continue/report unrecognized parameters added to the INIT, I
can squeak that up to triple the size on the wire (while nicely keeping
your hash computational load down lower).

I send INITs as fast as I can to the first IP address, and the INIT-ACKs
go to the second IP address (spoofed source address).

I send, say 1Mbps (on the wire) to you and you send 3Mbps (on the wire)
onwards to the other.

For my 1Mbps I use up 1Mbps incoming and 3Mbps outgoing on the first
host and use up 3Mbps incoming on the second host.  The second host will
discard the INIT-ACKs (at least the ones that it is capable of
receiving).  The first host will receive no indication that there is a
problem if the second host is SCTP capable.

So for my 1Mbps, I use up 4Mbps of the first host's interface and 3Mbps
of the second host's and 4Mbps of the shared network.

Sounds like amplification to me.

No attack?  All I need is a fraction of the bandwidth available to me as
you have and I can pretty much guarantee that you (and the other host
that upon inspection will think the attack is coming from the first
host) will not be performing any useful transport across their
interfaces.  Also, if the first host is not too efficient on hash
computation, I can probably even deny service to local processes.

And for an indenfinite period of time.

And that is only if the network is a football to us.  If the network is
a barbell, all I need is a fraction of the bandwidth of the bottleneck
in the barbell and I can pretty much grind the network to a halt.

Gosh you would have to use MPLS or something and put protocol 132 into a
low-bandwidth sandbox just to stop me.  Particularly if I take my
(hypothetical) 50 compromized servers and put them to the task.

What's worse, is if I take my 50 compromized servers and distribute my
spoofed INITs across 5000 servers, focussing the INIT-ACKs on one
victim, and the network is a football, the victim can say goodbye.  And
it will be very difficult to trace the origin of the attack.

I don't want to give that opportunity to a bunch of disgruntled types,
do you?  You think that byte multiplication is acceptable?  That only
packet count multiplication counts?

Michael?  You think that too?

Well, protect your servers.  Now that I mentioned it publicly even a
script kiddie could do it in minutes.

If TCP SACK is the same way, think twice about deploying it.

Plainjane TCP does not have to worry because the byte multiplication is
just not there.  PJ TCP can talk in terms of packet multiplication.

SCTP is a completely different beast.  I think that we had better
consider byte amplification.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Tue, 04 Oct 2005 08:38:11 -0400

> consider byte amplification.

So far.. only you have spoken up on this.. Michael as said
we should look in terms of packets.. I agree.

Lets see if anyone else in the wg think this is an
issue...

Anyone else, besides Brian, on the list think
we should worry about the number of bytes in
vs the number of bytes out?

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 04 Oct 2005 09:30:22 -0400

Brian:

Thinking about this some more... maybe we do
need at least a couple of changes on the verification
procedures:

1) Not allow ANYTHING but a HB+nonce to be sent to
    an unverified address. This would also include control.

2) NOT allow data to be bundled with a HB+nonce, as you wanted,
    since this would be a form of "byte amplification".

3) NOT EVEN the HB-ACK should be sent back to a non-verified address.
    That way you get it back, if you are a malicious attacker.. and
    this should be no problem since I think most implemenatations (if
    they have done any testing at all) will have been putting the
    destination they sent the HB to inside the HB...

This handles ALL but the INIT/INIT-ACK case... and I do not think
that you can address that easily... Michael's earlier change to say
MAY report unrecognized parameters (if I remember his statements right)
would help in this regard (by the way, in looking at 2960 I see
no MUST that I have to send an uncrecognized parameter anyway). But
you cannot get rid of the need to have a larger INIT-ACK just because
you have the COOKIE inside it... this comes down to a classic
security trade off.... do you protect against TCB exhaustion (aka
the SYN attack) or do you protect against a 'byte amplification' type
attack... In this case I think the SYN attack is far better to
protect against...

I still am not as concerned about "byte amplification" as you are, but
making the above changes will minimize this to hopefully make you
happy

R

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 4 Oct 2005 16:43:18 +0200

Randy,

see my comments in-line.

Best regards
Michael

>    since this would be a form of "byte amplification".
These points mean: You MUST verify the path first using HB(nonce)
and you MUST NOT send anything else. There is no distinction
necessary between DATA and control chunks.
>    destination they sent the HB to inside the HB...
No. You will send a HB(nonce) to an unverified address and the
HB-ACK might have to go back to an unverified address. And that
is not problem, because size(HB-ACK) == size(HB). So we do not
need a restriction here.
> making the above changes will minimize this to hopefully make you
I think the above procedure is pretty simple and I support it. However,
we should still not encourage implementations to reply to one packet
with more than 350 packets... So we should still have the text with
the bundling...

---

From: Randall Stewart <[email-masked]>
Date: Tue, 04 Oct 2005 12:28:18 -0400

Michael:

See below...

> is not problem, because size(HB-ACK) == size(HB). So we do not

Why?

If you have a verified address, you should be able to send
the HB-ACK back to that address without causing a problem.. It
is being over-precautious... mind you.. but one could do this..
I don't mind if we don't :-D

> with more than 350 packets... So we should still have the text with

Yep... I agree... the other thing is we COULD possibly craft
some warnings about responding to a large INIT... (one that
might be for amplification).

If one thinks about it... you almost cannot get away
from having the cookie be at least:

a) The peers addresses,          (say 2 IPv4's.. thats at
                                   least 8 bytes)
b) The tags and sequence numbers (16 bytes)
c) A timestamp.. (say 4 bytes)
d) A signature (16 or 20 bytes)

So no matter how big the INIT is .. the INIT-ACK will
probably always add at a minimum of 40 extra bytes....

But there are other methods for dealing with this type
of attack...

aka: RPF checks, ingress screening, and rate limiting
of INIT's.. come to mind.. I am sure there are others..

So I don't think it is that big of issue... maybe not
even worth addressing in the I-G

R

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 4 Oct 2005 21:39:38 +0200

Randy,

see my comments in-line.

Best regards
Michael

> I don't mind if we don't :-D
I do not see a problem, because the HB-ACK is one packet exactly like
the HB and it has the same length. So I do not see how this process
can be misused. That is why I would like to have as much freedom as
possible.
> might be for amplification).
Hmmm. The point is that is does not have to be a large INIT.
If the server has N addresses the INIT-ACK will be of the size
of the INIT + constant + constant * N.
So a server with a lot of addresses will produce large INIT-ACKs
even for small INITs. So one could use some heuristics to
try to decide if a particular INIT is used for an attack. One
could even use some sort of shaping...

However, I think as you point out below, the INIT-ACK is
larger than the INIT. The only way around that might be
an additional padding parameter which make the INIT larger
and is not put into the INIT-ACK. That could be used to
get the size of the INIT larger as the size of the INIT-ACK.
The receiver could, if the padding is too small, send an
ERROR/ABORT indicating that the padding is too small. Like
the COOKIE lifetime stuff.

But currently I do not think that it is worth the effort.

In summary:

Using the path verification stuff with unbundled HB(nonce)
there is no packet or byte amplification to victims which
are not the SCTP endpoint except the INIT/INIT-ACK pair.
There is no packet amplification, but the possibility
of an byte amplification. A way around that would be an
optional padding parameter, which makes the INIT larger.
But I do not think that it is worth it at the moment.
For verified paths we should enforce the 'one packet in,
at most one packet out' rule for control chunks as pointed
out (and agreed earlier).

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Oct 2005 02:47:57 -0600

Michael,

> with more than 350 packets... So we should still have the text with

The way things stand, it makes little difference whether you send 350
ERROR chunks to me in 350 packets or in 1 packet.  The most compute
intensive task for bogus packets (for a non-HW assist SCTP aware host)
is checksumming the payload of the packets, which is roughly the same
in either case.

The way that RFC 3309 is worded ("When an SCTP packet is received,
the receiver MUST first check the CRC-32c checksum"), I am prohibited
from checking for a bogus SCTP header until the checksum is calculated
in full.  So I must checksum every byte of every ERROR chunk regardless
of whether there are 350 in one packet, or 350 in 350 packets.

Note also that the attacker does not have this compute load.  The
attacker can use canned messages (precalculated checksum INIT messages
that are simply sent over and over again).

If RFC 3309 was worded differently the situation would be different
on the compute side.  If I was allowed to check the IP and SCTP headers
to see if the packet is bogus (regardless of the validity of the checksum)
and then only checksum when the header shows the packet to be possibly
genuine, then all bogus INIT-ACK packets could be discarded in constant
time regardless of size and 1 big packet would be better than 350 small
packets from the compute side.  (I do this already, but imps that follow
RFC 3309 to the letter will not.)

In terms of bandwidth consumption they are roughly the same, however.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Oct 2005 02:52:51 -0600

Randall,

> of INIT's.. come to mind.. I am sure there are others..

Rate limiting INITs will invite DoS attacks on the rate
limit.  All the attacker need do is exceed the rate and
all other INITs are denied.  This was learnt a long time
ago with SYNs.  I though we even had a recommendation
against rate limiting of INITs.

Also, because they are INITs you cannot rate limit on any
basis that the attacker cannot spoof.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Fri, 07 Oct 2005 08:38:35 -0400

Lets try to change the topic.. since this
is NOT an ICMP issue...

> is checksumming the payload of the packets, which is roughly the same

And what do you mean by a "bogus" packet?

- One that does not belong to an association?
<or>
- One that belongs to an association but contains a bunch
   of errors?

The question really becomes "how much of the packet are you
willing to look at and trust without knowning if the
data is corrupted or not"

This is the issue.

On an attacker sense, an "evil attacker" can setup a
valid association with you and then flood you with
packets that have perfectly acceptable headers.. and
yet are filled with error reports... and a bogus
checksum... even if you check the header before
you check the rest.. you would still end up doing
the crc32c..

A change in 3309 (which is inside the I-G) would not help
this. It COULD help the case where you have an
invalid header.. and thus save checksuming the
packet... but this is a minor annoyance as
far as processing goes... you don't get that
many errored packets....

But it won't help in an attacker case... the bigger
issue was that we elected to go with CRC32C IMO..
I was against this, I am not proposing to change it,
but it would have been better to do CRC32.. since then
the ability to have hardware assist would have been
MUCH MUCH better... sigh..

As far as going down the path of allowing you to
root around in the SCTP packet BEFORE you do
a checksum... I just don't see the value in
this... since you have to look at much more than
just 4 bytes (the ports)... and as I said, an
attacker can setup a nice association with
you and then flood you with errors that
have perfectly valid headers and a bogus
checksum...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Oct 2005 11:44:40 -0600

Randall,

Its not a big deal.  I don't trust anything, I just change the
order in which things are done.  All I do now is check that the
SCTP header has a correct length, that there exists a valid
first chunk header, and use the SCTP header to see if an
association exists.  If one does not exist and the policy is not
to send ABORT to OOTB packets (permitted by the I-G for port
scanning), I discard without checksumming.  Otherwise, I
checksum before delivering it to the association.

Thus if I am flooded with OOTB packets from any of the bombing
attacks, I discard them without checksumming.  For those
attacks, byte amplification would have less meaning for
processing power, but still meaning for bandwidth.

Point being, MUST should be changed to SHOULD on the order of
doing things.  It does not endanger the network or destroy
interoperability by changing the order of doing some things
and the MUST in regard to order is unwarranted.

Yes, in the attacks that do not include OOTB packets, this does
not help much.  So byte amplification is still important
(because you have to checksum each and every byte), and packet
amplification less important.

--brian

---

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 7 Oct 2005 12:14:19 -0700 (PDT)

> and the MUST in regard to order is unwarranted.

I agree with Randall's point that saving checksum calculation
on rare packets is not much of an optimization. But I don't
see how it is relevant.

If an SCTP implementation MUST NOT do X, and it does nothing
that any external entity can detect that implies it did X,
then why does it need the language downgraded to a SHOULD?

--
Caitlin Bestler
http://asomi.com/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Oct 2005 15:19:34 -0600

Caitlin,

> then why does it need the language downgraded to a SHOULD?

In fitting with the use of requirements keywords, it seems
pointless to say MUST with regard to something that is not
externally detectable.  That is clearly requiring an
implementation to do a thing a certain way that is not
ncessary for interoperability or protection of the netwrok,
a misuse of the keyword: somthing that the requirements
language RFC discusses.

When we say MUST, do we wnat to invite implementations to
do differently, just as long as they can't get caught?  I
think we should use MUST only when we expect an implementation
to do no different, whether detectable or not.

That's why I say that the language should be changed to say
that the checksum MUST be checked before responding to the
packet and leave the order of checking other items concerning
validity of the packet to the implementation.

--brian