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: Tuexen Michael <[email-masked]>
Date: Fri, 14 Jun 2002 09:49:43 +0200

Thomas,

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: Thomas Dreibholz [mailto:[email-masked]]
> Sent: Friday, June 14, 2002 9:40 AM
> To: Michael Tuexen; Thomas Dreibholz
> Cc: [email-masked]
> Subject: Re: [Rserpool] Pool Element Identifier
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Donnerstag, 13. Juni 2002 22:15 schrieb Michael Tuexen:
> > Dear all,
> >
> > see my comment below.
> >
> > Best regards
> > Michael
> >
> > On Thursday, June 13, 2002, at 07:04 PM, Thomas Dreibholz wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Am Donnerstag, 13. Juni 2002 15:21 schrieb La Monte Henry 
> Piggy Yarroll:
> > >
> > > Hi,
> > >
> > > see my comments in-line...
> > >
> > >> Thomas Dreibholz <[email-masked]> writes:
> > >>> Hash: SHA1
> > >>>
> > >>> Hi all,
> > >>>
> > >>> - - 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
> > >
> > > 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.
> >
> >  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.
> 
> 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.
> 
I only was saying that this random number generator is good.
It is used in SCTP for preventing bind attacks. I'm not talking about
RSerPool, only about the quality of the random numbers.

The other point is that after a PU has been authorized we assume
that the PU does not do a DOS. If it does, you know which administrator
to contact... 
> 
> > >> 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.
> > >
> > > 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
> > > - --
> > > 
> > > -
> --------------------------------------------------------------
> ---------
> > > 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-----
> > >
> > [email-masked]
> 
> - -- 
> - 
> --------------------------------------------------------------
> ---------
> 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
> 
> iD8DBQE9CZ3H32BbsHYPLWURAltxAJsG5wULRp9BjGPjCTnXqF4bMCXxNwCfQtDW
> TduL/owKaAGLBLTe4VDMpXs=
> =Hwpj
> -----END PGP SIGNATURE-----
>

---

From: Tuexen Michael <[email-masked]>
Date: Fri, 14 Jun 2002 09:49:43 +0200

Thomas,

see my comments below.

Best regards
Michael