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

From: "Schruefer, Wolfgang" <[email-masked]>
Date: Tue, 20 Sep 2005 12:38:21 +0200

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Sep 2005 13:57:54 +0200

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Sep 2005 06:51:13 -0600

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

-- 
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: Tue, 20 Sep 2005 15:44:15 +0200

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Sep 2005 12:53:23 -0400

Schruefer, Wolfgang wrote:
> 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.

Yes its possible.. please see the sctp-threats draft...

> 
> 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, ...).

Hmm.. are you saying then that the V-tag is an easy thing
for a blind attacker to guess? This means you have a very
lucky guessor (making a 1 in 4billion guess) in a few
packets... statistics say that it will take closer to
2billion packets of guesses to get an acceptable ICMP
message.

During the tcp-secure incident, after putting in the
changes to IOS and BSD that it says... I had an attack
program that would break a TCP connection in somewhere
like 1minute to 20 minutes (due to the window size
being in the seq space).. Note: of course this was
with known ports... so it just isolated the guessing
of a 32 bit number vs a 32 bit number divided by the
window space... Once the fix was in.. I let the
guessing program run over 12 hours... and it never
broke the connection... And that was on a 100megbit
enet..

Somehow I doubt that the V-tag is that weak..

> because that is exactly why it is made for ... but it causes no
> severe consequences if it is not implemented.

And here we dis-agree...

This item needs to be a MUST IMO and I bet the security
AD's will feel the same way.. so why not make it so now..

R

> Best Regards Wolfgang

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Sep 2005 11:09:50 -0600

Michael,

2 in the draft can be handled by policy at the server and client and does
not require sending many HEARTBEATS at one, creating amplificaion.  If the
"victim" chooses a new port number with each association attempt (the norm
for client-server applications), it can limit the attack.  Also, the server
can refuse associations that contain IP addresses that do not resolve back
to the same hostname.  The server can also refuse associations from known
"attackers" (that have failed verification of an address in the past).

There are, indeed, a zillion things that can be done about 2, without introducing
dangerous amplification as the supposed cure.

Because the so called "fix" to 2 introduces amplification, the fix MUST NOT
be used: (it is dangerous to the network).  If this "fix" made it to the IG,
it must be struck before rfc3332bis advances.

It is this "solution" to 2 that opens the door to 5 and 6.  A proper solution
to 2 would go farther to protect non-SCTP aware hosts than ICMP handling that
might be beyond an SCTP host's control.

--brian

On Tue, 20 Sep 2005, Michael Tuexen wrote:

> >>> specific ones) not to handle ICMP:

---

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

Brian,

see my comments in-line.

Best regards
Michael

> for client-server applications), it can limit the attack.  Also, the 
This is already stated in 2.2 1). Random port numbers do help, but I do 
know
that in SIGTRAN networks (main application of SCTP) normally both sides
are statically configured and therefore NOT random.
> to the same hostname.  The server can also refuse associations from 
This requires DNS to be in operation...
> it must be struck before rfc3332bis advances.
I do not agree here (to the MUST NOT) and do not understand the 
relation bewtween
the IG and the M3UA.

---

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

> dangerous amplification as the supposed cure.
Hmm lets see..

Max.Burst = 4 (at least that is the default).
A heartbeat (unless you are doing PMTU with it) is
usually about 100 bytes or so...

A default RTO on a non answering address starts at
3 seconds..

Soo.. its 400 additional bytes (in 4 packets) every
3 seconds...

First round, then 3 seconds later 4 more packets of
around 100 bytes each... etc..

And of course that is assuming that we have way way more
than 4 addresses... Once we start repeating addresses you
then get a doubling effect of the RTO... 6 second, 12 second.. up
to 60 second RTO.max...

Hmm.. does not seem IMO to be a huge amplification of
anything.. the initial cwnd of 4380 bytes will put
more data in the network then the heart beats

Of course I guess it depends on how one defines
amplification... if 4 packets every 3 seconds defines
it then we do need to look at that..

Others? what do you think? Does this qualify as a
amplification that should be taken out of the I-G?

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Sep 2005 11:30:29 -0600

Michael,

> are statically configured and therefore NOT random.

Those applications are long lived associations that are not vulnerable.
The attacker will be the one being told that they cannot add an address
to an association.

> This requires DNS to be in operation...

Which is rather necessary in the big I, which is what needs to be protected.

> I do not agree here (to the MUST NOT) and do not understand the 

Ooops, I meant rfc2960bis...

The MUST NOT is proper use of keywords (it must not be done because it
introduces amplification which is harmful to the network by providing all
manner of security threats.)

You would threaten all hosts in the Internet in the guise of fixing some
minor SCTP-only host threat that can be thwarted by policy?  I think not.

This will surely be brought up at last call.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Sep 2005 11:34:51 -0600

Randall,

> amplification that should be taken out of the I-G?

You should know that if more than one packet is sent for each
packet sent by the attacker it is amplification.

If all the attacker must do is send several packets to get a
host to send 4 packets every 3 seconds (even decaying), it is
a lot of amplification.

--brian

---

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

> minor SCTP-only host threat that can be thwarted by policy?  I think not.
If 4 packets every 3 seconds is a threat to the Big-I I think we
have a lot more problems then that to deal with. Oh and that would
be 4 packets a second to unique hosts.. any time a host repeats in
the "amplification" then its time doubles...

Sorry, I just don't see this as an amplification ...

> This will surely be brought up at last call.

The last call that ended on the 15th? I believe we
are still openly accepting comments... since we seem to
be having a "late" technical discussion...

Remember what Allision said early on:

"
In either case, to underline something in Michael's summary, 2960bis
is to be derived from this document by editing alone.  So do consider
this in your reviewing.
"

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Sep 2005 11:37:51 -0600

Randall,

> is to be derived from this document by editing alone.  So do consider

You cannot advance a replacement PS by last calling an INFORMATIONAL document.

Any attempt to do so without addressing issues with the PS will be contested.

--brian

---

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

> host to send 4 packets every 3 seconds (even decaying), it is

Hmm.. so lets see

I do:

----INIT------>
<---INIT-ACK---
----COOKIE-ECHO--->
<---COOKIE-ACK----

So I can get back

4 HB every 3 seconds... which are roughly all totaled
400 bytes... The INIT and COOKIE would be a minumum of
4 addresses + an implicit one + all required stuff..
A quick add.. shows me

32 bytes per address so thats 124
an INIT is a minimum of 20 bytes... so we
have 144... add to that the cookie will have
double that .. roughly around 240 (assuming
the server has minimal options and such
in its INIT-ACK and params) ... so we are
roughly sending 2 packets holding 400 bytes
to get a server to send 4 packet containing
100 bytes..

I just don't see that as an amplification. We could,
if others really feel it is needed, change it from
using Max.Burst (which is 4) and instead make a
new parameter

HB.Max.Burst.. and have it default to 2.

This would end up with a slower "proving" of addresses
and then keep a 1-1 packet ratio since it takes 2
packets from the attacker to get the association up..

Others? What do y'all think..

a) New parameter HB.Max.Burst set to 2
or
b) its ok the way it is?

R

---

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

> Any attempt to do so without addressing issues with the PS will be contested.

Please point to me where in 2119 that this is not allowed?

Before we proceeded we did have a conversation with Scott on this
and he did not feel it was an invalid proceedure... as long as
the WG was informed that we were taking this route.

I think Allision's declaration makes it pretty clear.

Now, I have no problems with a late discussion of the I-G.. this
is a GOOD thing.. and it needs to occur... which I think it
finally has been with the ICMP issue etc..

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Sep 2005 11:57:53 -0600

Randall,

There is a better solution to attack 2.  When the server receives the
INIT from C, it can send an INIT-ACK.  Then on COOKIE ECHO, C is a
verified address (and C is not verified in the attacker's association
and the attacker's association can be aborted).

That is what I already do.  We had that discussion some time ago.

--brian

---

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

Dear all,

see my comments in-line.

Best regards
Michael

>> host to send 4 packets every 3 seconds (even decaying), it is
This might even become
---- COOKIE-ECHO ---->
<----COOKIE-ACK------>

if the left side uses cookielifetimeexpand and the
right side follows it. So the attacker sends one or
two packets.
> to get a server to send 4 packet containing
As far as I understand it is the number of
packets people are mainly interested in.
If the attacker has to send n packets to
get m packets sent to the victim, the amplification factor
is m/n.
> using Max.Burst (which is 4) and instead make a
Having a different parameter might be good. But keep in
mind that you want large values to protect against some attacks
and small values to protect against others.
So you need a value in between... 4 is pretty good, I think.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Sep 2005 11:53:38 -0600

Randall,

A WG needs to address issues before an RFC is advanced, else it can
be apealled on the grounds that issues were not adequeately addressed.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Sep 2005 14:05:18 -0400

> and the attacker's association can be aborted).
Let me get this straight..

Attacker                             Server

-From:A--------INIT(list A,B,C,D)----to:Z
(B,C and D are victims)

A<--------------INIT-ACK(Z)------

A------------COOKIE-ECHO----->to:Z

Now For Server: A is a verified address (this
is also what the BSD implementation does... and
it is NOT allowed to send data to B C or D until
a HB is responded to from that address)... I also
believe thats whats in the I-G..

With of course the sending multiple HB's (max.burst)
to verify the B/C/D.. with backoff etc...

Now.. to this point I followed your email.. since it
makes sense.. and its what I did and what the I-G specify's..
But the rest:
"(and C is not verified in the attacker's association
   and the attacker's association can be aborted).
"
I don't understand what you are saying...

Having A verified (using my example) makes it so
Z can talk to A.. but in order for Z to use
the alternate addresses they must be verified...

What did you propose would filter this out?

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Sep 2005 14:06:47 -0400

> be apealled on the grounds that issues were not adequeately addressed.

And I believe that is what the last call of the I-G is about..
lets look at all issues it addresses since these are the
"scoped" changes that will be applied to 2960...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Sep 2005 12:11:32 -0600

Randall,

> What did you propose would filter this out?

Good so far.  Now, intended victim C sends an INIT to the server.
Instead of refusing it, send INIT-ACK.  When C sends COOKIE-ECHO,
C becomes verified.  C is not verified in the attacker's association
and therefore, it can be aborted.

If the case was that the first association was legit, (i.e., A,
B, C and D belong to the same host), then the association needed
to be restarted anyway and sending an ABORT and forming a new
association is proper.

The trick is in not exposing the verification tag for the first
association in the cookie sent to C.

I have to go away for a few hours, but I can provide a detailed
example when I get back.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Sep 2005 12:13:50 -0600

Randall,

> "scoped" changes that will be applied to 2960...

The IG is not the PS.  We had this discussion.  It don't believe that the
WG agreed with that process.  (The only comments were comments against
the "intermediate" step.)

Unless the IETF is now "by decree" instead of "by concensus".

--brian

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Sep 2005 14:17:55 -0400

Michael:

My comments in-line...

> right side follows it. So the attacker sends one or

ok.. your of course assuming that in the
above case, he does it once with the
INIT/INIT-ACK/COOKIE/C-A

and then when it gets knocked down in some
amount of time later... assuming we have ICMP
or ABORTS coming in..  it

retransmits the COOKIE-ECHO until it becomes
stale.... Hmm I wonder if a sequence number
could not be put in a handed out cookie...

It would take some work.. and some thought.. but
it might prevent the re-use of a cookie in this
manner... this is something to ponder...
> get m packets sent to the victim, the amplification factor

Yes... a couple of thoughts..

1) I always wondered if we should not have an additional
    burst limit.. seperate from max.burst... maybe we
    should..

