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

From: Randall Stewart <[email-masked]>
Date: Tue, 01 Oct 2002 06:34:35 -0500

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: Randall Stewart <[email-masked]>
Date: Tue, 01 Oct 2002 06:34:35 -0500

Michael:

R

---

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

Qiaobing, Maureen,

Best regards
Michael

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 01 Oct 2002 11:39:45 -0500

Michael,

Please go ahead and make the changes.

-Q

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 01 Oct 2002 11:39:45 -0500

Michael,

-Q

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 1 Oct 2002 23:42:50 +0200

Dear all,

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 1 Oct 2002 23:42:50 +0200

Dear all,

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Tue, 01 Oct 2002 16:57:49 -0500

Makes sense to me..

the SERVER_ANONCUMENT basically replaces the two messages..

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 01 Oct 2002 16:57:49 -0500

Makes sense to me..

R

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 01 Oct 2002 17:38:26 -0500

I agree too. 

In addition, we may need an optional transport address TLV in the
server-announcement so that the server can indicate to the perspective
PU/PE that "I only support ASAP/SCTP, so pls don't try
name-query-over-TCP with me" or "I am using a non-standard port to
listern to my incoming ASAP, so pls don't send them to the well-known
ASAP port".

-Q

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 01 Oct 2002 17:38:26 -0500

I agree too. 

-Q

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Oct 2002 00:04:39 +0200

Qiaobing,

while I'm writing up the stuff I found the following problem:

consider the following as a SERVER_ANNOUNCEMENT message as you
suggested:

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 0x0a |0|0|0|0|0|0|0|0|        Message Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                       Transport param #1                      :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                       Transport param #2                      :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:                             .....                             :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                       Transport param #n                      :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This message is sent out periodically by the ENRP server such that
P[UE]s know transport addresses of the ENRP servers. The transport
parameters provide (optionally) the TCP and SCTP information needed
by the P[UE]s for accessing the ENRP using ASAP.

But I want to use the same method to be used for detecting ENRP
servers by an ENRP server. But the other ENRP server must know
the SCTP information to access this ENRP server. This information
is different from the above. So this can not be the same message.

One solution I see is that we register at IANA

- a port number (UDP, SCTP) P' for ENRP
- a port number (UDP, TCP, SCTP) P'' for ASAP
- an RSerPool multicast address A

We send out a SERVER_ANNOUCE to A with port P' using UDP over IP 
multicast
to provide the ENRP information and send out another SERVER_ANNOUNCE to 
A with
port P'' using UDP over IP multicast to provide ASAP information.
If the ENRP server uses P' for ENRP, the transport parameter can be 
omitted,
if the ENRP server uses P'' and supports only SCTP the transport 
parameter can
be omitted.

These are twice as much multicast messages as I thought initially but I 
think
they are needed.

Do you have other ideas?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Oct 2002 00:04:39 +0200

Qiaobing,

Do you have other ideas?

Best regards
Michael

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 04 Oct 2002 15:25:53 -0500

Hi, Miachael,

> consider the following as a SERVER_ANNOUNCEMENT message as you

This looks fine. Though I think we need to clearly define when and how a
server should use multiple (optional) trans params. A server that
supports only SCTP on the well-known port should include no transport
param, right?

> by the P[UE]s for accessing the ENRP using ASAP.

yes.

> is different from the above. So this can not be the same message.

I am confused here. The SERVER_ANNOUCE we are defining here is an *ASAP*
message. For an ENRP server to discover its peer(s), we have a
PEER_PRESENCE (mtype=0x1) defined in *ENRP*. They should be kept
separate since they serve different purposes and their transmission
intervals should be controlled separately.

> - an RSerPool multicast address A

This is fine, except that I'd clarify that the UDP ports for ENRP and
ASAP are used only for multicast, not for sending/receiving ENRP or ASAP
messages over UDP unicast. 
 
> We send out a SERVER_ANNOUCE to A with port P' using UDP over IP multicast
> to provide the ENRP information 

No, the message the server sends (via m-cast) to A/P' is called
PEER_PRESENCE (msg type=0x1) in ENRP draft. It's already defined since
v00.

> and send out another SERVER_ANNOUNCE to A with

Correct.

> omitted, if the ENRP server uses P'' and supports only SCTP the transport
> parameter can be omitted.

As I mentioned above (as well in my previous emails), ENRP and ASAP are
using separate message type spaces, and I think that is a good approach
and should be kept that way. To try to re-use the same msg for both side
IMO does not save much, but may cause confusion (and may make the
implementation more complicated, at least in mine).

