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

From: Qiaobing Xie <[email-masked]>
Date: Fri, 27 Sep 2002 16:39:12 -0500

Hi, Michael,

....
> Hmmmm, OK, it seems that we agree that an ENRP server SHOULD always
> listen on a TCP and SCTP socket, MAY listen on a UDP multicast socket and always
> uses the same port number.  What is new (for me) that the response of the
> SERVER_HUNT is sent by TCP or SCTP. This would mean that the NS is a client. Hmm.
> In my understanding the SERVER_HUNT was sent as UDP unicast. Thats all. The PU 
> has to set up an SCTP assoc or TCP connection for doing name resolution requests. 
> If mutlicast is not available, the first step (send UDP multicast, receive UDP 
> unicasr) is omitted. For security this would be simpler, because in both case 
> would the PU start the communication.

I sense that more clarifications are needed for server hunt in both enrp
and asap. Let's lay it out with more details here (assuming the
to-be-defined well known asap port is 5151 for both TCP and SCTP, and
the well-known IP m-cast channel for asap is 244.1.2.3):

After an ENRP server (aka NS) finishes its initialization and 
enters the service, it:
1) MUST listen for incoming asap messages on SCTP/port=5151;
2) optionally also listens for incoming asap messages on TCP/port=5151;
3) optionally join m-cast group 244.1.2.3 (via a UDP or TCP socket, but 
   this shouldn't matter) for incoming m-cast asap messages.

If the NS choice not to support TCP-based PUs, it won't do 2).
Similarly, if m-cast is not available at the NS site, it won't do 3).

Now let's move on to the PE/PU side. 

For a PE, we've agreed that it MUST NOT use TCP for asap, this should
IMO include server-hunt. Therefore, a PE can either do a server-hunt via
SCTP if its site has no m-cast And it knows a pre-configured list of
available servers in its scope, or do a server-hunt via m-cast if
available. In the former case, the PE sends a copy of server-hunt to
each NS on the list at SCTP port 5151. In the latter case, the PE sends
a server-hunt to channel 244.1.2.3 (it shouldn't matter whether the
m-cast is sent out via a UDP or TCP socket, m-cast is an IP service).
The PE will attach a SCTP transport TLV in its server-hunt to tell the
NS where to send the response back. In either case above, when a NS
chooses to respond, it should always send its server-hunt-resp back to
the PE over SCTP (for sending response to the PE, no UDP, no m-cast, no
TCP should be allowed). After that, the PE picks a home server and sends
its reg to the server over SCTP....

For a PU, it has one more choice - TCP - when sending its server-hunt.
The rest should be the same as the above. Back to our previous
discussion, in the case where a TCP-only PU chooses to do server-hunt
via m-cast, it simply includes a TCP transport TLV in the server-hunt
message so that the NS will not respond via SCTP.

So the behavior on NS side should be to simply send back the
server-hunt-resp to wherever the transport TLV in the server-hunt
pointing. But unicast UDP should never be used for any asap messages. I
belive we agreed on this point a long time ago.

regards,
-Qiaobing
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 27 Sep 2002 16:39:12 -0500

Hi, Michael,

....

regards,
-Qiaobing

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 28 Sep 2002 22:05:52 +0200

Qiaobing,

I'm online again...

See my comments below.

Best regards
Michael

> the well-known IP m-cast channel for asap is 244.1.2.3):
I'm assuming that we use UDP as the transport protocol for the
multicast SERVER_HUNT meessage. We use port P for that. So the
question is if P equals 5151.
> Similarly, if m-cast is not available at the NS site, it won't do 3).
What about requesting that NS MUST support SCTP and TCP based name 
queries?
I have no problem with that and almost all hosts support TCP.
> Now let's move on to the PE/PU side.
OK.
> m-cast is sent out via a UDP or TCP socket, m-cast is an IP service).
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.
> its reg to the server over SCTP....
Here I had a different understanding. In my understanding the PE will 
always
set up the SCTP assoc. It will use the well known port number. So it 
needs
to know an IP Address. If there are some pre configured ones, these can
be used by the PE to start the assocs. If there are no configured one 
and
m-cast will be used, the PE sends a UDP message on the m-cast channel 
and
the port 5151. The NS respond with a UDP unicast message. The NS can now
try the source address (which is a unicast address of the NS) of the 
SERVER_HUNT_RESONSE
as an IP address of the NS. So it is only a different way of getting an
IP address of a NS. From that point of time on, the procedure is the 
same.
This simplifies also the security stuff, because we have only to think 
about
on procedure.
> message so that the NS will not respond via SCTP.
You do not need this, if you require the NS to support SCTP and TCP. 
This
is the simpler solution.
> belive we agreed on this point a long time ago.
I'm not sure on this. At least, I did not. UDP unicast would in my 
suggestion
be used for the SERVER_HUNT_RESPONSE. This is a very simple procedure 
and the
NS would not be clients for ASAP in one case and Server in the other.
It seems that this point needs some more discussion until we agree on 
one solution.

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 28 Sep 2002 22:05:52 +0200

Qiaobing,

I'm online again...

See my comments below.

Best regards
Michael

OK.

---