2) Now its true that the "number" of packets does translate
    on a host to a number of interupts... but I know for
    routers it is no longer a matter of packets over bytes..
    Most routers seem to not really care... from an endhost
    perspective though.. the number of interupts may well
    be the over-whelming factor .. but one every 3 seconds
    would take a large parrallel effort to have any effect
    I think...

I see your point that 2 may be to small.. but if we
can get your m/n equation closer to 1 it might
be better... I think at a minimum setting it
into a seperate parameter is probably a wise thing.. that
way an administrator can weigh the trade-offs of where a
smaller or larger one is more effective and tweak it seperately
from max.burst..

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Sep 2005 14:26:14 -0400

> to be restarted anyway and sending an ABORT and forming a new

But of course the above always depends on B/C/or/D to
do something.. if they do not.. you have:

a) extra cruft in Z.. i.e. the addresses held
    waiting to validate that they belong.

b) You still are going to have HB's going out to
    B/C and D... they will be farther apart... if
    you don't do as the I-G states.. but you are
    still required to send HB's..

c) I would think if you are running a HB timer per
    address.. you will send three HB's within 30 seconds
    plus or minus some minor variation... Note the BSD implementation
    only runs one HB timer.. so it would take 90 seconds to generate
    the 3 HB's.. either way is legal.. so in any event you have
    a slower amplification going on.. instead of 3 every 3 seconds,
    you have 3 every 30... If you are worried about a m/n amplification
    get enough parrallel hosts and the same problem exists....

> association in the cookie sent to C.

And the I-G already makes sure that does not happen...

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Sep 2005 14:27:43 -0400

Brian:

You were the only one that I remember objecting
to the process.. Joe had some comments but a lot
of his.. if I remember right.. had to do with
the naming of the document being confusing...
Joe.. jump in here and correct me if I am wrong..

R

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Sep 2005 20:52:41 +0200

Brian,

see my comments in-line.

Best regards
Michael

> and therefore, it can be aborted.

Hmm. Looks like Randy and you are talking about different attacks.
Brian is talking about an attack like in section 2 of the threat ID.
If he accepts the assoc from C, the stealing does not work.

I think (Randy, correct me if I'm wrong) is looking at it as an
attack like in section 6. This means the attacker sends 2 packets
and the server sends HBs to the victims as long as an ABORT/ICMP
is received.

Brian, which kind of attack are you talking about (2 or 6)?

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Sep 2005 20:56:21 +0200

Randy,

see my comments in-line.

Best regards
Michael

> above case, he does it once with the
Correct.
> amount of time later... assuming we have ICMP
Correct.
> manner... this is something to ponder...
Have to think about it.
>    burst limit.. seperate from max.burst... maybe we
Yes, we should.
>    would take a large parrallel effort to have any effect
I think people were thinking about using some of the attacks
in a distributed way.
I also think that if you get packets you do not want, you figure
that out in a time independent from the length of the packet.
That is why I was focussing on packets per second instead of
bytes per second.

---

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

Michael:

My comment below.. inline..

> and the server sends HBs to the victims as long as an ABORT/ICMP

I started talking about section 5/6.. and I think you
are correct.. Brian is talking about section 2..
Since the solutions all inter-relate.. it is easy
to get them mixed up ;-)

Now in any event... I am convinced that
we probably need a

HB.Max.Burst

the setting by default to 4... or maybe 2...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Sep 2005 01:50:53 -0600

Randall, Michael,

Allow me to start again.  First some history: (that we all know
but it warrants recapping):

There was a problem that, if one considered all addresses in an
INIT when searching for a TCB, that an attacker could high-jack
an association by attempting to form a new association with the
attacker's address included.  The scenario is something like
this:

     Evil Host               Server                Client
     ---------               ------                ------
     IP: A                   IP: X, Y              IP: C, D

                                         Existing
                             ===========Association=========

     INIT[A->X] [A,C,D] ---------->

     <----------INIT-ACK [tie tags]

     COOKIE-ECHO------------------>
                              Action (A)
                              Restart

     <-------------------COOKIE-ACK

               High-jacked
     ==========Association=========

It is bad enough that the Server revealed the verification tag
of the existing association in the state cookie to A, but the
association is completely high-jacked.

Of course the problem here is that the Server sends information
about an association, in which A is not involved, to A.
Particularly foolish.

In this case A has no business knowing anything about an
association in which it is not currently involved.

IG 2.6 proposes returning an ABORT to sender of the INIT.  So
the scenario would play out like this:

     Evil Host               Server                Client
     ---------               ------                ------
     IP: A                   IP: X, Y              IP: C, D

                                         Existing
                             ===========Association=========

     INIT[A->X] [A,C,D] ---------->

     <----------ABORT[new addresses]

There are several problems with this approach.

First, it facilitates port scanning.  In the diagram above, the
Evil Host, as scanner, is informed that an association exists on
Port N with addresses C or D, particularly if the error cause is
reported as suggested by IG 2.6.  This situation is completely
unacceptable for secure applications.  It continues to inform
Evil Host A information about an association in which it is not
involved.

Second, this opens the door to the attack in Section 2 of
sctpthreats.  That attack looks like this:

     Evil Host               Server                Client
     ---------               ------                ------
     IP: A                   IP: X, Y              IP: C, D

     INIT[A->X] [A,D]------------->

     <---------------------INIT-ACK

     COOKIE-ECHO------------------>

     <-------------------COOKIE-ACK

                             <------------INIT[C->X] [D]

                             ABORT[new addresses]-------->

As IG 2.6 stands, the client cannot even follow with:

                             <------------INIT[D->X] [C]

                             ABORT[new addresses]-------->

The "solution" to this attack it to require the Server to verify
addresses quickly with HEARTBEATs, so that the scenario will
play out something like this:

     Evil Host               Server                Client
     ---------               ------                ------
     IP: A                   IP: X, Y              IP: C, D

     INIT[A->X] [A,D]------------->

     <---------------------INIT-ACK

     COOKIE-ECHO------------------>

     <-------------------COOKIE-ACK

                             HEARTBEAT[D]---------------->

                             <-----------------------ABORT

                             <------------INIT[C->X] [C,D]

                             INIT-ACK-------------------->

                                           etc.

However, when more than two addresses are used, this provides
the amplification necessary to create the bombing attack in
Section 6 of sctpthreats.  This attack looks like this:

     Evil Host               Server                Victim(s)
     ---------               ------                ------
     IP: A                   IP: X, Y              IP: C, D, E, F, G

     INIT[A->X] [A,C,D,E,F,G]------->

     <---------------------INIT-ACK

     COOKIE-ECHO------------------>

     <-------------------COOKIE-ACK

                             HEARTBEAT[C]---------------->
                             HEARTBEAT[D]---------------->
                             HEARTBEAT[E]---------------->
                             HEARTBEAT[F]---------------->
                             HEARTBEAT[G]---------------->

                             <------------------ABORT/ICMP
                             <------------------ABORT/ICMP
                             <------------------ABORT/ICMP
                             <------------------ABORT/ICMP
                             <------------------ABORT/ICMP

     COOKIE-ECHO------------------>

     <-------------------COOKIE-ACK

                             HEARTBEAT[C]---------------->
                             HEARTBEAT[D]---------------->
                             HEARTBEAT[E]---------------->
                             HEARTBEAT[F]---------------->
                             HEARTBEAT[G]---------------->

                             <------------------ABORT/ICMP
                             <------------------ABORT/ICMP
                             <------------------ABORT/ICMP
                             <------------------ABORT/ICMP
                             <------------------ABORT/ICMP

Which (along with the Section 5 attack) led to proposals to
place ICMP requirements on SCTP hosts to protect non-SCTP aware
hosts.  But, in this case it having the Server properly handle
ICMP messages does not mitigate the attack.  The attacker can
still generate N HEARTBEATS using a single message.  Focusing K
servers on N IP addresses can easily bomb a multi-homed victim.

For non-SCTP aware victims, the HEARTBEAT will even be
retransmitted if ICMP messages do not get through.

It is upping the rate of confirmation HEARTBEAT messages as a
partial solution to Section 2 that aggravates this problem.
Amplification can be removed easily as follows: only verify one
address at a time, and require the attacker to respond to a
HEARBEAT before retransmitting.  The scenario would then play
out something like the following:

     Evil Host               Server                Victim(s)
     ---------               ------                ------
     IP: A                   IP: X, Y              IP: C, D, E, F, G

     INIT[A->X] [A,C,D,E,F,G]------->

     <---------------------INIT-ACK

     COOKIE-ECHO------------------>

     <-------------------COOKIE-ACK

                             HEARTBEAT[C]---------------->
                             [timeout]

     <-----------------HEARTBEAT[A]

     HEARTBEAT-ACK---------------->

                             HEARTBEAT[C]---------------->
                             [timeout]

                             etc.

If ICMP messages do not get through and the victim is non-SCTP
aware.  For the SCTP aware victim, it would look something like
this:

     Evil Host               Server                Victim(s)
     ---------               ------                ------
     IP: A                   IP: X, Y              IP: C, D, E, F, G

     INIT[A->X] [A,C,D,E,F,G]------->

     <---------------------INIT-ACK

     COOKIE-ECHO------------------>

     <-------------------COOKIE-ACK

                             HEARTBEAT[C]---------------->

                             <-----------------------ABORT

In both cases the attack is thwarted.

This also works for the Section 6 bombing attack.

Of course this obvious solution to 5 and 6 makes the counter
measure to 2 ineffective.  Consider the following:

     Evil Host               Server                Client
     ---------               ------                ------
     IP: A, B                IP: X, Y              IP: C, D

     INIT[A->X] [A,B,D]----------->

     <---------------------INIT-ACK

     COOKIE-ECHO------------------>

     <-------------------COOKIE-ACK

     <-----------------HEARTBEAT[B]
     B intentionally      [timeout]
     does not respond

     <-----------------HEARTBEAT[A]

     HEARTBEAT-ACK---------------->

     <-----------------HEARTBEAT[B]
     B intentionally      [timeout]
     does not respond

                             <------------INIT[C->X] [C,D]

                             ABORT[new addresses]-------->

                             <------------INIT[D->X] [C,D]

                             ABORT[new addresses]-------->

