Re: Pool Handle Translation in draft-ietf-rserpool-enrp-06.txt

Thomas Dreibholz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Dienstag, 23. September 2003 00:18 schrieb Qiaobing Xie:
> > 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;
>
> 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.
>

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

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

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.

>
> > 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.
>
> 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?

I think this change is acceptable.

regards,
-Qiaobing

>
>
> 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 protected]
>  Homepage:   http://www.exp-math.uni-essen.de/~dreibh
> =======================================================================
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE/cAVC32BbsHYPLWURAvF2AJ9vwr4P6KACBmfd+GF4MxxDLfFzywCdHZHD
> FXn89NT4UVVehvOLcf8dlM4=
> =SB1H
> -----END PGP SIGNATURE-----