Subject: RE: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt

From: Tuexen Michael <[email-masked]>
Date: Mon, 30 Sep 2002 16:16:59 +0200

Dear all,

after thinking a bit more on the m-cast stuff I came 
to the conclusion that we may want to use a different
solution:

The name servers send out periodically (every T sec)
a m-cast message not a SERVER_HUNT, more a SERVER_ANNOUNCE. 

If a P[UE] comes up it will join the m-cast group, receive
such a SERVER_ANNOUNCE message and knows from the source
address a candidate of the name server IP address.

The P[UE] has to wait (in the mean) T/N seconds where
N is the number of name servers.

After a P[UE] knows an IP address of a NS it can
leave the m-cast group, if it wants to. If it
stays in, it can store other IP-addresses in case of
the name server fails.

This soltion has not the problem of the other solution.

What do you think?

Best regards
Michael

Michael Tuexen   Tel.:   +49 89 722 47210
Siemens AG       Fax:    +49 89 722 48212
ICN WN CC SE 7   e-mail: [email-masked]

> -----Original Message-----
> From: Tuexen Michael 
> Sent: Monday, September 30, 2002 3:26 PM
> To: 'Randall Stewart'; Thomas Dreibholz
> Cc: Michael Tuexen; Qiaobing Xie; Tuexen Michael; Thomas Dreibholz;
> [email-masked]
> Subject: RE: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt
> 
> 
> Dear all,
> see my comments below.
> Best regards
> Michael
> 
> Michael Tuexen   Tel.:   +49 89 722 47210
> Siemens AG       Fax:    +49 89 722 48212
> ICN WN CC SE 7   e-mail: [email-masked]
> 
> > -----Original Message-----
> > From: Randall Stewart [mailto:[email-masked]]
> > Sent: Monday, September 30, 2002 2:23 PM
> > To: Thomas Dreibholz
> > Cc: Michael Tuexen; Qiaobing Xie; Tuexen Michael; Thomas Dreibholz;
> > [email-masked]
> > Subject: Re: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt
> > 
> > 
> > Thomas Dreibholz wrote:
> > 
> > > 
> > > A SERVER_HUNT_RESPONSE not via UDP unicast is not a good 
> > idea, since it would 
> > > make a denial of service attack very easy: An attacker just 
> > has to send many 
> > > IP-spoofed UDP packets with SERVER_HUNTs to the multicast 
> > channel. The 
> > > server's response would then to try to establish SCTP or 
> > TCP connections to a 
> > > non-existing address to send the response. Since the 
> > association/connection 
> > > resources (port number, memory) are allocated until a 
> > timeout occurs, the NS 
> > > will probably be out of resources quite soon.
> > > 
> > > 
> > Thomas:
> > 
> > You raise an excellent point.. in fact responding at all to a
> > multi-cast brings up some question..
> > 
> > If I am a evil hacker and I want to sabatoge Michaels machine,
> > all I have to do is send N Server-Hunt's with the made up
> > source address of Michaels machine addressed to the multi-cast
> > channel. The result is that X NS's send back Server-Hunt responses
> > (where X is the number of NS's running).
> > 
> > So I have a nice amplification attack....
> > 
> > In fact one might argue just the oppsite.. if I
> > 
> > a) require server hunts to be ignored if a point-2-point association
> >     exists and the S-H did not come in on that association.
> > b) require server hunts to be sent multi-cast if you have no 
> > alternative
> >     associations up with NS's..
> > c) responses come back SCTP (or TCP for PU's)
> > 
> 
> If we stick to SCTP the following would be a model if understand
> it correctly:
> 
> If the P[UE] knows an IP address of a NS, it establishes an
> association from port 5151 to port 5151 and sends a SERVER_HUNT via
> SCTP. The SERVER_HUNT_RESPONSE will be sent back on the same assoc.
> If the P[UE] does not know an IP address it sends a UDP multicast
> SERVER_HUNT. The NS will accept assocs from port 5151 on port 5151.
> This association will then be used for SERVER_HUNT_RESPONSEs.
> If a SERVER_HUNT arrives at a NS and an association has already
> been established, there will be no SERVER_HUNT_RESPONSE sent. That
> is good and avoids the kind of attack Thomas and Randy are 
> talking about.
> But there is one problem, assuming that my machine is under attack.
> 
> If my machine is running ASAP the assocaition is up and runnig after
> the first packet of the attack and Randys rule saves my machine. But
> consider the case my machine is NOT running ASAP. So the incoming INIT
> will be responded with an ABORT chunk there will be no assoc 
> coming up.
> If the name server processes these ABORT, stops the time, 
> clears the TCB,
> the ASAP layer will try to set up an assoc after the next UDP 
> multicast
> packet comes in. In this case my machine would get 100,000 INITs and 
> send in addtion to that 100,000 ABORTS. Hmmm. In case of UDP 
> my machine would
> send back ICMP port unreachable instead of ABORTS. (Do you 
> recongize that
> my machine runs SCTP, if not it would have sent back ICMP 
> protocol unrechable).
> 
> So the situation is:
> 
> - there are X NS involved.
> - the attacker sends N multicast messages.
> - if the machine under attack runs ASAP
>   it gets X associations and it better keep them up.
> - if the machine under attack does NOT run ASAP
>   it gets X * N INITs and sends N ICMP or ABORTS to EACH of the X NS.
> 
> The consequence: Better run ASAP or disable m-cast. Hmmm. Any 
> suggestions?
>   
> 
> I think the multicast stuff is definitly something for the 
> security section...
>  
> > Then what will happen is the attack will only gain you 'X' 
> connections
> > to name servers and now the attacker can no longer amplify 
> > his packets..
> > 
> > Yes you get a burst of associations... say I have 10 NS's I have an
> > existing association up to 2 of them.. I get instantly 8 
> associations
> > to NS's and server hunt responses.. but that is the end.
> > 
> > If we respond UDP unicast.. Then I the attacker can send 
> > 10,000 messages
> > and the NS's will send 100,000 messages...
> > 
> > R
> > 
> > 
> > 
> > 
> > -- 
> > Randall R. Stewart
> > [email-masked] 815-342-5222 (cell phone)
> > 
> 
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Randall Stewart <[email-masked]>
Date: Mon, 30 Sep 2002 14:17:38 -0500

Michael:

This sounds very promising... it avoids the situation all
together and it also allows a PU/PE to compose a list of
servers if it so desires..

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 30 Sep 2002 14:17:38 -0500

Michael:

R

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 30 Sep 2002 14:34:01 -0500

I like this idea too. It's clean and straightforward and reduce the
number of asap message by 1. Perhaps more important is that it needs not
to use UDP unicast (I just hate to see ASAP ends up using all of SCTP,
TCP, UDP unicat, UDP m-cast. That would be real ugly, IMO).

-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 30 Sep 2002 14:34:01 -0500

-Qiaobing