Effectively extending the time (indefinitely) that the Evil Host
can camp on address D.

Now, my point was that there is a better solution to the
high-jacking attack intended on being addressed by IG 2.6 (the
change that opened the door for the Section 2 attack in the
first place).

One possibility is a slight modification of the IG 2.6, only
abort on new addresses when the INIT is sent from an address
not belonging to the existing TCB.  Also clients should walk
through their source addresses and reattempt when they receive
such an error.  Then it plays out like this:

     Evil Host               Server                Client
     ---------               ------                ------
     IP: A, B                IP: X, Y              IP: C, D, E

     INIT[A->X] [A,B,E]----------->

     <---------------------INIT-ACK

     COOKIE-ECHO------------------>

     <-------------------COOKIE-ACK

     <-----------------HEARTBEAT[B]
     B intentionally      [timeout]
     does not respond

     <-----------------HEARTBEAT[A]

     HEARTBEAT-ACK---------------->

     <-----------------HEARTBEAT[B]
     B intentionally      [timeout]
     does not respond

                             <----------INIT[C->X] [C,D,E]

                             ABORT[new addresses]-------->

                             If the ABORT indicates the list
                             of new addresses (C and D in
                             this case), the next INIT can be
                             launched from an address not on the
                             list (E in this case).

                             <----------INIT[E->X] [C,D,E]

     Existing TCB for E,     INIT-ACK [tie tags]--------->
     populate tie tags.

     Tie tags, Action A      <-----------------COOKIE-ECHO
     Restart.

     <------------------------ABORT

                             COOKIE-ACK------------------>

This also addresses the case where a client restarts from an
association with addresses D, E, with new address set C, D, E.
The association will properly restart on the second INIT
attempt.

This does not yet address that the ABORT[new addresses] is a
breach of security because it tells the attacker whether
associations exists for arbitrary addresses.  (In fact the IG
recommends telling the attacker exactly which addresses in the
error).

Therefore, sending the ABORT should be optional in the same
manner as IG 2.47.  The effect of this solution is the same, it
just takes an INIT timeout instead of an ABORT, and would look
like this:

     Evil Host               Server                Client
     ---------               ------                ------
     IP: A, B                IP: X, Y, Z           IP: C, D, E

     INIT[A->X] [A,B,E]----------->

     <---------------------INIT-ACK

     COOKIE-ECHO------------------>

     <-------------------COOKIE-ACK

     <-----------------HEARTBEAT[B]
     B intentionally      [timeout]
     does not respond

     <-----------------HEARTBEAT[A]

     HEARTBEAT-ACK---------------->

     <-----------------HEARTBEAT[B]
     B intentionally      [timeout]
     does not respond

                             <----------INIT[C->X] [C,D,E]

                             [timeout]

                             <----------INIT[D->Y] [C,D,E]

                             [timeout]

                             <----------INIT[E->Z] [C,D,E]

     Existing TCB for E,     INIT-ACK [tie tags]--------->
     populate tie tags.

     Tie tags, Action A      <-----------------COOKIE-ECHO
     Restart.

     <------------------------ABORT

                             COOKIE-ACK------------------>

Unfortunately, the scanner can still tell that an association
exists for arbitrary addresses, like so:

     Evil Host               Server                Client
     ---------               ------                ------
     IP: A, B                IP: X, Y, Z           IP: C, D, E

     INIT[A->X] [A,B]------------->

     <---------------------INIT-ACK

     This port is listening.

     INIT[A->X] [A,B,C]----------->

     [timeout]  => association exists between X and C on this port.

This information can be used to leverage other attacks.  There
are solutions to this as well (that involve only looking up TCBs
based on the source address of the INIT and ignoring the address
list: the direct opposite of IG 2.18), however, they are more
complicated and would have to wait for another mail.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Wed, 21 Sep 2005 06:10:10 -0400

Just a few comments below... I am sure
Michael will add some more as well :D

> attacker's address included.  The scenario is something like

I believe this stuff was discussed long long ago as
well.. and that is why section 2.34 changed the
"tie-tag" description to be two seperate nonces
that are random and NOT the values in the association..

So the tags, once an association is established
are never put on the wire again....

> the scenario would play out like this:

The error cause in this case is a MAY..  and I believe that
many implementations just send an ABORT() with no error cause
whatsoever....  at least at the last few inter-ops this seemed
to be the case.

This makes it look no different than a INIT hitting a
port that is no longer listening...

> sctpthreats.  That attack looks like this:

The above is an exageration on your part... the current
I-G uses max.burst.. which is set at 4, not 5. And as
we have been discussing, this will be hb.max.burst in
the next I-G... that way its a seperable item... and thus
could be configured to 1 for a default... which would
make the above noise.. since you would get one HB out
and an abort back...

> servers on N IP addresses can easily bomb a multi-homed victim.

As I said in my earlier email.. this is NO different than
current SCTP..

If the attacker lists NON-SCTP aware victims you get:

------INIT[A->X] [A,C,D,E,F,G]------->
<---------------------INIT-ACK
COOKIE-ECHO------------------>
<-------------------COOKIE-ACK
....[HB timers started for A,C,D,E,F,G]

...[30 seconds+RTO(2)+var]..

<-------------HB(A)------
-----------HB-ACK-------->
                         ------------HB(C)-------->
                         ------------HB(D)-------->
                         ------------HB(E)-------->
                         ------------HB(F)-------->
                         ------------HB(G)-------->

..

And that will all happen within roughly the same
time period.. worse.. there is no max.burst limit
on this... the only thing seperating all the HB's is
the variation in the timer that is random and set
at 1/2 the RTT... which will probably be either
0 or a random value between 1-250ms...

So tell me.. whats the difference .. besides the
hb.max.burst limiting sending the number of HB's
how is the current 2960 sending of HB's any
different then the above HB's (other than the
fact that the IG 2.6 HB's are limited by a
burst limit where the above is not)...

So I think that one MUST handle ICMP's to cause
the association to tear down... and in fact I
would be inclined to have the hb.max.burst be
set at 2. This means it takes 2 messages
(assuming a tight cookie-life parameter) for the
"attacker" to generate 2 HB's... not much amplification
there now is there :-D
> retransmitted if ICMP messages do not get through.

And this is true for 2960 as it stands.. the above HB's
are still going to roll out every 30 seconds... in
wave after wave... especially if one does not process
ICMP messages for non-sctp aware hosts...

>      Evil Host               Server                Victim(s)

This is equivilant to setting the hb.max.burst to 1.
Which may or may not be a bad idea...

I am not sure about the HB back to A since this does
now give A a bit of information... but it might
be a good alternative... I would want to think
about this one :-0

>      Evil Host               Server                Victim(s)

And just plain setting hb.max.burst to 1 would yeild the
same effect...

> measure to 2 ineffective.  Consider the following:

And why in the world would the server hang on Address B?

Why not :

       Evil Host               Server                Client
       ---------               ------                ------

                         HEARTBEAT[C]
                              ---------------------->
                              <----ABORT-------------

I would not want to stick to the first address
not responding.. instead it would make far
more sense to go through each of them in
a cycle... that way you would:

a) prevent the above..
and
b) Not keep hitting the same guy (B) with
    a HB.

> change that opened the door for the Section 2 attack in the

And I think the solution in place, with hb.max.burst (instead
of using max.burst).. does not change anything that is not
already in base SCTP... and it solves the problem... you
may not like the solution.. but it does solve the problem...

I think it might be a debate-able item as to what
hb.max.burst should default to... 4 is what Michael
wants... but I don't see that it is a weak solution
to the problem... and in fact it puts a better limit
on HB's in these attack cases that the base RFC2960 does
not.. aka after 30 seconds or so the HB timers are
all going to be going off and doing your amplification
you are so concerned about....

> such an error.  Then it plays out like this:

And if you did not stick with sending the
HB to B, you would have aborted at the whole thing
at the second HB...

> The association will properly restart on the second INIT

If the restart was specifically to add addresses, then I
don't see this as a problem.. just use the add-ip draft
to add the addresses...

If the restart was due to a crash.. and new addresses
were added along with the restart... I doubt very much
that this will be an issue...  since the implementation
will respond with an ABORT to any HB that the server puts
out.... we have had to do special things (like pulling
network cables and sticking them back in) at inter-ops
in order to prevent the HB/Abort from knocking out
associations we are trying to test for the restart
case as it is  ;-D

> recommends telling the attacker exactly which addresses in the

if you look closely that is a MAY not a MUST... so you get an
ABORT() that looks like nothing is listening....

> just takes an INIT timeout instead of an ABORT, and would look

Now this would make sense to me.. changing the language
in 2.6 so that the ABORT is not a MUST but a SHOULD...
This gives the implementation an option on how to respond...
aka as below.. or as above..

>      Evil Host               Server                Client

And again, in your above picture the second HB to B should
really be to C which would cause an ABORT to come back....no
matter....

This is why I like answering like there is no port
listening... did the server go away or restart? the
attacker does not really know...

>      Evil Host               Server                Client

I would think, in the above scenario.. one INIT would
not really be enough to confirm anything... How does
the attacker know that the INIT was not lost in the network?

