Subject: [Rserpool] Pool Element Identifier

From: Thomas Dreibholz <[email-masked]>
Date: Wed, 12 Jun 2002 13:57:49 +0200

Hi all,

some thoughts about the pool element identifier:
- - To simplify the implementation of the pool user's name resolution cache, it 
would be useful if the pool element identifier is network-unique. Since the 
pool identifier is already defined to be unique in the ENRP server's pool, 
the pool identifier sent to the pool user could be made network-unique by 
combining it with a network-unique ENRP identifier.
- - Behavior in case of ENRP server failure:
If the ENRP server fails, the pool elements registered by this server will 
recognise the failure, start a server hunt procedure and register at a new 
server. Therefore, their pool element identifier (combined with ENRP server 
ID) will change. Pool users having already used the PEs' services before the 
crash can continue to use the service since the PU<->PE connection has not 
failed. These PUs still see the PEs under their old IDs. New PUs will see the 
PEs under their new IDs. It is therefore necessary to ensure that new ID and 
old ID are different.
- - Idea to calculate a pool element identifier:
a = MAC address of first ethernet (or any other type having a unique ID) 
interface. (48 bits)
b = process ID of ASAP instance registering a pool element (e.g. 16 bits)
c = random number (e.g. 16 bits)
d = time stamp (microseconds since 16-Jun-2002, e.g. 64 bits). This ensures 
that new ID != old ID.
To ensure that the calculated bits cannot be used by an attacker (process ID, 
time stamp to attack an authentication mechanism, MAC for spoofing attacks, 
...), let the id be the hash value of the combination of a,b,c and d. 
Suitable algorithms are e.g. MD5 or SHA1. If the ID length should be limited, 
the id could be a selected amount of bits of the hash value.
The same ID calculation mechanism can be repeated at the ENRP server, the PE 
identifiers of the PEs in its pool are the combination of the ENRP server ID 
and the IDs calculated by the PE.
- - Necessary changes to ASAP:
* PE identifier should be a TLV.
* PEs register/deregister at the ENRP server using their PE-ID (without ENRP 
server ID).
* The ENRP server uses the full ID (ENRP server ID + PE-ID) in name 
resolution responses.

Best regards
- -- 
=======================================================================
 Dipl.-Inform. Thomas Dreibholz

 University of Essen,                            Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
- -----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org

=g36Q
- -----END PGP PUBLIC KEY BLOCK-----

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 12 Jun 2002 20:34:00 -0500

Hi, Thomas,

See my comments in-line...

Thomas Dreibholz wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> would be useful if the pool element identifier is network-unique. 

I see the contrary is happening (from you description below). You are
making the current simple "32-bit random number PE-ID" more complicated.
Please explain what benefit you are talking about here.

> Since the

What do you mean by "the pool identifier sent to the pool user"? It
should be the pool user (PU) that sends pool identifier (pool handle) to
the ENRP server when doing the query.

> server. 

This is not true. Normally PE does not perform a re-registration to
another ENRP server because the original ENRP server fails. PE only
attempts re-registration when it needs to, for example, update its
attributes (load value, etc.).

When a PE attempts to update its registration, no matter whether it
sends the reg to the original ENRP server or to another ENRP server, it
is _important_ to use the same PE-ID to identify itself, since otherwise
the server will consider it a different PE.

I will not comment on your following text since I don't think I
understand what you are trying to propose in general.

-Qiaobing

