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

From: "Schruefer, Wolfgang" <[email-masked]>
Date: Fri, 23 Sep 2005 12:08:40 +0200

Randy,

I suppose there is a misunderstanding ... you need not to check the source address.

Theory: the best method is to use an packet amplification factor of 1!

That means: whenever we receive a packet (from any address of the peer), we are allowed to send a heartbeat to the next unverified address.

In my opinion this contains no risk, is easy to understand and we avoid a new protocol parameter.

Best regards
Wolfgang

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Randall Stewart
> Gesendet: Freitag, 23. September 2005 11:47
> An: Schruefer, Wolfgang
> Cc: [email-masked]; [email-masked]; Michael Tuexen; 
> Vlad Yasevich; Coene, Lode; Kacheong Poon; Scott Bradner
> Betreff: Re: [Tsvwg] ICMP issue with SCTP IG
> 
> Schruefer, Wolfgang wrote:
> > Brian,
> > 
> > as a client I would send immeadately n Heartbeats, where n is the 
> > number of my local adresses. Then the server could verify all paths 
> > immediately. I think that would work better than some other solution
> 
> 
> 
> I agree with Brian somewhat for his objection on this.. but I 
> will add one more.
> 
> The above is highly dependant on routing table's. It is 
> always possible that I can send to both of your addresses and 
> you can send to both of mine...
> 
> But I may NOT be able to send to your addresses with the 
> source addresses I wish to use depending on the routes..
> 
> Consider
> End-A                            End-Z
> IP-A                              IP-X
> IP-B                              IP-Y
> 
> End-A has a default route pointing out IP-A1 (its ISP).
> 
> If a packet sourced from IP-B goes out IP-A1, the ISP does 
> ingress filtering and drops it.
> 
> Its a linux box.. so it has a second route (default) out IP-B-1.
> 
> This second route will only kick in when IP-A's network fails..
> 
> 
> So, now If End-A is the client, how can it do what you say?
> 
> 
> End-Z on the other hand can always reach IP-A and IP-B with a 
> HB.. .even thoug the HB it sends to IP-B comes back sourced 
> from IP-A... this is why we put the HB destination inside the 
> HB message (or at least most of us do :-D)
> 
> R
> --
> Randall Stewart
> 803-345-0369 <or> 815-342-5222(cell)
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

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

Wolfgang,

That's similar to one proposal, which was to send a HB to the verified
address (and require a response) before sending one to another unverified
address.  I believe it was Michael that didn't like that one.  Perhaps
he explained why as follows:

On Wed, 21 Sep 2005 13:59:25 +0200, Michael Tuexen wrote:

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

--brian

On Fri, 23 Sep 2005, Schruefer, Wolfgang wrote:

> That means: whenever we receive a packet (from any address of the
> peer), we are allowed to send a heartbeat to the next unverified
> address.
> 

-- 
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: "Schruefer" <[email-masked]>
Date: Fri, 23 Sep 2005 15:26:42 +0200

Brian,

no, I think it is better, because the peer can speed up the verification
time by sending Data or Heartbeats  via any path. By the other proposal only
HB-Acks would continue the verification process.

Best regards
Wolfgang

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Brian F. G. Bidulock
Gesendet: Freitag, 23. September 2005 12:33
An: Schruefer, Wolfgang
Cc: [email-masked]; Coene, Lode; Vlad Yasevich; Michael Tuexen; Randall
Stewart; Scott Bradner; Kacheong Poon
Betreff: Re: [Tsvwg] ICMP issue with SCTP IG

Wolfgang,

--brian

---

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

Schruefer,

If Hb.Max.Burst is 1, I suppose the only difference is:

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

                              etc.

instead of:

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

                              etc.

So the rate that the server sends heartbeats is very low (timeout is 3 seconds),
and requiring the attacker to send an ack doesn't acheive much.    Logic for the
Hb.Max.Burst might be easier to implement (use existing HB interval mechanism).

--brian