And as to 2.18, we have had this discussion before.. and
I am sure, it sounds, that we will again :-(

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 Sep 2005 13:59:25 +0200

Hi Brian,

see my comments in-line.

Best regards
Michael

> attacker's address included.  The scenario is something like
That's why the new text says:

    An ABORT MUST be sent in response that MAY include the error
    'Restart of an association with new addresses'. The error SHOULD list
    the addresses that were added to the restarting association.

If an implementer does not want to give this information (and there
are good reasons for it, like you said above), he will simply not
put the error in the ABORT. We could possibly add some text making
the consequences of putting in the Error cause clear.
> sctpthreats.  That attack looks like this:
The case above is where you want to use a small number of HBs...
> retransmitted if ICMP messages do not get through.
True. If admins are filtering packets they must understand the
consequences.
>      Evil Host               Server                Victim(s)
What you basically do is to slow down the path verification and require
the first address (A) to be reachable.

Assume the the left host really owns [A,C,D,E,F,G]. This can not be 
known
by the Server. The intention of multihoming is to provide network fault 
tolerance.
So if after setting the assoc up, A and let's say C become unreachable. 
Can the
server send any DATA? I think not, because there are no verified paths.

So for network fault tolerance you want to do path verification as fast 
as
possible. So that's why you have to find a way in the middle between 
providing
network fault tolerance (send the HB fast) and not being dangerous.
Having a new parameter HB.max.burst can let the user decide what the 
balance is
he wants.
> measure to 2 ineffective.  Consider the following:
The server should try all addresses...
> such an error.  Then it plays out like this:
Why does the server not send a HB to E. The idea of the path 
verification
is to get ACTIVE path as soon as possible. So after trying B it should
try E. Then it would get an ABORT. This should happen before the client
wants to make a connection...
> recommends telling the attacker exactly which addresses in the
No: It says MAY.
> just takes an INIT timeout instead of an ABORT, and would look
Send HBs also to E.
> exists for arbitrary addresses, like so:
When you do not include any address, this is not true.
>      Evil Host               Server                Client
In summary I think:
- It may be good to add some text about the consequences of the 'MAY
   include an error cause'.
- Have a new parameter HB.Max.Burst seems to be good.
- It should be made clear that one should try to confirm all addresses
   and not stick to one until it is confirmed.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Sep 2005 11:19:32 -0600

Michael,

There is no need for destination verification with HEARTBEATS:

- each destination is aready in slow start,

- no more than a single packet or two containing data
  are going to be sent until there is an acknowledgement.

- failure to respond will increase the RTO on the destination
  as fast for DATA as it would for HEARTBEAT,

- data is going to be sent to one destination at a time
                              ^^^^^^^^^^^^^^^^^^^^^^^^^
  (unlike your parallel HEARTBEAT),

- data is already throttled by Max.Burst.

So it seems that your fast HEARTBEATS are more dangerous than the
data that that would otherwise be sent, so the implementation needs
to have the option to not send these new and dangerous HEARTBEATS
and to just send the data, already well protected by slow start and
congestion control.

--brian

On Wed, 21 Sep 2005, Michael Tuexen wrote:

--X--snip--X--

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Sep 2005 11:41:20 -0600

Michael,

> the consequences of putting in the Error cause clear.

Regardless of error code, just sending the ABORT in response to INIT
facilitates port scanning.  (And in this case for existing associations
which is far worse than just listening ports.)

This ABORT in response to INIT needs to be brought under IG 2.47 (ABORT
responses to INITs are optional because firewalls may drop them anyway.)

See IG 2.47.

--brian

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 21 Sep 2005 14:03:28 -0400

> which is far worse than just listening ports.)

Wait a minute... are you talking about this specific scenario or in
general?  If in general, how is that different from RST in response to SYN?

-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 Sep 2005 20:03:12 +0200

Hi Brian,

that's a good catch. So I suggest to change the text to

     An ABORT SHOULD be sent in response that MAY include the error
     'Restart of an association with new addresses'. The error SHOULD 
list
     the addresses that were added to the restarting association.

Then both texts say the same.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 Sep 2005 20:09:10 +0200

Brian,

the verification procedure has several goals:

1. Make sure that all addresses belong to a host when it is
    stating it in an INIT or INIT-ACK. This is to avoid the
    stealing attack.

2. Sending DATA to victim like the attack in section 5 of the
    threat ID.

3. Send DATA to some host and expose its contents.

Because you are not sending DATA on paths which have not been
verified, you want to verify them to be able to use them for
network fault tolerance.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Wed, 21 Sep 2005 15:48:19 -0400

>   are going to be sent until there is an acknowledgement.

are you sure about that? After all you cannot tell how
many packets will be sent.. just that the initial
cwnd = min(4*MTU, max (2*MTU, 4380 bytes))

How many packets that is, is not dictated by this... since,
in theory, you could send a lot of 1 byte TSN's .. not that
this is what happens in practice... if the sender does, they
COULD all be in seperate packets...

>   as fast for DATA as it would for HEARTBEAT,

Go look at the bombing attack illustrated in 5... in this
case the attacker ack's the data.. and thus you WOULD
bomb the victim.. with possibly a lot of data.

> - data is going to be sent to one destination at a time

And thus you hit it.. Max.Burst packets would be sent
to a SINGLE destination...

On the other hand, hb.max.burst  heartbeats will
be sent to multiple destinations...

Oh, and you still have ignored the fact that 2960, with its
multiple HB's timers after 30 seconds will dump the same or MORE
HB outs.. remember the hb timers are individual and not limited
by a hb.max.burst....

> and to just send the data, already well protected by slow start and

No, I would say you are missing the attack scenario 5 and
missing key other points aka... what a normal HB does...

It is MUCH less dangerous to send hb.max.burst HB's to
some number of other destinations then to dump a large
cwnd of packets on someone...

R

---

From: Randall Stewart <[email-masked]>
Date: Wed, 21 Sep 2005 15:49:55 -0400

Michael:

I agree.. and I think I said that in an earlier post... we
should make it a SHOULD :-D

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Sep 2005 16:23:04 -0600

Michael,

>     stating it in an INIT or INIT-ACK. This is to avoid the

I showed you how to thwart the stealing attack without the need
for verification.

> 2. Sending DATA to victim like the attack in section 5 of the

The HEARTBEATS are worse than the data.

> 3. Send DATA to some host and expose its contents.

DATA is never exposed.  It is only sent to the addresses that the
peer requested.

> verified, you want to verify them to be able to use them for

Sending a HEARTBEAT does not provide any assurance that a path
will be availble (for network fault tolerance) in the future.

None of those appear to be reasons.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Sep 2005 16:50:46 -0600

Randall,

> COULD all be in seperate packets...

Under the attack in 5, the packets are retransmissions, that
should be bundled.

> bomb the victim.. with possibly a lot of data.

One address would get cwnd of data (bundled because it is a
retransmission).  With HEARTBEAT, multiple address get a HEARTBEAT.
HEARTBEAT has applification.

> to a SINGLE destination...

In 5, Max.Burst will not be acheived.  Retranmissions are
bundled and only cwnd will be sent (probably one or two
packets).  An easy way to limit that would be to set MTU quite
low (e.g. 536) on new destinations and increase only through
PMTU discovery.
> be sent to multiple destinations...

Yes, all of them, to 4 destinations in parallel.  If
hb.max.burst is 4, that's 4:1 amplification, and the fact that
they are sent to multiple destinations, possibly over multiple
interfaces, makes the sending rate even worse than DATA sent to
a single address from a single interface.

> HB outs.. remember the hb timers are individual and not limited

But jitter is built into the timing so that the probably that
two HEARTBEAT are emmitted at the same time is low.  The same is
not true for these "verification" HEARTBEATs that are
intentionally, it seems, emmitted in parallel.

> missing key other points aka... what a normal HB does...

There is nothing the matter with normal HEARTBEATs.  They are
jittered, they dribble out individually.  And sending them is
OPTIONAL.  And they do not provide the attack in 6 as do
verification HEARTBEATs.

I don't know why any self respecting Evil Host would attack with
5, when the attack in 6 applies to both SCTP-aware and non-SCTP
aware hosts, has more amplification, and can be performed with
the least amount of processing on the attacker's part (simply
resending COOKIE-ECHO).

> cwnd of packets on someone...

So let's set cwnd to an initial value of 1 byte on unverified
addresses and leave it there until an RTO calculation can be
performed.  Then only one packet up to MTU (slop) will be sent
until an ack is received, there is no bombing attack 5 and
because there are no verification heartbeats, there is also no
attack 6.

If MTU bothers you, set it low for unverified addresses (no RTO
calculation) and then either increase it once verified or let
PTMU Discovery increase it.  A far more conservative initial
slow start if you will.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Sep 2005 16:55:30 -0600

Vlad,

Firewalls can discard the SYN without RST.  Similarly, firewalls can
discard the INIT without ABORT.  Both for the purpose of thwarting port
scanning from specific sources.  IG 2.47 adds the option to not send
ABORT in reponse to INIT (downgraded to SHOULD from MUST).  However,
this ABORT[new addresses] still carries a MUST (IG 2.6).  From the same
rationale as IG 2.47, this MUST needs to be downgraded to a SHOULD.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Sep 2005 16:56:51 -0600

Michael,

Yes, precisely.  Do change MUST to SHOULD.  It could even be added as
an incremental text change in IG 2.47.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Sep 2005 11:21:06 +0200

Hi Brian,

see my comments in-line.

Best regards
Michael

> I showed you how to thwart the stealing attack without the need
I know, but I do not think that your proposed solution is as good as 
you think.
> The HEARTBEATS are worse than the data.
I do not see why. If the attacker can guess the TSNs to ack in a good
way the rate of sending data can be high.
The attacker can not raise the rate HB are sent.
> DATA is never exposed.  It is only sent to the addresses that the
Your last sentence it what the security people where pointing out.
Your peer list you some addresses but you have no idea if your peer
really owns them. They can just be listed.
> will be availble (for network fault tolerance) in the future.
My point is: If your peer lists multiple IP-addresses (and there
is no attacker in the game) you should be able (pretty soon) to
make use of the multiple addresses for data transfer.
So the first HBs to be sent are necessary to be able to do data
transfer, they are not sufficient. You are right on that.
I'm assuming here that you do the path verification procedure.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Sep 2005 12:11:50 +0200

Brian,

see my comments in-line.

Best regards
Michael

> Under the attack in 5, the packets are retransmissions, that
Only in the beginning. Without path verification it could simply
choose the path to the victim to be the primary.
> HEARTBEAT has applification.
Just to be clear amplification means the ration of what the attacker
is sending and what to victim is getting.

For the attack in section 5 the attacker is sending SACKs, the
victim is getting the data. Since the attacker can SACK some
TSNs, he can get an amplification...

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Sep 2005 06:22:10 -0400

> I showed you how to thwart the stealing attack without the need

And I don't see that it is a very good procedure...
> The HEARTBEATS are worse than the data.

So lets see, 2 HB's every RTO (assuming my
preference vs michaels one of 4) are worse
than an attacker building up a cwnd of say
64,000 bytes... and then following the
section 5 of the threats document and dumping
that all on someone... hmm.. I don't think I
can agree...

Not counting the fact that all those HB timers
are going off the first time around as well...
> DATA is never exposed.  It is only sent to the addresses that the

Which are not verified...

> will be availble (for network fault tolerance) in the future.

The intial HB's don't do that... they may
a) help you estabilish an RTO
and
b) validate that the address does belong to the peer..

But at any point something can break... even if
you sent hb's every RTT you could not know until
you sent data there if it had not just broken....

R

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Sep 2005 06:45:40 -0400

> Under the attack in 5, the packets are retransmissions, that

a) Bundling is NOT a requirement of ANY SCTP implementation.
b) Even if they are bundled you are looking at 4 MTU's
c) As the attack in 5 points out, if the guy times
    it write he injects false SACK's from the victim
    as well and this means that he can basically bomb
    max.burst packets for every one he sends... so
    we have an amplification as much as using Michaels
    HB.max.burst...

