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. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
