Re: [OPSEC] Thoughts on draft-gont-opsec-ipv6-firewall-reqs

[Fernando Gont <[e-mail]>]

Hi, Fred,

Thanks so much for your feedback! (and thanks for taking the time to
write down such a detailed review!) -- Please find (some of) my
comments in-line...


On 04/18/2014 08:38 PM, Fred Baker (fred) wrote:
> 
> First comment: I’d appreciate it if we had a framework for the 
> discussion of this, RFC 6092, 
> draft-hutton-rtcweb-nat-firewall-considerations, 
> draft-jab-host-firewalls, draft-ietf-v6ops-balanced-ipv6-security, 
> draft-vyncke-advanced-ipv6-security, and a long list of other
> drafts with the name “firewall” in them.

Could you elaborate what (specifically) you have in mind?



> Second comment: I think this draft is not about an IPv6 firewall,
> and as currently structured is likely to take approximately forever
> to discuss, and will then be wrong. Let me throw out a thought 
> experiment: consider REQ SPC-70. This is listed as an “IPv6”
> firewall feature, but it requires “stateful” association of ICMPv6
> replies to TCP, UDP, and ICMPv6 sessions - it doesn’t mention IPv6,
> and apart from the ICMPv6 part, would be substantively the same if
> we were to suddenly decide to deploy CATNIP or TUBA.

Not sure what you mean. Clearly, an IPv6 firewall does not deal only
with IPv6, but with whatever is on top of it 8at least the transport
layer). In this particular case, the intent is that, if you allow,
say, outgoing tcp segments destined to port 80, you should also allow
the corresponding (ICMPv6) control messages.


> Why are these not a separate document that such a deployment could
> refer to?

You mean e.g., a document that just focuses on the IPv6 packet
filtering details? -- If so, I can agree with you.


> I can build that product on an enterprise scale if you can afford
> it, but you’re talking about some serious state in the network, far
> beyond what firewalls do today.

FWIW, here we're assuming that you're doing stateful filtering -- so
the state is already there.



> I’m join to suggest that this be broken up into a number of 
> separately-discussable documents, each of which defines a test 
> target. If I build a product and claim that it firewalls IPv6,
> what are the requirements of that product? If I build a product
> (perhaps the same product) that claims to firewall TCP sessions,
> what are the requirements for that product?

I'd have no issues with that. I'd say that it makes perfect sense to
move "how to filter X protocol" into a different document.. although
I'm not sure if I'd do "one protocol per document" (me, I wouldn't
mind, but then there are folks that claim about multiple small
documents..)