> Therefore, their pool element identifier (combined with ENRP server

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 12 Jun 2002 20:34:00 -0500

Hi, Thomas,

-Qiaobing

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Thu, 13 Jun 2002 08:21:17 -0500

Thomas Dreibholz <[email-masked]> writes:
> - - To simplify the implementation of the pool user's name
> resolution cache, it would be useful if the pool element identifier
> is network-unique. Since the pool identifier is already defined to
> be unique in the ENRP server's pool, the pool identifier sent to the
> pool user could be made network-unique by combining it with a
> network-unique ENRP identifier.

The consequences of a PE-ID conflict are that the first PE to register
with a given PE-ID may be excluded from the pool by the second PE to
register with the same PE-ID.  This is not that bad a consequence.

It's a waste of resources, so maybe we want to do something about it.

How often will this happen?  If we have a 32 bit PE-ID with uniform
random distribution, the odds of any particular two PE's conflicting
are 1:2^64.  If we allow for a pool size of 512 (2^9) the odds of a
conflict are about 1:2^(64-9) or 1:2^55 during the startup of a given
pool.

Let's further speculate that we've been very successfull and there are
roughly as many 512 element pools as humans, say 2^33.  Let's further
assume that everybody restarts their pools from scratch daily.

The daily odds of a conflict occurring somewhere on the planet are
1:2^(55-33) or 1:2^22 i.e. about 1:4,000,000.  Put differently, that's
once every 11,491 years.

Conflicts are easy to detect, so if folks think that those odds
justify the extra work, we can add a conflict detection mechanism.

Let's not overengineer this protocol.

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Thu, 13 Jun 2002 08:21:17 -0500

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 13 Jun 2002 19:04:09 +0200

Am Donnerstag, 13. Juni 2002 15:21 schrieb La Monte Henry Piggy Yarroll:

Hi,

see my comments in-line...

> random distribution, the odds of any particular two PE's conflicting

PE conflicts are no problem if uniform random distribution is assumed. But 
since the PE-ID is selected by the pool element itself, an attacker could try 
a DoS attack by registering with PE-IDs known to be already in the pool.

> Let's not overengineer this protocol.

A pool may consist of many different pool element programs. Even if all PEs 
have to authenticate before adding a pool element, the pool element 
implementation may contain security leaks allowing a malicious user to add 
conflicting PE-IDs.
Since the amount of ENRP servers is much smaller than the amount of pool 
elements, it may be a good idea to let the ENRP server select the PE 
identifier and return it to the pool element in the REGISTRATION_RESPONSE 
message. This would keep the protocol simple but make the PE-ID selection 
much more trustworthy.

Best regards
- -- 

=g36Q

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 13 Jun 2002 19:04:09 +0200

Hi,

Best regards
- -- 

=g36Q

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 13 Jun 2002 14:42:33 -0500

Hi, Thomas,

I agree with La Monte's view that a 32-bit random number PE-ID is
adequate (also, at the interim meeting a few weeks ago, the participants
reached the same conclusion).

I am also not convinced that, as you might have implied below, the
simple PE-ID opens up security holes. See my detailed comments in-line.

Thomas Dreibholz wrote:
....
> But

If the attacker already knows the PE-IDs in the pool and has access to
ENRP server, the attacker could simply de-register all the PEs. This
would be a much easier and more complete way of DoS, comparing to cause
conflicting PE-IDs in the pool. 

....
> implementation may contain security leaks allowing a malicious user to add

ditto. After succeeded in breaching the authentication, if the attacker
only wants to add conflicting PE-IDs, I would not call it "attacking", I
would probably call it "teasing" :-)

regards,
-Qiaobing

> mQGiBDr2cOgRBAC71Xhy1yzNTBxnousyxwtZ+zxRQJIfkDUQ8Yry5/rdoRkUldnE
> VQUNX9owxKKwA40DsKMX5lfPIgfPpefqnSOx1/XOtjpffkF8+FY8ncU/LKvHPPw3
> oNXzFAr8F6NqpJAIbp8eW6DlfraXiJFZk0D6sZyIk9XDqTY01+Dn5WmAewCg4Szj
> r52geHYk+6n83yfVqw8+c3MD/A9d4ylhJikTHzbL83HTO7WozqlGtZq0rwGY+JIq
> wPAaRAdBnu0brQz7xtfTZrvxA6v3sYb73bpuosaQNtg1K5Z0l0fbJQxls7wCdSC4
> GmkXyl64c1bPiGMHu7WVE85mwdm4KyD7qELnnNKZoagFgK1HNYFJtuUDYQ3ihBQq
> k0VnBACaqJ4k/VJYPQvuWy0fppX+Ultyqz2rrHqqVvaSotjc8muxwM0OL42ZCjL1
> scuFb1TonojymUFa1nqe6uYU5Owjh2CRfs5+TnMUO7S7vXQRQgWPffIE7kJqL46G
> S79MmHXVWwmO1WMpJooTlsCUv+J+pAWpYu5nJY4X/s+1DXSA9LQvVGhvbWFzIERy
> ZWliaG9seiA8ZHJlaWJoQGV4cC1tYXRoLnVuaS1lc3Nlbi5kZT6IVwQTEQIAFwUC
> OvZw6AULBwoDBAMVAwIDFgIBAheAAAoJEN9gW7B2Dy1l6BcAnRhM7hgy3qOLDKps
> qIY88XZaMjMqAKDHqpiM/8CFpti9TKeIP/mRbva/3rkCDQQ69nD8EAgApETE6wER
> FSA5YMQvoqNPYpf8W3y+u+BJvD2QMdKXFy79XnYCoOB26q0JK5gGw1GTB39ANOpc
> 3x5dkSNDiJptntB9DX7SEb1V+GU62XZOhju6o4GbLlhRsy40SVvzZ/RldkoYeCRH
> 1JghU7EkGsn8RcLuRFj7AgW+bWkIyC3NCGZN+mdc/mmRxYqeFpMQv2+Xnb1EuCk6
> jqDJL6IjVKueYZD5XtKXW+QAj1UlRo9vGpNLs7oZz3QahEgf0S5Cn9eLp2JRr94D
> FVoInZwziOWyEJ8BrJoydDgCAb/5eEdrAc+7ibuPSOnOxVH8ae9zyNbdimSJGDt1
> pnfEz/Cw3cYYvwADBwf/bV9iJO22zTJaB5Sz8dzbQfwaa55fugi7DvPOe5eiE1p9
> /W+uPJTYZ7WQxarM8q/h8BztwOAfeUKztzoGSVvEfxha8Wnvz/3rLWLK1Ok+v9ZV
> ElrAYmJbbEci1Lmk1vXwmjcYoojYl/25mhkvucg8zVO8WfNYCwBUkGUGUj+SQpbf
> xEt80dyGm6KFv9XO1fAzlUXkWBODZ4vDPNRY+Ay4evAFkbfKFgHXMUBvtXlGfuSQ
> pTRXNt0mfRVZ4OeeIKbPdCI8DX5ND9+cIWEQJ2APgWta+h61kwJ5c7k2xxabbYt6
> v9jTzPr57yvVle4fOV6ExUeCcFaRIzvX+87FMoac+YhGBBgRAgAGBQI69nD8AAoJ
> EN9gW7B2Dy1lPpwAnR3YQYZRN4WouZwLcGpfMfH2X5RVAKDCa7d6Hwhoa7DrPaTA
> P/965IPybA==
> =g36Q
> -----BEGIN PGP SIGNATURE-----
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE9CNCJ32BbsHYPLWURAq4ZAKC3E41bQmlULq9Ew5V2Js4yy4S/0wCgladp
> +g52dGR53eHKsgiQf5AN5uw=
> =Da9P
> -----END PGP SIGNATURE-----
>

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 13 Jun 2002 14:42:33 -0500