regards,
-Qiaobing

> 
> These are twice as much multicast messages as I thought initially but I think
> they are needed.
> 
> Do you have other ideas?
> 
> Best regards
> Michael
>

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 04 Oct 2002 15:25:53 -0500

Hi, Miachael,

yes.

 

Correct.

regards,
-Qiaobing

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Oct 2002 22:42:12 +0200

Hi Qiaobing,

see my comments below.

Best regards
Michael

Correct.
> intervals should be controlled separately.
Yes I agree, that is what I wanted to say. Just not realized that the 
message
already exists and is called PEER_PRESENCE.
> messages over UDP unicast.
I will do that.
> PEER_PRESENCE (msg type=0x1) in ENRP draft. It's already defined since
I overlooked that.
> implementation more complicated, at least in mine).
I agree with you, I was very in favor of separate type space. I even did
not meant to use the same message type for ENRP and ASAP, just the same
layout. But the message is already there.
I just wanted to make sure that ENRP and ASAP need separate mechanisms,
because I first thought that one is enough. That is wrong.

Best regards
Michael
>>>>>>>>>> association from port 5151 to port 5151 and sends a 
>>>>>>>>>> SERVER_HUNT
>>>>>>>>>> via

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Oct 2002 22:42:12 +0200

Hi Qiaobing,

see my comments below.

Best regards
Michael

Correct.
I will do that.
I overlooked that.

Best regards
Michael

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 29 Oct 2002 23:06:41 +0100

Dear all,

I was thinking about the the multicast related procedure in ENRP. Even 
if we
modify it such that an ENRP server does periodic announcements and a new
server will just listen to these announcements we still have a problem.

The ID currently says that when an ENRP server gets information about a 
new
server, it will try to connect to it. Let us assume that we have N ENRP 
servers
running. What happens if I send a PEER_PRESENCE message by using 
multicast
and (spoofed) IP address A. Then all ENRP servers will try to setup an 
association
with A. Or am I wrong? i think only a random delay between the 
reception of the
multicast message and the start of the association / connection will 
help.

Another 'problem': In section 4.7 it is described that in case a PU 
finds
a PE unreachable it informs its Home ENRP Server. This server will send 
a
ENDPOINT_KEEP_ALIVE message. So the PU/PE will be a server? I thought 
that this
check would be performed by the Home ENRP server of the PE in question? 
AM I wrong?

Another fundamental question: All ENRP servers in an operational scope 
have
fully meshed SCTP associations, or not? Or a some using the multicast 
stuff to replace
that?

Best regards
Michael
--
[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 29 Oct 2002 23:06:41 +0100

Dear all,

Best regards
Michael

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 29 Oct 2002 17:01:38 -0600

Hi, Michael,

Michael Tüxen wrote:
> 
> Dear all,
> 
> I was thinking about the the multicast related procedure in ENRP. Even if we

The new server will not wait. Instead, it will announce its presence by
multicasting a PEER_PRESENCE with "reply-required" flag set. when other
servers see this msg and flag they will send back a p-to-p PEER_PRESENCE
with server info. I remember this is what the latest draft says (or try
to say).

> new server, it will try to connect to it. Let us assume that we have N ENRP
> servers running. What happens if I send a PEER_PRESENCE message by using
> multicast and (spoofed) IP address A. Then all ENRP servers will try to setup an
> association with A. Or am I wrong? 

I think you are correct. If A is not an ENRP server, it most likely will
drop the messages. If you have a compromised network with a large N,
this indeed becomes an attack. But I hope N will not go beyond a few
dozens... 

> i think only a random delay between the reception of the

Yeah, that can be added as an implementor's note.

> 
> Another 'problem': In section 4.7 it is described that in case a PU finds
> a ENDPOINT_KEEP_ALIVE message. So the PU/PE will be a server? I thought
> that this check would be performed by the Home ENRP server of the PE in 
> question? AM I wrong?

We used to do that (i.e., only the home server of the PE is allowed to
ping the PE in question) many revisions back, but not any more. It takes
some complexity (and extra msgs if you check the old versions) to do
that and unless there is a compelling reason for that I suggest not to
do that again. 

> have fully meshed SCTP associations, or not? Or a some using the multicast
> stuff to replace that?

The idea is to have a partial mesh. In section 4, there are a lot of
details on how an enrp server tracks the m-cast capability of each of
its peers. When a server needs to send something to all peers, it will
m-cast the msg and at the same time send individual copies of the
message to peers that are not m-cast capable.

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 29 Oct 2002 17:01:38 -0600

Hi, Michael,

regards,
-Qiaobing