>> 2.  Introduction
>> 
>> While the IETF has published a large number of documents 
>> discussing IP and IPv6 packet filtering (see e.g. [RFC7126] and 
>> some documents on the topic of IP firewalls (see e.g. [RFC2979]
>> and [RFC3511]), concrete requirements for IP firewalls have never
>> been specified in the RFC series.
> 
> Except in RFC 6092.

[fwiw, point noted]



[....]
> And at first blush, I’ll bet the requirements for an IPv6 firewall 
> are almost identical to those of an IPv4 firewall. Reason? The 
> attacks are the same, and the security policies are the same. If a 
> smurf can run on IPv4, it can run on IPv6. Amplification attacks, 
> spoofed source address issues, and so on and so forth, are likely
> to be identical, because in a certain sense IPv6 is IPv4 with
> bigger addresses, and the transports and applications use the two 
> interchangeably.

I agree that the functional requirements will be very similar to those
of IPv4. But the problem is that it is not unusual to find that there
is no such parity of features between the two protocols (given the
same device).


> The one place that the IETF would *like* security policy to differ
> is that a to of security practitioners bought, hook line and
> sinker, the circa-1995 marketing that a NAT was a security
> technology; it’s not, it’s an address multiplexing technology, and
> produces a certain kind of firewall-like capability as an
> accidental side-effect, but a lot of corporate security policies
> star with “you put your NAT here”, and then stop.

Agreed.



>> REQ GEN-10: All features of the firewall MUST be able to be 
>> individually configured (at least ON or OFF, with other 
>> configurable parameters as applicable).  A well-documented
>> default initial setting must be provided for each feature.
> 
>> REQ GEN-20: MUST support basic Access Control Lists (ACLs).
> 
> Define a “basic” access list?

Will do.



>> REQ GEN-30: MUST support stateless packet inspection and
>> filtering at transport layer.
> 
> The transport layer is not IPv6. This belongs in a 
> transport-layer-specific firewall specification, as it will be 
> portable to IPv4, IPv7, and IPv9 firewalls that use the same 
> transport.

Sort of. There's interaction between e.g. ICMPv6 and the transport
layer. -- for instance, if you require the fw to perform e.g. TCP
checksum validation, it won't be "IP-agnostic".

I'd also say that basic packet filtering capabilities imply the
ability to do this sort of stateful filtering.



>> REQ GEN-60: MUST be able to enforce timeouts on protocol
>> sessions based on the upper-layer protocol (e.g. enforce a
>> timeout on the FIN-WAIT state for TCP connections, a timeout for
>> DNS query/respose pair, etc.). In general, it MUST have different
>> timeout parameters and thresholds to be used to prevent idle
>> sessions from exhausting resources on the device and/or the
>> service that is defended.  For sessions composed of multiple
>> packets (such as TCP connections), the exchange of valid packets
>> MUST refresh the timers employed for enforcing the aforementioned
>> timeouts.
>> 
>> NOTE: This is to avoid the known and buggy behavior where
>> firewalls enforce a maximum lifetime for the protocol session
>> (e.g. TCP connection) regardless of whether there is ongoing
>> exchange of legitimate packets for such session.
> 
> This also forces certain behaviors, such as TCP keep-alives, to be 
> used, which means that host applications that don’t currently use 
> them to be changed before they can be used in the context of this 
> firewall.

Agreed.




>> REQ GEN-80: MUST be able to redirect specific traffic to a proxy 
>> server e.g. for HTTP/S protocols.
>> 
>> NOTE: "Redirection means that the firewall should be able to
>> divert the traffic to a proxy - i.e., take the traffic, send it
>> to an inspection engine, receive it back and forward it (all
>> this completely transparent to the users).
> 
> This can be complicated. if I am redirecting DNS to a local
> server, for example, I need the server to be able to accept a
> packet as “to it” regardless of its destination address, and
> respond as if it were that system. If it is http/https, I’d
> actually rather have this built into routing somehow - instead of
> all of the traffic going through the firewall to the proxy, and
> routing deliver it to the proxy in the first place.

FWIW, this req is based on a commonly supported firewall feature.




>> REQ GEN-90: MUST be able to detect and reject invalid source or 
>> destination addresses (e.g. local-link addresses that try to 
>> traverse the firewall) with a single policy.
> 
> Again, a general router requirement. Any router needs to be able
> to generate an ICMP Destination Unreachable for any of the seven
> valid codes if appropriate. That includes validating source address
> scope.

Agreed. Question: are you implying that we should remove this
requirement? Something else?



>> 5.  IPv6-Specific Features
>> 
>> REQ SPC-10: MUST be able to filter ICMPv6 [RFC4443] traffic at a 
>> message type/ code granularity.  [RFC4890] MUST be employed for
>> the default filtering configuration.
> 
> ICMPv6 is not IPv6. This belongs in an ICMPv6-specific firewall 
> specification. It’s OK to make a requirement of the IPv6 firewall 
> specification that it also implement the ICMPv6 specification.

I'm fine with, say, putting the filtering details in separate
documents. But I'd disagree that ICMPv6 is not IPv6. Or, well.. that
depends on what what means by "IPv6". If one means "IPv6 protocol
suite", then ICMPv6 is definitely a part of it (that's what we mean here).



>> REQ SPC-20: MUST be able to block packets containing any
>> specified extension header type (based on its Next Header value),
>> on a specified number of instances of a specified extension
>> header type, and on a specified overall number of IPv6 extension
>> headers.
>> 
>> REQ SPC-30: MUST be able to block IPv6 packets that employ a 
>> Routing Header both at the granularity of Extension Header Type
>> (as required in SPC-20) and Routing Header Type.
> 
> I’d actually generalize that. Any of the extension headers that
> can handle a sub-option (of which the Routing Header and
> Destination Header are examples) should be able to filter on the
> presence, absence, or content of the various sub-options.

Good point. Will do.



>> REQ SPC-40: SHOULD be able to drop packets based on IPv6 option 
>> types.
> 
> Is that the same as SPC-30?

No. Here we mean that you should be able to filter based on the
*options* (i.e., this is finer-grained than SPC-30).



>> REQ SPC-50: MUST be able to detect IPv6 tunnels such as SIIT 
>> [RFC6145], 6to4 [RFC3056], 6in4 [RFC4213], ISATAP [RFC5214] and 
>> Teredo [RFC4380] (please see [RFC7123], and MUST be able to 
>> selectively block or allow them for specific sources,
>> destinations, routes or interfaces.
> 
> Why is this not “must implement an ACL that can permit or deny 
> traffic based on any combination of source and destination
> prefixes or port numbers, or next header (e.g. protocol) values”?

Would do. Maybe it would be valuable to avoid requiring the admin to
craft the aforementioned rules from cratch?



>> REQ SPC-60: MUST be able to validate IPv6 Neighbor Discovery 
>> [RFC4861] packets (RS, RA, NS, NA, Redirect) according to 
>> [I-D.ietf-opsec-ipv6-nd-security].
> 
> Why is this not a requirement of any IPv6 node? What makes it 
> specific to a firewall?

It's certainly not... But some validation checks are not (yet)
required for all nodes, and [I-D.ietf-opsec-ipv6-nd-security] will not
formally achieve this, since it's on the Informational track....



>> REQ SPC-70: MUST be able to statefully match ICMPv6 errors to
>> TCP [RFC0793], UDP [RFC0768], and ICMPv6 [RFC4443] communication 
>> instances (see [RFC5927]).
> 
> So, it not only keeps source/destination pair state, as a NA(P)T 
> might, but tracks send and acknowledge sequence numbers, last
> message sent (SYN vs data vs ack vs FIN/RST), and where the
> conversation is in its state machine. This precludes loa-sharing
> among firewalls, as the most recent message will by definition have
> passed one and not both.

Note: here we're requiring the ability of doing so... not the
enforcement of the policy.



>> REQ SPC-80: MUST be able to parse all defined extension headers 
>> according to [RFC7045], and SHOULD filter packets containing
>> IPv6 Extension Headers as recommended in 
>> [draft-gont-opsec-ipv6-eh-filtering].
> 
> How does this differ from SPC-20?

I agree this one wasn't clear. But here's the intent: SPC-20 requires
that the device has the capability to filter EHs on a per-type
granularity, etc. SPC-80 is meant to provide a default ruleset via
[draft-gont-opsec-ipv6-eh-filtering].

(yes, this is not clear... and the reference to RFC7045 is probably
superflous).



>> REQ SPC-90: MUST be able to find the upper-layer protocol in an 
>> IPv6 header chain (see [RFC7112].
> 
> How does this differ from SPC-80?

SPC-80 specifies default filtering rules based on EHs. SPC-90 requires
the fw to be able to process the entire IPv6 header chain (such that
e.g. the fw cannot be bypassed via inclusion of IPv6 EHs and the like).



>> REQ SPC-100: SHOULD be able to normalize (rewrite) the following 
>> IPv6 header fields on a per-interface basis:
>> 
>> *  Hop Limit
> 
> DANGER! DANGER WILL ROBINSON! Do you *really* want to do that?

As with many of the previous ones, here we're specifying feature,
rather than enforcement of a policy. (the device must be able to do
that... but that doesn't mean that e.g. the feature must be enabled by
default).

That said, normalizing the Hop Limit to something like, say, 64, will
prevent external nodes from discovering your network topology (yes,
you can also filter the corresponding ICMPv6 errors), and, most
importantly, will prevent an attacker from evading a NIDS by playing
with the Hop Limit field (such that the sensor sees the packet, but
the target doesn't).



>> 7.  Denial of Service (DoS) Protection
>> 
>> REQ DoS-10: MUST be able to protect against
>> implementation-specific attacks, including:
>> 
>> *  Winnuke [Myst1997]
>> 
>> *  ping-of-death [Kenney1996]
>> 
>> *  Smurf [CERT1998a]
>> 
>> *  LAND Attack [Meltman1997]
>> 
>> *  Teardrop Attack [CERT1997] [Junos-Teardrop]
> 
> So, just checking on the implications here. Nobody has thought of
> a new DDOS attack since 1998?

FWIW, these are not really DDOS, but rather common implementation
errors. The references are certainly about the IPv4 incarnation of
these vulnerabilities.. but some of them have reincarnated in IPv6
implementations. See e.g.:

*
<http://gcn.com/blogs/cybereye/2013/08/microsoft-patch-ping-of-death-ipv6.aspx>

* <http://tools.ietf.org/id/draft-gont-6man-ipv6-smurf-amplifier-01.txt>




>> REQ DoS-50: MUST be able to detect and drop malformed IPv6
>> packets (incorrect header/option lengths, etc.).
> 
> Hey! This is great! This IPv6 firewall actually does something
> with IPv6!
> 
> Is a side-effect of this that we can’t deploy a new feature like
> we had with ECN?

Why should it be? ECN had trouble being deployed because fw's were
dropping packets that had a *Reserved* bit set. Here we're talking
about *malformed* packet -- a packet with a reserved bit set does not
qualify as such.




>> REQ DoS-70: MUST be able to provide bandwidth management (QoS or 
>> anti- flooding) policies customizable for specific source and 
>> destination networks, or by VLAN or MPLS ID.
> 
> Hmm. That kind of thing is usually found in higher-end equipment.
> Are you saying that a residential firewall that one purchases for
> peanuts needs to do this? Do you have a market requirement?

We're certainly not talking about "residential firewalls" here. That
said, the idea is that if you have a residential firewall that somehow
wanted to "comply" with this document, you could simply state that it
e.g. "does not comply with the 'requirements for dos mitigation' in
this document", or e.g., that "it is conditionally compliant to the
'requirements for DoS mitigation' in this document".



>> REQ DoS-80: MUST be able to participate to a blackhole/synkhole 
>> routing infrastructure as per [RFC5635].
> 
> This is a general router requirement.

do you mean "a formal router requirement" (as say, per RFC1812)?

P.S.: More responses in the pipeline...

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492