Ted, Please let me describe a scenario for an attack that would work if we don't enforce the filtering rules from the current version of the I-D.
Before getting into the specific details, please let me provide some background. ** Background ** * As have been noted multiple times, IPv6 Extension Headers and Transport Protocols share the same name space. Given an unrecognized/unknown EH/Protocol type, there's no way for you to know how to parse it: since it could be ether an EH, or a transport protocol. * RFC6564 has a major flaw, since it defines a "unified format for EHs". But per the above, it is impossible to tell when you should assume that what follows is an EH (in RFC6564 format) or a new transport protocol. * There's nothing that we can do to fix RFC6564 itself in this respect. The only possible option is to replace RFC6564 with something such as: <https://tools.ietf.org/id/draft-gont-6man-rfc6564bis-00.txt>. Regardless of whether the IETF decides to fix this problem or not, the problem is there. * If you assume that an unrecognized header follows the format in RFC6564, you will hurt the deployment of new transport protocols. * RFC7045 is the current IETF advice on the topic. DHCPv6 shield complies with it -- as noted a few times... even by Brian Carpenter (co-author of the aforementioned document). If you disagree with what DHCPv6-shield is currently doing, you're essentially disagreeing with 6man's advice on the topic. ** Attack scenario ** 1) Let us assume that either a new EH that doesn't follow RFC6564 is specified (since, as noted, RFC6564 doesn't buy you anything), or that the proposal in draft-gont-6man-rfc6564bis-00 gets standardized, and hence new EHs follow the EH format in that document. 2) Such EH, according to the rules you had proposed (namely "assume RFC6564 for unrecognized headers"), would be passed/allowed, since it would be considered a "transport protocol" rather than an EH. 3) Now, let us assume that such EH has been implemented by a target host. An attacker could send a DHCPv6-server packet with includes one of the aforementioned EHs. The DHCPv6-shiled device would (according to your rules) pass this packet, and the target host would receive it. 4) As a result of the above, an attacker would have been able to sneak a DHCPv6-server packet past the DHCPv6 shield device. This is an attack vector we mean to block. The current version of DHCPv6-shield would block it. If we were to modify the document as you suggest, it wouldn't. Thanks, Fernando On 02/09/2015 01:44 PM, Ted Lemon wrote: > On Feb 9, 2015, at 11:11 AM, C. M. Heard <[email protected]> wrote: >> As I argue in >> http://www.ietf.org/mail-archive/web/opsec/current/msg01817.html, >> the switch opens itself up to DOS attacks if it assumes that any >> unknown header in the chain conforms to RFC 6564 and attempts to >> continue parsing the header chain. > > Yes, you made this argument. But how does this constitute a DoS attack? > You have a 1500 byte packet, and you have some kind of fast-path hardware > that's trying to parse the packet. At some point it will either succeed or > fail. Most such hardware doesn't even look very far into the packet--maybe > 256 bytes at most. > > I asked you earlier in this conversation to describe a specific attack, not > make general speculations. Can you describe a specific attack here and > explain why it is bad? Remember that we are specifically talking about > filtering DHCPv6 here, not solving the general problem of eliminating > possibly bogus packets at the switching fabric so that hosts don't see them. > > Remember too that the packet has to actually be _valid_ when it's forwarded > to the host: it's not sufficient that it simply make it through the filter. > Otherwise the host will not see it as a DHCPv6 packet, and the shield will > have succeeded even though it passed the packet. So the packet has to use a > valid chain of extension headers that the host can successfully parse, even > if they are unknown to the switch. > > Can you describe an attack that works in the presence of all these > requirements? > -- 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