> HEARTBEAT has applification.

And one address gets a cwnd of data .. this is 4 packets.
So for every phony sack the guy sends, the victim
gets 4 packets.

Vs once every RTO you send 2 HB's... to different
addresses... and with very short life cookies,  it
takes the guy 2 packets to send those two HB's..

Not much of an amplification.. according to Michaels
rule its 2:2.... vs your 4:1...

I think I would rather settle for the 2/2 :-)

> low (e.g. 536) on new destinations and increase only through

How does Max.Burst not get achieved? if the cwnd is 4380
and lets assume 1400 byte data pieces..

T3-timeout

-----RETRAN(1400)----> victim
fs=1400
-----RETRAN(1400)----> victim
fs=2800
-----RETRAN(1400)----> victim
fs=3200
-----RETRAN(1400)----> victim
fs=4600 both cwnd and max.burst hit.

Now our attacker injects
<-----SACK(4 tsn's)----from victim

Guess what comes out... another 4 packets
and the cwnd opens further...

a one-to-four amplificaiton.. far more
than you can get with a Hb.max.burst set
at 2... in fact we could easily set the
cookielife down to 3 seconds or so...
which means the guy is having to send
2 to get 2...

> hb.max.burst is 4, that's 4:1 amplification, and the fact that
And so is the attack above.. but my recomendation is
NOT 4 for hb.max.burst.. Michael thinks it should
be but I would prefer 2... that is a 2:1 amplification
ONLY if you have a long cookie-life... what this says
is we should shorten the recommended cookie.life I am thinking
to something around RTO initial...

That makes the amplifcation 2:2 instead...

> a single address from a single interface.

sending out 2 HBs for every RTO is NOT much of
an amplifcation... sorry what you I illustrate above
shows, clearly, a 4:1 amplification with your
solution...

Sorry IMO your "solution" is far far worse
than the few HB's that are sent...
> intentionally, it seems, emmitted in parallel.

Lets see.. the jitter is usually around 1-255ms random..

So.. if I send you a list of 255 IP addresses of
victims... you will send 1 hb every ms 30 seconds
after the association comes up..

Seems to me like yet another amplification...

> OPTIONAL.  And they do not provide the attack in 6 as do
Almost all implementations send them by default.. I have
never yet seen an implementation that does not...

> the least amount of processing on the attacker's part (simply

Assuming a long cookie life... as I said, maybe the cookie life
should really be sitting at about 3 seconds...

and as we know, there are far more window's hosts
out in the world.. so a 5 attack is
just as likely to succeed

> PTMU Discovery increase it.  A far more conservative initial

Sorry I don't like this solution.. it penalizes non-attackers
for no reason...

setting hb.max.burst to 2, and cooklife to 3 seconds to me
seems more appropriate....

Your solution on the other hand does not solve the problems
IMO..

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Sep 2005 04:45:16 -0600

Michael,

> choose the path to the victim to be the primary.

And just how would it do that?  It is the server that chooses the
primary, and the obvious choice is the verified address from the
INIT/INIT-ACK exchange, which cannot be a bogus addresss.

> TSNs, he can get an amplification...

Well no, because the cwnd of the victim addresses will not grow
because they are already retransmitted.  Limiting initial cwnd
to unverified addresses can easily remove the amplification.

OTOH, the only way to remove amplification in 6 is to send 1 HEARBEAT
at a time.  They are not even necessary because 2 and 5 can be solved
without requiring them.  Thus they are harmful.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Sep 2005 06:46:31 -0400

> rationale as IG 2.47, this MUST needs to be downgraded to a SHOULD.

Which I agree with you on :-D

R

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Sep 2005 06:47:06 -0400

> an incremental text change in IG 2.47.

I have already changed it...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Sep 2005 04:51:14 -0600

Michael,

> I know, but I do not think that your proposed solution is as good as 

Please, poke some holes in it.

> The attacker can not raise the rate HB are sent.

The attacker cannot raise the rate that data is retransmitted to the
victim in 5 either.  He can spoof SACKs, but because they were
retransmitted, they cannot grow cwnd and the limit stays in place.

> really owns them. They can just be listed.

If the peer wants to expose his data to the world, he is welcome.
The only purpose can be an attack.

> I'm assuming here that you do the path verification procedure.

Just send limited data.  They proper peer will ack them and cwnd
will grow quickly, but only after they have been verified by DATA.
Sending data for verification instead of HEARTBEATs in fact will
make use of the destination faster than HEARTBEATs.  The HEARTBEATs
carry no useable data and are wasted bandwidth, a wasted exchange,
and a pointless delay.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Sep 2005 04:58:43 -0600

Randall,

> that all on someone... hmm.. I don't think I

64,000 bytes cannot be dumped given an initial cwnd of 1,
and an initial MTU of 536.

> are going off the first time around as well...

They will go off anyway.

> Which are not verified...

So what?  The data is being sent to addresses that the peer gave.
There is no need for the Evil Host to go to all the trouble of
trying to expose data by having us send to addresses that are not
his.  He could easily receive the data himself and send it on to
whatever address in the world he cares.  Nothing can be exposed
that the normal host does not already have the capability to show
to the world.

> you sent data there if it had not just broken....

Exactly my point.  Verification HEARTBEATs don't help.  Sending
data and growing a cwnd does.  The sooner the better.  Skip the
HEARTBEATs and just send data (initially at a restricted rate
until verified).

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Sep 2005 04:59:13 -0600

Randall,

Good, that's settled.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Sep 2005 07:06:52 -0400

> Please, poke some holes in it.

ok
> retransmitted, they cannot grow cwnd and the limit stays in place.

And eventually the destination that WAS primary will
fail.. and of course since the Vicitim address IP-V
will have answered (with spoofed sacks) it will
select this as the new primary... Or maybe one of
the other ones.. does not matter..

Now the CWND DOES grow with every SACK that is sent by
the attacker.. no matter what the initial cwnd is set
to..

And thus you get a 1:max.burst amplification...

> carry no useable data and are wasted bandwidth, a wasted exchange,

But they do, verify that you own an address.. something a
SACK cannot do.... since I can easily spoof a SACK
on any piece of DATA you rediect to an alternate
address...

R

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Sep 2005 07:11:40 -0400

> and an initial MTU of 536.

1)Last time I checked most networks are 1500 bytes. .not
   536.
2) Set the cwnd to 1, I will spoof a sack for the
    first TSN.. you will nicely raise the cwnd to
    1 + 1400 bytes (the size of the data)
    Then the server will send another packet..
    and again I spoof a sack.. I can ramp it
    easily up to the point to get 1:max.burst
    amplification... it may take me a couple of
    packets with your initial cwnd=1, but that is
    not a problem once I get things setup I will
    quickly reach 1:max.burst

>>are going off the first time around as well...

Yep.. so you basically will be sending all those
lovely HB's .. with enough addresses this becomes
a bombing attack in and of itself.. thanks for
agreeing ..
> that the normal host does not already have the capability to show

In the attack case you are correct... the whole idea
is that you ask for something big and then bomb
the guy with the data....

> HEARTBEATs and just send data (initially at a restricted rate

And I will spoof some lovely sacks and grow your
cwnd.. and you will think its verified...

R

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Sep 2005 07:17:26 -0400

> Good, that's settled.
Now as to the HB issue.. I think we
should do the following:

1) As discussed have a hb.max.burst to seperate
    the initial hb's from the max.burst

2) set this value at 2.

And yes, Brian I know you object to this.. but so far
you are alone in your objection...

Michael, I know you had wanted hb.max.burst set to
4, but I think setting it to 2 is safer.... (as a
default of course)...

I would like this discussion to draw to a close... at
least on this item.. unless we have others that
want to comment here...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Sep 2005 05:32:46 -0600

Randall,

>     we have an amplification as much as using Michaels

Start with an initial cwnd of 1 byte and an MTU of 536.  Then
only one packet will be sent.  The attacker can spoof SACKs
all he wants.  They are retransmitted packets and cannot grow
cwnd.

> So for every phony sack the guy sends, the victim

cwnd = 1, MTU = 536, 1 packet.

> takes the guy 2 packets to send those two HB's..

He sends 1 packet (COOKIE-ECHO), and each address gets a
HEARTBEAT, 2 at a time, but the attacker only sends 1 packet
and gets N HEARTBEATS.  That's big amplification.  No setting
of Hb.Max.Burst will help that.  Each address still gets a
HEARTBEAT eventually, and without the attacker sending another
packet.

> rule its 2:2.... vs your 4:1...

cwnd = 1, MTU = 536.  1:1

With 10 victim addresses (he can list as many as he likes or
the server will accept)  10:1

> I think I would rather settle for the 2/2 :-)

Hb.Max.Burst does not change the amplification, just the
rate of the burst.  With 10 victim addresses, 10 HEARTBEATS, 
1 COOKIE-ECHO.

> >>to a SINGLE destination...

cwnd = 1, MTU = 536, 1 packet.

> and lets assume 1400 byte data pieces..

cwnd = 1, MTU = 536, 1 packet.

