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

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 27 Sep 2002 14:50:35 -0700

Dear Randy, Qiaobing,

see my comments below. However one remark: I tried to
use the cvs diff command to find quickly Qiaobings changes.
What I found was that the whole document (every line) was changed.
The cvs diff is correct, the doc has now DOS line endings. After
I have made my changes I will check it in with UNIX one again. Or
should I try MacOS ones? Just kidding. 

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: Friday, September 27, 2002 2:48 PM
> To: Qiaobing Xie
> Cc: Thomas Dreibholz; [email-masked]
> Subject: Re: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt
> 
> 
> Qiaobing Xie wrote:
> > Hi, Thomas,
> > 
> > Sorry for the late response, both Randy and myself were 
> taking vacation. Pls see
> > my comments in-line..
> > 
> and overworked in other areas :-<
> 
> 
> > Thomas Dreibholz wrote:
> > ...
> > 
> >>some comments on draft-ietf-rserpool-asap-04.txt:
> >>
> >>- - DEREGISTRATION_RESPONSE:
> >>The "Pool Element Parameter" field must be optional, since 
> the nameserver
> >>cannot generate this field if the pool element identified 
> by Pool Handle
> >>Parameter and PE Identifier Parameter in a DEREGISTRATION 
> message is not
> >>existing in the namespace.
> >>There should also be an error code (e.g. 7) for "Pool 
> Element not found".
> > 
> > 
> > Agreed. In fact, I'd suggest to replace the PE TLV with a 
> PE Identifier TLV in
> > both reg and de-reg responses. Building the PE TLV again 
> from parsed attributes
> > when sending the response is really a pain, while simply 
> mirroring the original PE
> > TLV back does not seem to serve any purpose. 
> >  
> 
> I agree too
> 
> > 
> >>- - There must be an error message type for the case of an 
> unknown message type
> >>is received. For example, a client sends a message type 0xab to the
> >>nameserver. This type is unknown, therefore an error should 
> be returned.
> >>Suggestion:
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++
> >>++++ Type = 0xff | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Message 
> Length +++++
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++
> >>++++ Error Parameter                                        
>       +++++
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++
> > 
> > 
> > A PEER_ERROR message is defined in ENRP v04 already. 
> Probably the same needs to be
> > done for ASAP. Since ENRP and ASAP are on different paths, 
> they need to define
> > their error message separately.
> > 
> 
> Either that or more fodder for the common parameters document...
> 
A error cause is already available in the Common Parameter doc.
I will commit text for that and also for the error causes of
the common parameter doc.
> > 
> >>- - NAME_RESOLUTION_RESPONSE, ENDPOINT_KEEP_ALIVE_ACK, COOKIE_ECHO,
> >>SERVER_HUNT_RESPONSE must contain an optional "Operational 
> Error" parameter.
> > 
> > 
> > Sounds reasonable. In addition, with 
> NAME_RESOLUTION_RESPONSE + Op Error, we
> > probably can remove NAME_UNKNOWN.
> > 
> 
> True.. sounds good
> 
> > 
> >>- - There should be the pool policies "Random" and 
> "Weighted Random":
> >>Random:
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++
> >>++++ Param Type = 0x6             | Length = 8              
>       +++++
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++
> >>++++ Policy Type = 0x5 | Weight                             
>       +++++
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++
> > 
> > 
> > this makes sense and is straightforward to add.
> > 
> > 
> >>Weighted Random:
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++
> >>++++ Param Type = 0x6             | Length = 8              
>       +++++
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 27 Sep 2002 14:49:53 -0700

Dear Randy, Qiaobing,

my DSL access is not working at the moment, I'm using a modem. So
I might not check e-mail very ofter this weekend.

See my comments below.
Best regards
Michael

On Friday, Sep 27, 2002, at 20:07 Europe/Berlin, Qiaobing Xie wrote:

> Hi, Michael,
> Tuexen Michael wrote:
> This is due to that I used emacs, diff, and cvs from my Windows side 
> and I forgot
> to 'vi' those new lines out before committing the files. Will remember 
> that next
> time :-)
>
No problem.
>>>> they need to define their error message separately.
>>>
> Thomas and I meant to say that we also need a stand-alone op error 
> *message* on
> both asap and enrp side. I'd prefer to have separate ERROR msgs since 
> asap and
> enrp are using separate msg type space now. We can still make the msg 
> type value
> common btw them, e.g., we can, for both enrp and asap, define 
> msg-type=0xfe as Op
> Error (assuming we still reserve 0xff for ietf extension).
>
> I've already have this defined in ENRP v04 (but msg type is not 0xfe 
> yet). I can
> make the change to asap if this sounds ok.
>
I put that in the ASAP ID some minutes ago. And also specified the
unrec message/parameter error cause in the common parameter ID.
> I've added op error TLV to NAME_RESOLUTION_RESPONSE, but not to 
> others. I can make
> these changes to the asap xml, too.
>
> ...
>>>>> - - There should be the pool policies "Random" and "Weighted 
>>>>> Random":
> ....
>>>> more justification may be needed for this one. Seems quite
>>>> computation intensive to match a distribution function.
>>>>
>>> Well probably one could call the 'least used' a weighted distribution
>>> since you are really talking that the weight is what the least used
>>> is looking at :>
>
> At this point I'd suggest that we do not add any more load policies to 
> the base
> asap draft. If there is the need to define some different policies 
> right now, it'd
> be better to put them in a separate draft(s). That way, it would be 
> easier for us
> to discuss and refine the policies without interfering with the 
> progress of the
> asap draft, and we could avoid adding more text "load" to the base 
> asap draft :-)
>
I agree with that.
> ...
>>>>
>>>>> - - SERVER_HUNT_RESPONSE should contain at least one Server
>>> Information
>>>>> Parameter. This is useful for 2 reasons:
>>>>> 1. The nameserver may use a port different from the
>>> well-known nameserver
>>>>> port.
>>>>> 2. The nameserver may support SCTP and TCP or SCTP only;
>>> some pool users may
>>>>> only support TCP and therefore are only interested in
>>> TCP-capable nameservers.
>>>>
>>>> I am not sure about this one. I guess I don't quite see
>>> your scenario here. If a
>>>> nameserver is listening on a different ASAP port and the PE
>>> is doing the hunt by
>>>> the well-known port, the server will never receive the
>>> server_hunt in the first
>>>> place. If the server is responding, then it means that the
>>> PE did the hunt on the
>>>> right port.

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 27 Sep 2002 14:50:35 -0700

Dear Randy, Qiaobing,

Best regards
Michael

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 27 Sep 2002 14:49:53 -0700

Dear Randy, Qiaobing,

See my comments below.
Best regards
Michael

No problem.
I agree with that.

---

From: Tuexen Michael <[email-masked]>
Date: Mon, 30 Sep 2002 15:26:22 +0200

Dear all,
see my comments below.
Best regards
Michael

> Sent: Monday, September 30, 2002 2:23 PM
> To: Thomas Dreibholz
> Cc: Michael Tuexen; Qiaobing Xie; Tuexen Michael; Thomas Dreibholz;
> [email-masked]
> > 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)
>

---

From: Tuexen Michael <[email-masked]>
Date: Mon, 30 Sep 2002 15:26:22 +0200

Dear all,
see my comments below.
Best regards
Michael

So the situation is:

---

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

> From: Tuexen Michael 
> Sent: Monday, September 30, 2002 3:26 PM
> To: 'Randall Stewart'; Thomas Dreibholz
> Subject: RE: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt
> 
> 
> Dear all,
> see my comments below.
> Best regards
> Michael
>