On Mon, 9 Feb 2015, joel jaeggli wrote:
> On 2/9/15 7:09 PM, Ted Lemon wrote:
> > 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?
Allow me to point out that a device that is unable to parse the entire
IPv6 header chain is not compliant with the draft as now written:
1. DHCPv6-Shield MUST parse the entire IPv6 header chain present in
the packet, to identify whether it is a DHCPv6 packet meant for a
DHCPv6 client (i.e., a DHCPv6-server message).
RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a
limit on the number of bytes they can inspect (starting from
the beginning of the IPv6 packet), since this could introduce
false-negatives: DHCP6-server packets received on ports not
allowed to receive such packets could be allowed simply
because the DHCPv6-Shield device does not parse the entire
IPv6 header chain present in the packet.
The implication is that if the header chain exceeds the size that
can be looked at with fast-path logic, the packet would need to be
kicked onto a slow path -- where the potential DoS exposure that
I've pointed out would very likely be a real problem.
//cmh
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
