Subject: [Rserpool] Pool Handle Translation in draft-ietf-rserpool-enrp-06.txt

From: Thomas Dreibholz <[email-masked]>
Date: Mon, 22 Sep 2003 16:20:27 +0200

Hi all,

a comment on section 4.5 of the ENRP draft:
"In the response message, the ENRP server MUST list all the PEs currently 
registered in this pool, in a list of PE parameters."

It is not a good idea to list all PEs currently registered in the pool: The 
NAME_RESOLUTION_RESPONSE message as defined in 2.2.6 of the ASAP draft 
version 07 has no "More Data" flag or something like this. Since the length 
field is limited to 16 bits, the amount of PEs in a pool would be limited by 
the size of the resulting NAME_RESOLUTION_RESPONSE message.

What about replacing the sentence in section 4.5 by "In the response message, 
the ENRP server MUST list an appropriate subset of the PEs currently 
registered in this pool, in a list of PE parameters."

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

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

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 22 Sep 2003 17:18:31 -0500

Hi, Thomas,

To add a "more data" flag to NAME_RESOLUTION_RESPONSE will add
complexity to the implementation and add significant delay to ENRP query
responses when the flag is used. To allow the use of "an appropriate
subset of PEs" will raise the question (and ambiguity) of "what is the
appropriate subset of PEs", and will break the load sharing mechanism,
and may potentially cause inter-op problems. IMO, either change above
would need a very strong justification to make.

Let's do a little calculation to see how big the problem you mentioned
is.

With 16 bit length field, you are allowed to have a 64k byte size
response msg.

a) if each PE in the pool is of SCTP type with dual-homed IPv6
interfaces, a PE param TLV would take 72 bytes, and you would be able to
comfortably fit about 900 PEs in a response;

b) if each PE is of SCTP type with triple-homed IPv6, a PE TLV would
take 92 bytes and you would be able to have >700 PEs.

For IPv4 or transport type other than SCTP, you could easily get >1000
PEs in a single response message. 

We talked about RSERPOOL scalability issues a long time ago and I
remember our consensus was to be able to support pool size in the range
of no more than 150~200 PEs as our requirement.

So I am not convinced that the message size limit here is causing a
problem for us.

regards,
-Qiaobing

Thomas Dreibholz wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/bwUr32BbsHYPLWURAmwMAKCGGL/hE+mOE4hLej/X/0TPBQY9HwCgiBkS
> jKGiwkpAyltbhAWuzhaC6E8=
> =yJ3T
> -----END PGP SIGNATURE-----
>

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 22 Sep 2003 17:18:31 -0500

Hi, Thomas,

regards,
-Qiaobing

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 23 Sep 2003 10:33:06 +0200

> comfortably fit about 900 PEs in a response;

But what happens when some PEs register e.g. with 100 IPv6 addresses or more. 
This can cause a denial of service! Another way to cause a denial of service 
would be to fill up the pool with registrations until a 64K response msg is 
reached. 

> PEs in a single response message.

Replying many PEs in a single response message is also quite inefficient. 
Consider a PU connected to the Internet via a 28800 baud modem. Transfering a 
64 KBytes chunk takes more than 20 seconds. Via GSM or GPRS, this would not 
only be slow but also very, very expensive.  And usually, it can be expected 
that the PU gets connected to a PE after trying very few PE addresses. Since 
the PEs in the PU's local cache also time out, transfering many PEs does not 
make sense.

> So I am not convinced that the message size limit here is causing a

Well, most pools will probably not exceed a 64K size limit. But the protocol 
design should not build such a limit in. May be, in some years this will 
become a problem. What about "In the response message, the ENRP server 
*SHOULD* list all the PEs currently registered in this pool, in a list of PE 
parameters." instead of MUST?

Best regards
- --

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 23 Sep 2003 10:33:06 +0200

Best regards
- --

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 26 Sep 2003 15:50:20 -0500

> would be to fill up the pool with registrations until a 64K response msg is

I wouldn't be worried about this scenario since this won't happen unless you
assume that the bad guy has already broken the security (either IPsec or TLS). IF
the bad guy has already broken the security, he/she can do a number of far
nastier attacks than what you described above...

> the PEs in the PU's local cache also time out, transfering many PEs does not

I am not sure about anyone would deploy RSERPOOL directly over PUs connected by
low speed dial-up. But if it is the case, this is a legitimate concern. One could
argue that this case is on the edge of what RSERPOOL is intended to be used.

> parameters." instead of MUST?

I think this change is acceptable.

regards,
-Qiaobing

> iD8DBQE/cAVC32BbsHYPLWURAvF2AJ9vwr4P6KACBmfd+GF4MxxDLfFzywCdHZHD
> FXn89NT4UVVehvOLcf8dlM4=
> =SB1H

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 26 Sep 2003 15:50:20 -0500

regards,
-Qiaobing