Hi, Thomas,

Thomas Dreibholz wrote:
....

....

regards,
-Qiaobing

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 13 Jun 2002 22:15:42 +0200

Dear all,

see my comment below.

Best regards
Michael

> a DoS attack by registering with PE-IDs known to be already in the pool.
 From the ASAP ID:

           R2.2) Fill in a PE identifier using a good quality randomly
                 generated number ([RFC1750] provides some information
                 on randomness guidelines).

So this IS a good random number. It is of the same quality we use for
SCTP to provide security against blind attacks.

> - 
> -----------------------------------------------------------------------
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 13 Jun 2002 22:15:42 +0200

Dear all,

see my comment below.

Best regards
Michael

 From the ASAP ID:

---

From: Thomas Dreibholz <[email-masked]>
Date: Fri, 14 Jun 2002 09:39:48 +0200

> SCTP to provide security against blind attacks.

It is not necessary to do blind attacks. The NAME_RESOLUTION_RESPONSE message 
returns Pool Element Parameters. As defined in 
draft-ietf-rserpool-common-param-00, the Pool Element Parameter includes the 
PE Identifier. Therefore, an attacker simply has to call NAME_RESOLUTION to 
ask an ENRP server for suitable PE Identifiers to start a DoS attack. 
Authentication is not a protection, since all pool users must have the 
permission to do name resoultions.

- -- 

=g36Q

---

From: Thomas Dreibholz <[email-masked]>
Date: Fri, 14 Jun 2002 09:39:48 +0200

- -- 

=g36Q

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 14 Jun 2002 08:04:01 -0500

[I presented an analysis that suggested it would be thousands of years
before we were likely to see a PE-ID conflict, a conflict that causes
a minor resource inefficiency.]

...
> message. This would keep the protocol simple but make the PE-ID selection 

I like this idea.  With essentially no additional overhead we can
completely eliminate the very low probability event of conflicting
PE-IDs.  I can administratively assign each ENRP server its own prefix
and it can assign PE-IDs out of that pool.

Hmm... that's not QUITE zero overhead.  But if the ENRP server assigns
the PE-ID I (as an RSERPOOL admin) COULD eliminate possible conflict
if I wanted to without any changes to the protocol.

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 14 Jun 2002 08:04:01 -0500

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 14 Jun 2002 11:32:21 -0500

La Monte Henry Piggy Yarroll wrote:
....
> and it can assign PE-IDs out of that pool.

Up to this point, ENRP server is designed to be totally auto-configured,
i.e., whenever you feel you'd like to start an additional ENRP server
anywhere in the op space, you simply start the executable and the server
will pick it server ID, find all existing peer, initialize its internal
database, etc...

With this proposed change, auto-config would become no longer possible.
To start a new server, you (the admin) would then need to have a prior
knowledge about all the existing servers (at least their IDs) in the
scope so that you would know how to pick a proper new server ID for the
new server. To get this knowledge, either you will have to use a server
ID distribution protocol or you need to maintain a central server ID
database (or repository)...

Therefore, I not only see added complexity, but the introduction of
potential single point of failure if we go down this route.

-Qiaobing

> >  Inst. for Experimental Mathematics              Ellernstra?e 29

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 14 Jun 2002 11:32:21 -0500

-Qiaobing