> <-----SACK(4 tsn's)----from victim

This SACK can't grow cwnd (intially) because they are
retransmitted packets.  Once a secondary is being sent
new data (one packet at a time, cwnd = 1, MTU = 536)
the attacker can continue data flow by spoofing SACKs
and grow cwnd but the large buildup of the attack is gone
and it will take a lot of well timed SACKs to keep it going.

> and the cwnd opens further...

Still better than 10.

> which means the guy is having to send

You can set Hb.max.burst at 1 and the server will still
send 10 HEARTBEATs, one at a time.  And they will queue to
multiple interfaces and can be emitted on the wire in parallel
anyway.

> to something around RTO initial...

The COOKIE-LIFE is not the controlling factor if as the
attacker can get the Server to send N HEARTBEATs (N=16 or as
many addresses as the server will accept).  The attacker can
then still get 5:1 amplification by sending 3 messages
(INIT/INIT-ACK/COOKIE-ECHO) for every 16 HEARTBEATS.

> >>HB outs.. remember the hb timers are individual and not limited

They are jittered so that they will not be emitted together!
Did you forget the +-50% ?

> after the association comes up..

You will verify them at a faster rate, as fast as the server
can loop around for another Hb.Max.Burst, and it will send 255
of them for 3 attacker messages, for a whopping total of over
60:1 multiplication.

> never yet seen an implementation that does not...

My point was that the verification HEARTBEAT are not in the
text as optional.  They are a MUST.

> should really be sitting at about 3 seconds...

Doesn't matter.  If the attacker uses more than 3 victim
addresses, amplification still exists.

> just as likely to succeed

Why?  When a 6 attack will kill them quicker.

> Your solution on the other hand does not solve the problems

Perhaps a better solution would be to send verification
HEARTBEATs, but send them one at a time and require a
successful response to the first one or another successful
HEARTBEAT/ACK exchange with a verified address before sending
another (as I showed in my example).  It removes the
amplification.  With the solution I proposed for attack 2, it
is not necessary to send them so fast.  A legitimate peer will
respond rapidly and all addresses will be in service quickly.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Sep 2005 05:36:04 -0600

Randall,

I see, the rate can be ramped up.  So, send verification
HEARTBEATs, but require a correct ACK before retransmitting or
sending to a new unverified address.  That removes the amplification.
With the solution I proposed for 2, it is not necessary to send
them so fast.  (An attacker cannot camp on an address for longer
than it takes the victim to resend and INIT.)

Attack 2 was the whole purpose for sending them so fast.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Sep 2005 05:38:27 -0600

Randall,

> least on this item.. unless we have others that

No, the problem is all the HB get sent anyway.

Also, I am not convinced that even the Max.Burst that we
have limits anything, because it does not establish a
time period to which it applies and is therefore not
rate limiting.  The current description says something
like "go away and come back", but a very fast machine can
do that in a blink anyway.  So what does it limit?

In attack 6, all the HB get sent, and the amplification
remains, regardless of the setting of Hb.Max.Burst.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Sep 2005 07:42:48 -0400

> Attack 2 was the whole purpose for sending them so fast.

So you are proposing

hb.max.burst = 1

Then I take it..

Which I would not object to... since this means
you can't possibly get an amplification.. even
with longer cookie lifes... and
you still work quickly to send HB.s...

hb.max.burst's Every RTO..

I can live with that.. Michael? You wanted
4, I wanted 2.. would you be happy with
Brian's 1?

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Sep 2005 05:46:51 -0600

Randall,

What is your definition for Hb.Max.Burst?  Is it different from
that for Max.Burst?

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Sep 2005 15:11:41 +0200

Brian,

see my comments in-line.

Best regards
Michael

> INIT/INIT-ACK exchange, which cannot be a bogus addresss.
Yes, but if the path retransmit counter reaches the threshold,
implementations are free to chose another address as the primary path.
> to unverified addresses can easily remove the amplification.
Once the server is not transmitting (=sending for the first time)
the packet to the attacker anymore, you are wrong.
> without requiring them.  Thus they are harmful.
I disagree here.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Sep 2005 15:15:07 +0200

Hi Brian,

see my comments in-line.

Best regards
Michael

> carry no useable data and are wasted bandwidth, a wasted exchange,
The HB sent for verification contain some Random Number which has to
be returned. So the HB-ACKs can not be spoofed.
The only relation between the DATA chunk and the SACK is the TSN,
which can easily be spoofed.
So I think there is a fundamental difference between using DATA/SACK
for verification and HB/HB-ACKs.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Sep 2005 15:18:25 +0200

Randy,

see my comments in-line.

Best regards
Michael

>    the initial hb's from the max.burst
OK.
> 2) set this value at 2.
OK. we have to make is changeable in the socketapi (or at
least on a sysctl base. So the wording should make it clear
that is is a parameter with a default value of 2.
> least on this item.. unless we have others that
I'm happy with the stuff above.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Sep 2005 16:18:37 +0200

Randy, Brian,

as far as I understand the discussion we are in agreement
that we need the path verification procedure and have
two parameters
Max.Burst
HB.Max.Burst

Could you state what they mean? Are they per destination
or per association, what is the meaning (I think Brian
also asked about the time).

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Sep 2005 03:33:19 -0600

Michael, Randall,

The new section 6.1 in IG 2.14 is rather unclear.

It think that what you meant was the following:

- When a SACK is received acknowledging data sent to a destination and,
  before the acknowledgement, the amount of unacknowledged data
  outstanding to that destination, flightsize, is less than cwnd (the
  full cwnd was not utilized when the acknowledgement was received),
  degrade cwnd to the minimum of cwnd and (flightsize + Max.Burst*MTU).

What it currently says is "[w]hen the time comes for the sender to
transmit new DATA chunks," which would be after the acknowledgement,
when flightsize might very well be zero even though the entire cwnd
was utilized on the last cycle.

Also, I think that either "strictly limiting the number of packets
emitted by the output routine" deserves an example of just how that
could possibly be accomplished.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Sep 2005 03:38:10 -0600

Michael,

> for verification and HB/HB-ACKs.

For spoofing of SACKs, it might also be a good idea to note that
if a SACK is received acknowledging TSNs that have not yet been
sent, that the receiver of the SACK SHOULD ABORT the association
[Invalid Mandatory Parameter].  This removes the ability of
attackers to easily send bogus SACKs that can make a sender to
overstep its congestion window.

This spoofing of SACK makes me wonder about another attack.
Maybe the SACK needs a nonce.  Consider the following:

Evil Host                          Server
IP A                               IP X
---------                          ------

<---------Establish Association------->

DATA---------------------------------->
start download

<-------------------------------DATA[1]
<-------------------------------DATA[2]
<-------------------------------DATA[3]
<-------------------------------DATA[4]

SACK[4]------------------------------->
SACK[9]------------------------------->
SACK[15]------------------------------>
SACK[22]------------------------------>
SACK[30]------------------------------>
SACK[39]------------------------------>

etc.

If the server sends new data on each received SACK, it will be
acknowledged on the very next packet processed (even before the
data is emitted on the wire.)

It appears quite easy to ramp up the server's congestion window
this way and get it to saturate its outgoing interface, denying
or degrading service to other users of the interface.

Now many servers throttle at the application layer, but there
are still tricks that can be played with FR and Fast-Recovery.

Adding a nonce to data packets and SACKs might cure this attack,
like so:

Evil Host                          Server
IP A                               IP X
---------                          ------

<-------------------[nonce A]---DATA[1]
<-------------------[nonce A]---DATA[2]
<-------------------[nonce A]---DATA[3]
<-------------------[nonce A]---DATA[4]

SACK[4]-[nonce A]--------------------->

<-------------------[nonce B]---DATA[5]
<-------------------[nonce B]---DATA[6]
<-------------------[nonce B]---DATA[7]
<-------------------[nonce B]---DATA[8]
<-------------------[nonce B]---DATA[9]

SACK[5]-[nonce B]--------------------->
SACK[7]-[nonce B]--------------------->
SACK[9]-[nonce B]--------------------->

This would keep an attacker from faking SACKs.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Fri, 23 Sep 2005 05:39:58 -0400

> What is your definition for Hb.Max.Burst?  Is it different from

At the startup, I have N unconfirmed addresses and 1 confirmed
address. For the 1 confirmed address I would start its
normal HB timer. For the N other addresses I would first
send out HB.Max.Burst HB's to those addresses and start
a timer using RTO + Jitter (i.e. around 3.0 -3.2 sec).
If any of the HB.max.burst answers a HB, I would
start its normal HB timer.. (aka delay + jitter + RTO) and
remove it from the unconfirmed state. At the expiration of
the timer (3.x seconds later) I would take a different
set of the addresses that are still unconfirmed and
send out HB.max.burst (basically going round robin through
the list of addresses). Once again the unconfirmed timer
would be restarted (with its 3 - 3.2 sec value)... this
would continue until:

a) All timers are confirmed (and thus there is nothing left to do)
or
b) All unconfirmed address have had dest.max.rtx's on them.. if that
    happens the normal HB timer is started on them and they are
    also marked not-reachable. Thus they look like any other downed
    address until they respond to a HB...

That is bascially how I would go about doing it... Now the BSD
implementation has one slight difference here.. it only ever
runs one HB timer.. so it does the above but it does not
have other timers to start... and in order to do its round
robin HB.. it always selects the hb.max.burst oldest addresses
(where oldest means longest time since it has had data/or a hb
  sent to it).

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Sep 2005 03:41:26 -0600

Randall,

Please see below:

> 4, I wanted 2.. would you be happy with

Here is what I would like to do in implementation.  Perhaps the
wording can be crafted to accomodate this.

I do not want to verify addresses intially in a burst (to remove
amplification).  So, when sending to unverified addresses, I
want to send a nonce HB, bundled with and followed by a full
initial window of DATA.  I will not accept SACKs for this DATA
until the nonce is acknowledged (destination verified).

Also, when changing from a primary to an alternate and sending
retransmissions, I want to bundle a nonce HB with the
retransmission data (the purpose being to get an accurate RTO
calculation despite the fact that the data sent is
retransmission data).

That way, attackk 5 will play out like this:

 IP A                           IP X, Y                  IP C, D, E

 Evil Host                      Server                   Victim
 ---------                      ------                   -------

 INIT[A->X] [A,C,D,E]-------------->
 <--------------INIT-ACK[X->A] [X,Y]
 COOKIE-ECHO[A->X]----------------->
 <------------------------COOKIE-ACK

 DATA------------------------------>
 initiating download
 <---------------------------DATA[1]
 <---------------------------DATA[2]
 <---------------------------DATA[3]
 <---------------------------DATA[4]
                        [timeout(s)]
			         retransmission to 'C'
			         HB[nonce]DATA[1]------------>
			         DATA[2]--------------------->
			         DATA[3]--------------------->
			         DATA[4]--------------------->
 SACK[2]--------------------------> discarded [or optionally ABORT]
 SACK[4]--------------------------> discarded [or optionally ABORT]
                                 [timeout(s)]
			         retransmission to 'D'
			         HB[nonce]DATA[1]------------>
			         DATA[2]--------------------->
			         DATA[3]--------------------->
			         DATA[4]--------------------->
 SACK[2]--------------------------> discarded [or optionally ABORT]
 SACK[4]--------------------------> discarded [or optionally ABORT]
                                 [timeout(s)]
			         retransmission to 'E'
			         HB[nonce]DATA[1]------------>
			         DATA[2]--------------------->
			         DATA[3]--------------------->
			         DATA[4]--------------------->

			    and so on

For the legitimate host, it looks as follows:

      IP C, D, E                             IP X, Y

      Client                                 Server
      ------                                 ------

      INIT[C->X] [C,D,E]------------------------>
      <----------------------INIT-ACK[X->C] [X,Y]
      COOKIE-ECHO[C->X]------------------------->
      <--------------------------------COOKIE-ACK

      DATA-------------------------------------->
      initiating download
                                  
      primary C already verified
      <-----------------------------------DATA[1]
      <-----------------------------------DATA[2]
      SACK[2]----------------------------------->
      <-----------------------------------DATA[3]
      <-----------------------------------DATA[4]
      SACK[4]----------------------------------->
      <-----------------------------------DATA[5]
      <-----------------------------------DATA[6]
      path failure to C
      <-----------------------------------DATA[7]
      <-----------------------------------DATA[8]
                                     [timeout(s)]

			      retransmission to D
      <----------------------HB[nonce]----DATA[5]
      <-----------------------------------DATA[6]
      <-----------------------------------DATA[7]
      <-----------------------------------DATA[8]

      HB-ACK[nonce] SACK[5]--------------------->
      <-----------------------------------DATA[9]
      SACK[7]----------------------------------->
      <----------------------------------DATA[10]
      <----------------------------------DATA[11]
      SACK[9]----------------------------------->

      etc.

