Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT)

["C. M. Heard" <[e-mail]>]

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