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

From: Tuexen Michael <[email-masked]>
Date: Tue, 1 Oct 2002 13:58:51 +0200

Hi Randy,

I will see what I can do today but I might need until tomorrow
to commit the changes to ASAP and ENRP.

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: Tuesday, October 01, 2002 1:35 PM
> To: Tuexen Michael
> Cc: 'Thomas Dreibholz'; 'Michael Tuexen'; 'Qiaobing Xie'; 'Thomas
> Dreibholz'; [email-masked]'
> Subject: Re: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt
> 
> 
> Michael:
> 
> Go ahead and make the change... if you can get it
> in earlier enough I will have time to do a review of
> your changes today..
> 
> I am off of design doc's today and on to i-d's :>
> 
> R
> 
> 
> Tuexen Michael wrote:
> > Qiaobing, Maureen,
> > 
> > what do you think. If you agree, I would modify the ASAP and ENRP
> > to the new procedure.
> > 
> > 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 9:18 PM
> >>To: Tuexen Michael
> >>Cc: 'Thomas Dreibholz'; 'Michael Tuexen'; 'Qiaobing Xie'; 'Thomas
> >>Dreibholz'; [email-masked]'
> >>Subject: Re: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt
> >>
> >>
> >>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
> >>
> >>Tuexen Michael wrote:
> >>
> >>>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
> >>>
> >>>
> >>
> >>
> >>
> >>-- 
> >>Randall R. Stewart
> >>[email-masked] 815-342-5222 (cell phone)
> >>
> > 
> > 
> > 
> 
> 
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Tuexen Michael <[email-masked]>
Date: Tue, 1 Oct 2002 13:58:51 +0200

Hi Randy,

Best regards
Michael

---

From: Tuexen Michael <[email-masked]>
Date: Tue, 1 Oct 2002 10:02:21 +0200

Qiaobing,

as far as I understand neither TCP nor SCTP can run
over m-cast. They are unicast protocols.

In my understanding the problem lies in the fact
of acknowledgements. Some of the receivers might
have received some DATA chunks, others not. Will
you retransmit? So providing reliablibilty is the
problem. There is a WG on this topic:
http://www.ietf.org/html.charters/rmt-charter.html

Best regards
Michael 

> From: Qiaobing Xie [mailto:[email-masked]]
> Sent: Monday, September 30, 2002 9:28 PM
> To: Michael Tuexen
> Cc: Tuexen Michael; 'Randall Stewart'; Thomas Dreibholz;
> [email-masked]
> ...
> > Hmm. I'm not an m-cast expert, but up to my understanding 
> you can not
> > use m-cast with TCP or SCTP. So UDP is the only transport 
> protocol you
> > can use. In addition to the m-cast group you need a UDP 
> port number. You
> > can use the same as the port number for TCP and SCTP.
> 
> Yes, Michael, you are correct. Although the m-cast man page 
> says you can
> do m-cast via any datagram transport, but in practice UDP is probably
> the only datagram socket usable (I don't know of any SCTP socket has
> m-cast support implemented).
> 
> -Qiaobing
>

---

From: Tuexen Michael <[email-masked]>
Date: Tue, 1 Oct 2002 10:47:04 +0200

Qiaobing, Maureen,

Best regards
Michael

> >>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
> >>
> >>>Cc: Michael Tuexen; Qiaobing Xie; Tuexen Michael; Thomas Dreibholz;
> >>>[email-masked]
> >>>channel. The result is that X NS's send back Server-Hunt responses
> >>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.
> >>SERVER_HUNT. The NS will accept assocs from port 5151 on port 5151.
> >>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
> >>>Yes you get a burst of associations... say I have 10 NS's I have an

---

From: [email-masked]
Date: Wed, 2 Oct 2002 06:39:07 +0300

Hi Micheal,

The model you have suggested sounds like a better one, so I support
it.

John

> From: ext Michael Tuexen [mailto:[email-masked]]
> Sent: 02 October, 2002 00:43
> To: Qiaobing Xie
> Cc: Tuexen Michael; 'Randall Stewart'; 'Thomas Dreibholz'; 'Thomas
> Dreibholz'; [email-masked]
> introducing a SERVER_ANNOUNCEMENT message and the procedure
> described earlier makes the SERVER_HUNT, SERVER_HUNT_RESPONSE
> useless in my opinion.
> 
> You are only testing if the peer provides ASAP service. But you
> get (almost) the same by establishing an SCTP association or
> TCP connection to the registered port.
> 
> Therefore I'm suggesting to get rid of the SERVER_HUNT, 
> SERVER_HUNT_RESPONSE
> message.
> 
> Any objections, comments?
> 
> Best regards
> Michael
> 
> On Tuesday, Oct 1, 2002, at 18:39 Europe/Berlin, Qiaobing Xie wrote:
> 
> > Michael,
> >
> > Please go ahead and make the changes.
> >
> > -Q
> >
> > Tuexen Michael wrote:
> >>
> >> Qiaobing, Maureen,
> >>
> machine. 
> >>>>> But
> NS's I have 
> >>>>>> an

---

From: [email-masked]
Date: Wed, 2 Oct 2002 06:39:07 +0300

Hi Micheal,

John