On 5/31/2011 11:19 AM, Hannes Gredler wrote:
On Tue, May 31, 2011 at 10:56:52AM -0700, Joe Touch wrote:
|
|
| On 5/31/2011 10:52 AM, Paul Hoffman wrote:
|>On May 31, 2011, at 10:23 AM, Randy Bush wrote:
|>
|>>>1. Maybe add to section 5.9 "An Error Report PDU MUST NOT be sent for
|>>>an Error Report PDU.".
|>>
|>>makes sense
|>>
|>>>To answer the initial request, it seems reasonable to specify "the
|>>>length of the Arbitrary Text of Error Diagnostic Message MUST NOT be
|>>>longer than 200 octets". That keeps the length of the entire PDU under
|>>>the semi-magic 256 octets for the current version of the protocol
|>>
|>>in what way is 256 octets semi-magic?
|>
|>C or assembly-based implementations will need to malloc (etc.) the
|>buffer for the incoming message. Having that fit into 256 octets could
|>easily have some value to some implementations. There is no security
|>problem if the cache ignores such a MUST and makes the message longer
|>because the length is given the PDU. (Having said that, I hope router
|>implementers of this protocol are being robust in checking the lengths
|>in this PDU; I can already see ways to craft malicious versions of this
|>PDU that might trigger a buffer overflow...)
|
| These are good reasons for robust implementations to check for the
| message length and read only as much as the currently allocated
| buffer allows, reading more in as needed.
wonder what the normative procedure is for "too-large" messages ?
my pre-standard implementation has an inbound buffer of 4K
and resets the session if it encounters a PDU length of> 4K.
That makes an easy DOS attack.
It's better to:
- allocate a 4K (or whatever value you want) buffer
- read up to the first 4K
- check to see if there's more to read, and allocate more buffer space
or read it into the first buffer (after the first 4K has been parsed)
Either way, there's no reason for a *protocol action* to deal with a
receiver buffering issue.
Joe
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
