On 02/08/2015 04:24 PM, Ted Lemon wrote: > On Feb 8, 2015, at 1:47 PM, C. M. Heard <[email protected]> wrote: >> It is not necessarily true that an unknown upper layer protocol >> header will look like a malformed extension header to a device that >> assumes it is an extension header following the format in RFC >> 6564. If the value of the 2nd octet of the unknown header is v, >> then it won't appear malformed if at least 8*(v+1) bytes remain in >> the packet, starting from the beginning of the unknown header. At >> that point the device would be interpreting the payload of the >> unknown upper layer PDU as an extension header chain. In the >> benign case where the packet is a legitimate one with an upper >> layer protocol unknown to the device, it is likely (but not >> assured) that the chain would quickly terminate in something that >> looks like a malformed extension header. However, it would not be >> difficult to craft a packet that makes a very long apparent header >> chain. Depending on how the device processes header chains, that >> could easily be a vector for DOS attacks -- e.g., by consuming >> processing resources or by exercising a rarely used processing >> path. That is why I think it is UNSAFE to continue processing a >> header chain after encountering an unknown next header value. > > This may or may not be true, but to the extent that it's true, it's > already addressed in RFC 7045, and it's addressed correctly there. > There is no need to strengthen the advice in RFC 7045 here, which > this document currently does
Why do you think this document "strengthens the advice in RFC7045", as opposed to it actually *complying* with what's in RFC7045? Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