From: Thomas Dreibholz <[email-masked]>
Date: Mon, 30 Sep 2002 11:16:05 +0200

On Samstag, 28. September 2002 22:05, Michael Tuexen wrote:
Hi all,

see my comments below.

Best regards

> >    this shouldn't matter) for incoming m-cast asap messages.
TCP is always unicast, therefore only UDP sockets are possible here.

> It seems that this point needs some more discussion until we agree on

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.

- -- 
=======================================================================
 Dipl.-Inform. Thomas Dreibholz
 Molbachweg 7
 D-51674 Wiehl-Forst    Mail: [email-masked]
 Germany                WWW:  http://www.exp-math.uni-essen.de/~dreibh
=======================================================================

---

From: Thomas Dreibholz <[email-masked]>
Date: Mon, 30 Sep 2002 11:16:05 +0200

see my comments below.

Best regards

- --

---

From: Randall Stewart <[email-masked]>
Date: Mon, 30 Sep 2002 07:06:20 -0500

> its reg to the server over SCTP....

This all sounds good.. but I do have one question. In the case
of a NON-multicast scenario.. why do you need a transport TLV?
After all the receiver should know it came in via a SCTP 
socket/association. I can see the need on multicast.. and I might
even buy a symetry argument... but it seems to me this might
be an optional parmameter... unless implementation wise it makes
more sense not to.. i.e. for symetry

> belive we agreed on this point a long time ago.
I guess this could simplify the NS.. in that you just follow the TLV.. but
then could I send a server hunt via the SCTP list and request that
you send it back TCP?

I really think the NS should send it back via the channel it arrived
on aka either TCP or SCTP... and only look at the Transport TLV if
it came in via Multi-cast...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Randall Stewart <[email-masked]>
Date: Mon, 30 Sep 2002 07:06:20 -0500

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 30 Sep 2002 07:13:08 -0500

> question is if P equals 5151.

Yes, it should..

> What about requesting that NS MUST support SCTP and TCP based name queries?
> set up the SCTP assoc. It will use the well known port number. So it needs
> be used by the PE to start the assocs. If there are no configured one and
> m-cast will be used, the PE sends a UDP message on the m-cast channel and
> IP address of a NS. From that point of time on, the procedure is the same.
I like this even better.. it is how I think we used to do it in the
very first prototype, of course you did not have TCP as a choice.

Basically you respond via the way the message arrived.. so if it came
in on a SCTP association (aka server-hunt) the NS would respond on that
same assocaition.

If it came in Multicast/UDP then it would respond with a point to point
UDP message.

Then the sender of the server-hunt can send the NS request via SCTP or 
whatever (if it is a PU).

> You do not need this, if you require the NS to support SCTP and TCP. This
> is the simpler solution.
> 

But why not give the option of only supporting SCTP if the NS wants to
do it this way? Code wise it is simpler to listen to one
port than two....

> It seems that this point needs some more discussion until we agree on 

ok..

---

From: Randall Stewart <[email-masked]>
Date: Mon, 30 Sep 2002 07:13:08 -0500

Yes, it should..

ok..

---

From: Randall Stewart <[email-masked]>
Date: Mon, 30 Sep 2002 07:22:36 -0500

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

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 30 Sep 2002 07:22:36 -0500

Thomas:

R

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 30 Sep 2002 11:54:23 -0500

> more sense not to.. i.e. for symetry

I was more looking at symmetry and simplification of NS code :-) I have
no problem to make this TLV an optional param (see below).

> it came in via Multi-cast...

This will work for me. To be complete, I guess the NS will ignore the
TLV (if present) if the hunt came in via a non-m-cast channel and will
ignore the hunt if the hunt came in via m-cast without a TLV.

-Q

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 30 Sep 2002 11:54:23 -0500

-Q

---

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

...
> 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: Qiaobing Xie <[email-masked]>
Date: Mon, 30 Sep 2002 14:28:09 -0500

...

-Qiaobing

---

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

Hi, Michael,

...
> > But unicast UDP should never be used for any asap messages. I
> I'm not sure on this. At least, I did not. 

At the very beginning we intended to use "SCTP only" for all RSERPOOL
signaling (i.e, ENRP and ASAP) plus using m-cast for some messages
whenever it is available for bandwidth efficiency. We later agreed on
opening a door for using TCP for ASAP in a special case for PUs (Maureen
presented a strong and clear justification for that case). But I never
remember we've agreed to open a door for using UDP unicast for ASAP as
well. If I am incorrect here, someone please remind me what I must have
missed.

But I like your latest SERVER_ANNOUNCE msg idea. And that eliminates the
UDP unicast issue.

regards,
-Qiaobing

---

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

Hi, Michael,

...

regards,
-Qiaobing

---

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

I believe if one looks closely that the M-cast is specifically forbidden
by the RFC itself... Chip wrote something in there to the effect
that any NON-Unicast packet MUST be discarded..

R

---

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

R

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 30 Sep 2002 15:06:25 -0500

I know we deliberately prohibited m-cast in SCTP stack itself. But I was
talking about the feasibility of some socket layer trickery that can
by-pass the SCTP stack.

-Q

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 30 Sep 2002 15:06:25 -0500

-Q