On Sun, 8 Feb 2015, Ted Lemon wrote:
> 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.
...
> 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.
Would your objections be addressed if Section 3 of the draft were
replaced by something along the lines of the following?
=============================== cut here ===============================
3. When parsing the IPv6 header chain, if the packet contains an
unrecognized Next Header value, DHCPv6-Shield MUST be configurable
to pass the packet. The default configuration MAY drop such packets.
When such a packet is dropped, DHCPv6-Shield SHOULD log the packet
drop event in an implementation-specific manner as a security alert.
RATIONALE: An unrecognized Next Header value could possibly
identify an IPv6 Extension Header, and thus be leveraged to
conceal a DHCPv6-server packet that should be dropped, or it
may identify an unrecognized upper layer protocol, which
should be passed. There is no reliable way to tell the
difference. The advice given here is consistent with the
requirements levied by [RFC7045] on forwarding nodes with
respect to handling of unrecognized extension headers.
4. When parsing the IPv6 header chain, if the packet is identified
to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield MUST
drop the packet, and SHOULD log the packet drop event in an
implementation-specific manner as a security alert.
=============================== cut here ===============================
//cmh
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
