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, and indeed this is completely unrelated to the supposed purpose of the document, which is to prevent DHCP packets sent by unauthorized servers from reaching clients. If indeed RFC 7045 is too weak and needs to be strengthened, the place to do that is in 6man, not in opsec. Fernando tried to do that in 6man and got no traction. If we were to allow that to be done here, it would effectively be an end-run around the 6man working group. _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
