Re: Length of Reason String

[asbjorn.rrp@theglobalname.org]

I agree,

but back to the length of the "reason string". The longest current status enum
is 24 characters, so that must be the bare minimum, in my view.


Asbjorn


On Tue, 25 Sep 2001 23:17:35 -0400 Daniel Manley <dmanley@tucows.com> wrote:
>I'm thinking that DoS attacks shouldn't be much of a concern in EPP 
>since registrar authentication is required.  At least in the world of 
>domain name registrations, ICANN would certainly have something to say 
>to registrars that attempt DoS attacks on registries.
>
>But in non-domain domains, things might be a little different.
>
>Dan
>
>Hollenbeck, Scott wrote:
>
>>>-----Original Message-----
>>>From: budi@alliance.globalnetlink.com
>>>[mailto:budi@alliance.globalnetlink.com]
>>>Sent: Tuesday, September 25, 2001 9:59 PM
>>>To: ietf-provreg@cafax.se
>>>Subject: RE: Length of Reason String
>>>
>>>
>>>On 25 Sep 01, at 20:16, Hollenbeck, Scott wrote:
>>>
>>>>I don't see the relation to sloppy coding or DoS attacks.
>>>>
>>>Hi Scott,
>>>I don't mean to say that we shouldn't use strings.
>>>And of course we should limit the length.
>>>(or shouldn't we?)
>>>
>>>It's just sloppy coding in the implementation can results in
>>>DoS attack (depends on the implementation of course).
>>>For example if we limit the length of reason string to 16 chars.
>>>Then, I create a nasty server which sends 10.000 chars, eg
>>>
>>>- this-is-a-very-long-rely-beyond-32-characters-and-i-am-going-to-see-
>>>which-implementation-crashes-or-give-me-access-to-their-workstation-
>>>wha-ha-haAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
>>>
>>
>>Actually, these sorts of long strings will/should get caught and flagged as
>>errors by the XML parser before they get too far.  Buffer overflow might be
>>a problem with a buggy parser, so I see what you're saying.  It's a risk
>>with strings.
>>
>><Scott/>
>>
>
>
>
>


-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.