Note that I want to send the HB[nonce] to D even if it was
verified and previously used, so that I can obtain a current RTO
calculation regardless of the fact that it is retransmission
packets being sent.

Please craft the wording of the verification HB along the
following lines:

 - MUST precede (or bundle) data transmission or retransmission
   to an unverified address with an HB[nonce].

 - MUST NOT acknowledge data sent to an unverified address until
   the address is verified ([nonce] returned).  If a SACK
   acknowledging data sent to an unverified address is received,
   discard it or optionally ABORT the association.

The following two can be implicit:

 - MAY precede (or bundle) data transmission or retransmission
   to any address with an HB[nonce] to reverify or reestablish
   an RTO.

 - MAY refuse to acknowledge data sent subsequent to an
   HB[nonce], sent to any address, until the [nonce] is
   returned.

The rest as an implementation note, except:

 - MUST NOT have more than Hb.Max.Burst unacknowledged HB[nonce]
   packets outstanding to unverified addresses, but they may be
   retranmitted with a new [nonce] according to normal RTO
   backoff rules.

I still vote for recommended value of Hb.Max.Burst of 1, with a
requirement that it be no greater than 2. (Because it only takes
two attacker packets [INIT] and [COOKIE-ECHO with DATA] to set
up attack 5.

Even following my preferences above (sending HB[nonce] only when
there is data to be sent to an unverified address), Hb.Max.Burst
limits CMT algorithms that might otherwise send too many
HB[nonce]'s and initial data to too many unverified addresses in
parallel.

Then attack 5 and 6 will be gonzo.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Sep 2005 03:45:11 -0600

Randall,

As regards attack 2 and IG 2.6, can we alter IG 2.6 to permit
the sender of the INIT to add new addresses if the INIT is sent
(and the INIT-ACK will be returned to) an address already
engaged in the association (listed in the TCB).  An INIT-ACK is
in this case returned with tie tags populated as usual.

State that if a client INIT is refused with ABORT[new addresses]
that the client may retry according to Max.Init.Retries but
should retry with a different source address (belonging to the
endpoint sending the INIT), and should not use an address listed
in the cause in the ABORT (if present).

State that if a client INIT times out, that any retry INIT
should use a different source address (belonging to the endpoint
sending the INIT) for the retry INIT.  (Because an ABORT[new
addresses] might not be sent according to IG 2.47.)

Then an attacker will not be able to camp on an address for the
period of time that it takes a server to verify with HB[nonce],
only for the period of time that it takes the client to retry a
few INITs.

Add that any association restarted as result of this procedure
MUST discard data.  (To deny dynamically acquired addresses the
ability to restart a previous hanging association and reap any
of their previous data.)

Then attack 2 will be gonzo.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Sep 2005 03:48:40 -0600

Randall,

Sounds good.  To sum up, a sender must have no more than
Hb.Max.Burst verification HB outstanding to unverified
addresses.

But see my other note on also sending data with them.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Fri, 23 Sep 2005 05:50:01 -0400

> also asked about the time).

In the case of the verifcation procedure there must be
only a single timer running to push out the verification
HB's.. if this is not clear we need some wording
in there to make it so :-D

R

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 23 Sep 2005 14:13:16 +0200

Hi Brian,

good catch!

We wrote in the SCTP treat ID:

    An SCTP implementation should abort the association if it receives a
    SACK acknowledging a TSN which has not been sent.  This makes TSN
    guessing for the attacker quite hard because if the attacker
    acknowledges one TSN too fast the association will be aborted.

but have not put a corresponding text in the IG. I suggest that we  
add ti
the IG:

    An SCTP implementation SHOULD abort the association if it receives a
    SACK acknowledging a TSN which has not been sent.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Sep 2005 14:33:23 -0600

Michael,

Yes I agree, add that.  But although this makes it harder it does
not make it impossible.  It is easy enough I think to predict which
TSNs the server will send and how many at a time.  I suppose the
attacker could even train itself for a brief period by actually
receiving the data.  But what about from there?

I suppose that a HB[nonce] could be bundled every N packets just
to be sure, but it is not reliable.  The HB[nonce] could be lost.
It would be more reliable to have a nonce in each packet carrying
data.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Sep 2005 15:32:12 -0600

Michael,

Maybe I have a solution for this using HB[nonce].  The method would work
like this: ever so often, during cwnd increase, I tag a DATA chunk as
being associated with a nonce and send a HB[nonce] before (or bundled
ahead of) that data chunk.  Whenever the tagged DATA chunk is
retransmitted, the HB[nonce] is sent before (bundled ahead of) it.  If a
SACK cummulatively acknowledging any TSN greater than or equal to the
TSN of the tagged DATA chunk is received, ABORT the association.
When the HB-ACK[nonce] is receive correctly, and cwnd is still growing,
tag the next DATA message and go around again.  That would generate one
HB[nonce] for each round-trip of data utilizing the entire cwnd.  If the
entire cwnd is not being utilized, skip the nonce.

The reliability is reestablished by always retransmitting the nonce with
the tagged DATA chunk.

So the attack would play out like:

 Evil Host                          Server
 IP A                               IP X
 ---------                          ------

 <-------------------------------DATA[1]
 <-------------------------------DATA[2]
 <-------------------------------DATA[3]
 <-----------------HB[nonce A]---DATA[4] (cwnd acheived)

 HB[nonce A]--SACK[4]------------------>

 <-------------------------------DATA[5]
 <-------------------------------DATA[6]
 <-------------------------------DATA[7]
 <-------------------------------DATA[8]
 <-----------------HB[nonce B]---DATA[9] (cwnd acheived)

 SACK[5]------------------------------->
 SACK[7]------------------------------->
 HB[nonce B]--SACK[9]------------------> (attacker cannot predict nonce B)

That way the attacker is not permitted to spoof SACKs that would grow
the congestion window.

With this method, one probably wouldn't need separate HB verification
procedures, for attack 5 (but probably still need a Hb.Max.Burst) for
attack 6.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Mon, 26 Sep 2005 12:44:14 -0400

> was utilized on the last cycle.

I don't agree... the idea is not just for sack processing
but for anytime you send data.. you want to limit
how much you burst out.

Assume I have nothing in flight...

doing

if( (flight + (maxburst * mtusize)) < cwnd)
       cwnd = flight + maxburst * mtusize

Will do just that...

You don't want, after all, a sack that ack's all
data leaving the cwnd up above max.burst mtu's ... otherwise
you can then send more than max.burst mtu's of data...

> could possibly be accomplished.

I don't agree... counting the number of packets you have
emitted between receiving each SACK is not worthy of
writting details on it.... you just set the counter
to 0 when a packet arrives.. and when you are outputting
you increment it each time you send... when you hit
the limit.. you stop outputting...

Whats hard about that? I believe thats what the Sun implementation
does...

The default for the BSD one is the cwnd limiting....

R

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 26 Sep 2005 12:58:22 -0400

Brian F. G. Bidulock wrote:
> amplification). 

I don't see there is amplification if we have HB.max.burst set at
one or even two for that matter (with short cookie-lifes).

  So, when sending to unverified addresses, I
> until the nonce is acknowledged (destination verified).

But that means you would send a FULL WINDOW of data (or 4 packets)
to the guy... this means you have an amplification attack.

I can see doing as you say above as long as you are NOT
allowed to send any more than one packet that MUST
contain a HB.. and NO OTHER packets may be sent to
that destination UNTIL you get a response from the HB...

That would allow you to use a HB+DATA probe for confirmation..

> calculation despite the fact that the data sent is
I don't see anything in the spec that disallows this... and
in fact I think its a great idea... I have been doing
a HB after retransmit for a while in BSD..  Armando Caro and
I worked on this a while back.. I think it was in his
disortation...

> That way, attackk 5 will play out like this:

And you just did an amplification of 4 messages to victim C...

If you only allow a initial cwnd of 1 packet... then the above
I am fine with...

> For the legitimate host, it looks as follows:

Well.. thats fine too.. I know thats the way the BSD
implementation works as well .. it always checks
the nonce.... :-D

I have no problems with crafting something... with the restriction
of 1 MTU of data only to the destination with required
bundled HB... But I want to get through the rest of my email
backlog .. I will craft something after that and post it...

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 26 Sep 2005 13:03:30 -0400

Michael Tuexen wrote:
> but have not put a corresponding text in the IG. I suggest that we  add ti
> the IG:
> 

Do you really think a SHOULD is required... I have no
problem with the wording... but maybe a MAY..

I can go with what ever the consensus is here.. though...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 26 Sep 2005 11:08:27 -0600

Randall,

> Whats hard about that? I believe thats what the Sun implementation

It doesn't say each SACK...

--brian

---

From: Randall Stewart <[email-masked]>
Date: Mon, 26 Sep 2005 13:10:54 -0400

Brian:

But if you don't allow data sent to
a un-confirmed address to begin and
depend on the confirmation process to
enable addresses...

OR as an alternative

Send only 1 MTU of data on retransmission
that MUST be bundled with a HB+nonce..

Then you don't dump 4 packets at
the victim...

---

From: Randall Stewart <[email-masked]>
Date: Mon, 26 Sep 2005 13:13:34 -0400

> It doesn't say each SACK...

And why should it.. any opp to send should be gated
by max.burst..

No matter if you are processing a packet with
a sack... or you are responding to a request from
a user to send data...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 26 Sep 2005 11:15:01 -0600

Randall,

Different attack: this one was for an attacker getting
a server to exceed its cwnd by acking data too fast.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 26 Sep 2005 11:22:10 -0600

Randall,

> a sack... or you are responding to a request from

So you are saying that when data is available after sending max.burst
that I should able to send another max.burst?

Effectively:

    do {
	    for (i = 0; i < max.burst; i++) {
		    send data
	    }
    } while (data available);  <--- another opportunity to send

How does that work?

--brian

---

From: Randall Stewart <[email-masked]>
Date: Mon, 26 Sep 2005 16:11:02 -0400

>     } while (data available);  <--- another opportunity to send

No,

That is not what I am saying..

User.makes.system call ( send(data))
   .... to kernel...

