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

[Fernando Gont <[e-mail]>]

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 <[e-mail]> 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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492