On 2/9/15 7:09 PM, Ted Lemon wrote: > On Feb 9, 2015, at 9:51 PM, C. M. Heard <[email protected]> wrote: >> If I counted correctly, this "packet" uses all 110 unassigned >> protocol numbers (aka next header values). It would be easy to >> include more or fewer headers. Or make the last header length >> point outside the packet. >> >> Note that this is not an attack on the destination host. The >> destination host should drop the packet immediately upon >> encountering an unknown next header value. Rather, it is an attack >> on the DHCPv6-Shield engine, which has to do a lot of work to >> figure out what to do with this packet. Is a typical >> implementation robust enough to deal with a line-rate stream of >> stuff like this? Do implementations with hardware accelerators >> (and limited header memory) suffer no adverse effects at all? What >> do they do if the header chain won't fit? I'm sure the effects >> vary greatly, but is is really true that this attack is nothing to >> worry about? > > I think what will happen in practice is that there will be some > fast-path logic that looks at the first 256 bytes of the packet at > most, and probably discards it if it can't be made sense of by the > end of those 256 bytes. I am completely okay with that. What I am > not okay with is advocating this behavior in a BCP.
We do ourselves and the community a disservice when we fail to include discussion of operational divergence from expected behavior. if whe can find a position that falls short of advocacy where does that leave us? > AFAIK existing implementations of DHCPv6-shield already do this. Yeah exactly. > _______________________________________________ OPSEC mailing list > [email protected] https://www.ietf.org/mailman/listinfo/opsec >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