-sctp is called
   -sctp dumps the data into a send queue (multiple chunks)
   -sctp calls the output function
      - for (i=0  ; i< max.burst; i++)
                send a tsn
        return
    return
  return - to -user

Only max.burst packets are ever sent...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 26 Sep 2005 16:32:33 -0600

Randall,

> Only max.burst packets are ever sent...

The above is certainly not explained, and has problems.  The
user interface normally only sends one chunk of data, and
max.burst will never be acheived no matter how fast data is sent
by the user.

For large amounts of data, and a partial sending API, the user
can make system calls that never send more than 2 packets.
Again max.burst is never achieved no matter how fast the user is
capable of sending.

Just slip a loop around your example and replace multiple chunks
with 1 chunk:

for (i = 0; i < 20000; i++) {
	send data chunk i
	> -sctp is called
	>    -sctp dumps the data into a send queue (1 chunk)
}

So I still can't see how that acheives anything.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 27 Sep 2005 23:50:04 +0200

Hi Randy,

I can accept hb.max.burst = 1 for the Internet, since it means that
you have only one unacked HB in flight for path verification.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 27 Sep 2005 23:53:29 +0200

Hi Randy,

I think a SHOULD makes it harder for someone who wants to send
'guessed' SACKs. I can live with a MAY, but would prefer a SHOULD
for making the life of attackers or someone trying to get more bandwidth
as he should get harder.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Sep 2005 00:01:03 +0200

Dear Brian,

the goal of the path verification is one the one hand not to
send packets to a host which might not want them in a sense
of an attack with this sort of packet multiplication. On the
other hand it is also for not providing more information than
necessary to an unconfirmed address.

You can get rid of the packet multiplication stuff by only
sending one MTU of DATA bundled with a HB(nonce). But you
are stiff providing more information compared to just sending
a HB(nonce): TSN, SSN, PID. I'm not really sure to list the
user data here, because if the user wants some security service
he should do something.

I have not thought about a possible attack using this additional
information, but I think providing only as much information as
needed is better than providing more.

So I would prefer doing the path verification first (without DATA).
And use HB.max.burst=1. If the user wants the path verification
faster he can modify HB.max.burst or use sctp_connectx and provide
multiple addresses for the peer.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Sep 2005 00:02:30 +0200

Brian,

see my comment in-line.

Best regards
Michael

> a server to exceed its cwnd by acking data too fast.
This is why I prefer a SHOULD regarding the sending of an ABORT
on reception of a SACK acking something not even sent.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Sep 2005 16:25:32 -0600

Michael,

I prefer SHOULD as well.  The only time that I can see that it would be
worth not doing that is for extremely large bandwidth-delay product
networks where the ack might be left over from the previous TSN window.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Sep 2005 16:31:18 -0600

Michael,

As stated before, the data is going to where the peer requested
it to be sent.

If you mean that the peer application is lax and negligently lists
some insecure address when it establishes an association, then such
a peer is not secure.

Otherwise, the server simply sends data to where the peer requested
it to be sent.

Can you provide an example scenario?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Sep 2005 16:35:26 -0600

Michael,

> on reception of a SACK acking something not even sent.

Yes, I agree.  But it does not defeat the attack.  It is fairly
easly to predict the TSNs that a download server will use, and quite
possible to "train" the attacking program's TSN prediction using
initial data transmissions.

What do you think of an HB[nonce] once every window while cwnd is
increasing?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Sep 2005 16:32:06 -0600

Michael,

I'm good with 1.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Sep 2005 07:30:04 +0200

H Brian,

see my comments in-line.

Best regards
Michael

> initial data transmissions.
I agree with you. But it make it harder. That's why I prefer a SHOULD.
> What do you think of an HB[nonce] once every window while cwnd is
I do not see what you gain by it. Once a IP-address of the peer is
verified, it belongs to the peer. If someone can send back a HB(nonce)
once he can do it multiple times. So I think it is enough to do it once
at the beginning of an association.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Sep 2005 07:34:15 +0200

Brian,

see my comments in-line.

Best regards
Michael

> As stated before, the data is going to where the peer requested
That is right. But the point of the security guys was the following:
1. The address you send the INIT to is known the be owned by the peer.
    If not, he could not send back the INIT-ACK.
2. The address you send the INIT-ACK to is known to be owned by the 
peer.
    If not, he could not send back the COOKIE-ACK.
3. All other addresses are only reported by the peer as his addresses.
Is makes on address of each side 'better' than the others. The result
of the path verification is that they are all really known the be owned
by the peer.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Sep 2005 23:43:15 -0600

Michael,

Perhaps you can get these security guys to give an example of where that
would be a problem, because I sure can't see it.  It can surely not be the
responsibility of the receiver of the INIT to avoid sending data to the
addresses requested by the INIT.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Sep 2005 23:46:27 -0600

Michael,

> at the beginning of an association.

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.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Sep 2005 08:29:31 +0200

Hi Brian,

see my comments inline.

Best regards
Michael

> addresses requested by the INIT.
I disagree here. It is the responsibility of the sender of DATA not to
send it and, for example, attack a victim. The receiver of the INIT does
not know if the sender of the INIT is an attacker.

It is the purpose of the path verification procedure to make sure that
the addresses your peer is presenting you really belong to him.
We also provide a method for the SCTP user to tell SCTP that a set of
addresses are confirmed (by calling bindx).

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Sep 2005 08:34:26 +0200

Hi Brian,

see my comments in-line.

Best regards
Michael

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 28 Sep 2005 01:25:27 -0600

Michael,

On Wed, 28 Sep 2005, Michael Tuexen wrote:

> > Perhaps you can get these security guys to give an example of where
> > that would be a problem, because I sure can't see it.  It can surely
> > not be the responsibility of the receiver of the INIT to avoid
> > sending data to the addresses requested by the INIT.

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.

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".

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 28 Sep 2005 01:48:29 -0600

Michael,

On Wed, 28 Sep 2005, Michael Tuexen wrote:

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

--brian

---

From: Randall Stewart <[email-masked]>
Date: Wed, 28 Sep 2005 09:11:18 -0400

> into problems when packets are reordered in the network.

This same "attack" exists in TCP as well... and if
I remember right there is a draft on tcpm that was
briefly discussed on it. It has not gone to far since
it is, IMO, not seen as a threat worth worrying about.

I would have to go back and reveiw the mailing on
tcpm on this..  but I think I am of the same opinion..

besides.. if you actually do a "strict sack" where you
abort someone that sends a SACK for data not sent.. then
you basically would make the penalty for "lying" pretty
sever.. besides the fact that the receiver has to
be willing to NOT care that the data arrives..

I think this is what as always made me of the opinion
that it is a non-issue.. if you are getting an
FTP of a file (for example) and you sack a piece
of info not yet sent... and then that piece of
info is truely lost by the network (and it
more likely would be... since you are ramping the
sender up illicitly.. heading towards the cliff as
Fred calls it)... then how good is that file transfer
going to be? You got it a bit quicker.. maybe but
you have missing pieces...

R

---

From: Randall Stewart <[email-masked]>
Date: Wed, 28 Sep 2005 09:14:23 -0400

Brian:

I personally do NOT have a problem with you bundling a HB/nonce with
DATA.. with only one condition...

You are NOT allowed to send more than one packet to the destination
until after the HB-ACK returns...

In that case, I see it has nothing more than a delayed HB/nonce
verification.. that just happens to carry a bundled piece of
data with it...

But the cwnd must be set to 1 until after the HB-ACK that moves
it from UNCONFIRMED -> CONFIRMED comes in..

That would basically make it acceptable... I have not
had time to craft the wording for this.. and I will.. later
this week..

R

---

From: Randall Stewart <[email-masked]>
Date: Wed, 28 Sep 2005 09:15:36 -0400

> Sounds like a good demonstration for DoS attack points at the next SCTP

And tell me how TCP is different please?

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 28 Sep 2005 11:01:34 -0600

Randall,

> had time to craft the wording for this.. and I will.. later

I'm ok with bundling one packet.  We were here discussing whether sending
that one packet of data to an unverified address exposes data in some way.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 28 Sep 2005 11:07:05 -0600

Randall,

> it is, IMO, not seen as a threat worth worrying about.

It is much more difficult with TCP because the sequence number
is a byte offset rather than simple monotonoically increasing
chunk number.  If the TSN was allowed to skip some numbers ever
so often it would be more difficult for SCTP too.

> you have missing pieces...

The purpose of the attack is to get the server to saturate its
outgoing interface and deny outgoing datagram service to all
other users of the interface, not to get a download faster.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 28 Sep 2005 11:07:48 -0600

Randall,

Segment number does not monotonically increase.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 Sep 2005 23:38:09 +0200

Brian,

see my comments in-line.

Best regards
Michael

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Sep 2005 16:40:43 -0600

Michael,

> back HB-ACK and drop the SACK. This could require a retransmission

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?

> 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

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 30 Sep 2005 12:36:18 +0200

Brian,

see my comment in-line.

Best regards
Michael

> the protocol handles SACKs that are dropped by the network.
The bundling issue.
One reception of a packet containing two chunks HB,DATA
you can send back a packet containing two chunks HB,SACK but
if the receiver of the DATA does not support bundling we
would send back two packets: one with HB-ACK, one with SACK. The
idea (text suggestion will follow) was that the HB-ACK will
be sent and the SACK will be discarded. But you are right.
If you do not implement bundling, you get not the optimal throughput.
Just another incentive to implement bundling.
> the resulting poor performance can it?
No.

---

From: Randall Stewart <[email-masked]>
Date: Fri, 30 Sep 2005 08:18:32 -0400

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

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

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).
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

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)...

Hopefully sometime today I can get the words crafted for this
and send it to the list for wordsmitthing ;-D

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 30 Sep 2005 11:55:32 -0600

Randall,

Yes, I think we are in agreement.  A couple comments below...

>     the HB+nonce is responded to.. and thus the path

If HB.max.burst is defined right, it will handle case d) as
well:  e.g. maximum number of outstanding verification packets.

> <-----HB-ACK+nonce (possibly bundled).

Yes, and

  ----COOKIE-ECHO,HB[nonce],DATA,DATA

but then bundling of DATA was always permitted with COOKIE-ECHO, it
just needs an HB[nonce] ahead of it if you are going to send the
COOKIE-ECHO to an unverified address.

> <--to:IPB-COOKIE,ACK+HB/nonce

Yes, and

  ---COOKIE-ACK,HB-ACK[nonce],HB[nonce],SACK,DATA,DATA

> HB-Verification procedure (or the HB/Nonce+DATA as they

Good.  I think most applications of multihoming are two interfaces
anyway.

> more than one output packet...

Yes, Michael's ERROR report attack looks particularly ugly.  I think
we need some MUST language there along the lines that Michael proposed.

--brian