A presentation based on RFC 6092 that presents recommendations for devices that operate IPv6 firewalls for home or small business networks.

1. IPV6 SIMPLE SECURITY
CAPABILITIES.
50 issues from RFC 6092 edited by J. Woodyatt, Apple
Presentation by Olle E. Johansson, Edvina AB.

2. ABSTRACT
• The RFC which this presentation is based upon is focused on
IPv6 gateway CPEs - home routers, business Internet
gateways.
• TheRFC is informational and refers to other RFCs that are
standard documents.
• TheRFC was contributed to by a large group of very
experienced TCP/IP network engineers

3. COPYRIGHT FOR THE RFC
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.

4. OVERVIEW
For the purposes of this document, residential Internet gateways are
assumed to be fairly simple devices with a limited subset of the full
range of possible features. They function as default routers
[RFC4294] for a single local-area network, e.g., an Ethernet network,
a Wi-Fi network, or a bridge between two or more such segments. They
have only one interface by which they can access the Internet service
at any one time, using any of several possible sub-IP mechanisms,
including tunnels and transition mechanisms.
In referring to the security capabilities of residential gateways, it
is reasonable to distinguish between their "interior" network, i.e.,
the local-area network, and their "exterior" networks, e.g., the
public Internet and the networks of Internet service providers. This
document is concerned only with the behavior of IP packet filters
that police the flow of traffic between the interior IPv6 network and
the exterior IPv6 networks of residential Internet gateways.

5. NOT A STANDARD, BUT
VERY USEFUL
• Even though this RFC is not a standards-track document, it’s a
very useful document
• If you refer to this document in your procurement process,
you have a good reference
• Some requirements can of course be discussed - and we hope
they will be!
• Feedback is of course welcome - on Facebook, Twitter or as a comment
on our web page.

6. RECOMMENDED OPERATIONAL
GOALS FOR THE FIREWALL
• Check all traffic to and from Internet for basic sanity
• Allow tracking of application usage by source and destination network
addresses and ports
• Provide a barrier agains untrusted external influences
• Allow manually configured exceptions
• Isolate local network DHCPv6 and DNS resolver services from the public
Internet
RFC 4864

7. 50 RECOMMENDATIONS
Read the RFC for details and references
to other documents and web pages. The RFC has much
more background material. This is just a checklist based on
the RFC to simplify your checks with current products and
firewall rulesets.

8. STATELESS FILTERS:
1.
MULTICAST SOURCE
• Packets bearing multicast source address in their outer IPv6
headers MUST NOT be forwarded or transmitted on any
interface

9. STATELESS FILTERS:
2.
MULTICAST DESTINATION
• Packetsbearing multicast destination addresses in their outer
IPv6 headers of equal or narrower scope than the configured
scope boundary level of the gateway MUST NOT be
forwarded in any direction.
• The default scope SHOULD be organization-local scope.
See RFC 4007
for scopes.

10. STATELESS FILTERS:
3.
FORBIDDEN ADDRESSES
• Packetsbearing source and/or destination addresses forbidden
to appear in the outer headers of packets transmitted over
the public Internet MUST NOT be forwarded.
See RFC 3879
and 5156.

11. STATELESS FILTERS:
4.
BAD EXTENSION HEADERS
• Packetsbearing deprecated extension headers prior to their
first upper-layer-protocol header SHOULD NOT be
forwarded or transmitted over any interface.
See RFC 2460
and 5095.

12. STATELESS FILTERS:
5.
NON-LOCAL ADDRESSES
• Outbound packets MUST NOT be forwarded if the source
address in their outer IPv6 header does not have a unicast
prefix configured for use by globally reachable nodes on the
interior network.

13. STATELESS FILTERS:
6.
LOCAL ADDRESSES ON
INBOUND PACKETS
• Inbound packets MUST NOT be forwarded if the source
address in their outer IPv6 header has a global unicast prefix
assigned for use by globally reachable nodes on the internal
network.
Don’t accept
spoofed addresses.

14. STATELESS FILTERS:
7.
UNIQUE LOCAL
ADDRESSES
• ByDEFAULT, packets with unique local source and/or
destination addresses SHOULD NOT be forwarded to or
from the exterior network.
ULA: RFC 4193

15. STATELESS FILTERS:
8. DNS QUERIES
• By DEFAULT, inbound DNS queries received on the exterior
interfaces MUST NOT be processed by any integrated DNS
resolving server.
A gateway
with DNS should
serve the internal
network only.

16. STATELESS FILTERS:
9. DHCPV6
• Inbound DHCPv6 discovery packets received on exterior
interfaces MUST NOT be processed by any integrated
DHCPv6 server or relay agent.
A gateway
with DHCPv6 should
serve the internal
network only.

17. CONNECTION-FREE FILTERS:
10. ICMPV6
• IPv6
gateways SHOULD NOT forward ICMPv6 "Destination
Unreachable" and "Packet Too Big" messages containing IP
headers that do not match generic upper-layer transport state
records
RFC 4890 describes
filtering of ICMPv6

18. CONNECTION-FREE FILTERS:
11. APPLICATIONS
• If application transparency is most important, then a stateful packet filter SHOULD have
"endpoint-independent filtering" behavior for generic upper-layer transport protocols.
• If a more stringent filtering behavior is most important, then a filter SHOULD have
"address-dependent filtering" behavior.
• The filtering behavior MAY be an option configurable by the network administrator, and it
MAY be independent of the filtering behavior for other protocols.
• Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended
for provisioning without service-provider management.
A gateway is said to have
"endpoint-independent filt
when the exterior address ering" behavior
is not evaluated when matc
with a flow. A gateway is hing a packet
said to have "address-dep
behavior when the exterior endent filtering"
address of a packet is re
the exterior address for quired to match
its flow.

19. CONNECTION-FREE FILTERS:
12.
TIMEOUT FOR
APPLICATIONS
• Filter state records for generic upper-layer transport protocols MUST NOT be deleted or
recycled until an idle timer not less than two minutes has expired without having
forwarded a packet matching the state in some configurable amount of time.
• By DEFAULT, the idle timer for such state records is five minutes.

20. CONNECTION-FREE FILTERS:
13. APPLICATION UPDATES
• ResidentialIPv6 gateways SHOULD provide a convenient
means to update their firmware securely, for the installation of
security patches and other manufacturer-recommended
changes
The Internet security community is never completely at rest. New
attack surfaces, and vulnerabilities in them, are typically
discovered faster than they can be patched by normal equipment
upgrade cycles. It's therefore important for vendors of residential
gateway equipment to provide automatic software updates to patch
vulnerabilities as they are discovered.

21. CONNECTION-FREE FILTERS - UDP:
14. UDP TIMEOUTS
•A state record for a UDP flow where both source and
destination ports are outside the well-known port range
(ports 0-1023) MUST NOT expire in less than two minutes of
idle time.
• Thevalue of the UDP state record idle timer MAY be
configurable.
• The DEFAULT is five minutes. Based on RFC 4787
which describes
best practise for IPv4
UDP filtering

22. CONNECTION-FREE FILTERS - UDP:
15. UDP TIMEOUTS
•Astate record for a UDP flow where one or both of the
source and destination ports are in the well-known port range
(ports 0-1023) MAY expire after a period of idle time shorter
than two minutes to facilitate the operation of the IANA-
registered service assigned to the port in question.
Based on RFC 4787
which describes
best practise for IPv4
UDP filtering

23. CONNECTION-FREE FILTERS - UDP:
16.
CONNECTION STATE
REFRESH
•A state record for a UDP flow MUST be refreshed when a
packet is forwarded from the interior to the exterior, and it
MAY be refreshed when a packet is forwarded in the reverse
direction.
NAT keepalives
should come from the
inside.

24. CONNECTION-FREE FILTERS - UDP:
17.
APPLICATION
TRANSPARENCY
• If application transparency is most important, then a stateful packet filter SHOULD have
"endpoint-independent filtering" behavior for UDP.
• If a more stringent filtering behavior is most important, then a filter SHOULD have
"address-dependent filtering" behavior.
• The filtering behavior MAY be an option configurable by the network administrator, and
it MAY be independent of the filtering behavior for TCP and other protocols.
• Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider management.

25. CONNECTION-FREE FILTERS - UDP:
18.
CONNECTION RELATED
ICMP MESSAGES
• Ifa gateway forwards a UDP flow, it MUST also forward
ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing UDP headers that match the flow state
record.
See Path MTU Discovery
RFC 1981

26. CONNECTION-FREE FILTERS - UDP:
19.
ICMPV6 AND THE
CONNECTION STATE
• Receiptof any sort of ICMPv6 message MUST NOT
terminate the state record for a UDP flow.

27. CONNECTION-FREE FILTERS - UDP:
20.
UDP-LITE IS A SEPARATE
FLOW
• UDP-Lite flows [RFC3828] SHOULD be handled in the same
way as UDP flows, except that the upper-layer transport
protocol identifier for UDP-Lite is not the same as UDP;
therefore, UDP packets MUST NOT match UDP-Lite state
records, and vice versa.

28. CONNECTION-FREE FILTERS - IPSEC:
21. IPSEC FILTERING - AH
• In
their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate
node addresses, with destination extension headers of type
"Authentication Header (AH)" [RFC4302] in their outer IP
extension header chain.
The Internet Protocol security (IPsec) suite offers greater
flexibility and better overall security than the simple security of
stateful packet filtering at network perimeters. Therefore,
residential IPv6 gateways need not prohibit IPsec traffic flows.

29. CONNECTION-FREE FILTERS - IPSEC:
22. IPSEC FILTERING -ESP
• Intheir DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate
node addresses, with an upper-layer protocol of type
"Encapsulating Security Payload (ESP)" [RFC4303] in their outer
IP extension header chain.

30. CONNECTION-FREE FILTERS - IPSEC:
23. IPSEC RELATED ICMPV6
• Ifa gateway forwards an ESP flow, it MUST also forward (in
the reverse direction) ICMPv6 "Destination Unreachable" and
"Packet Too Big" messages containing ESP headers that match
the flow state record.

31. CONNECTION-FREE FILTERS - IPSEC:
24. IKE FOR IPSEC
• Intheir DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of any UDP packets, to and from
legitimate node addresses, with a destination port of 500, i.e.,
the port reserved by IANA for the Internet Key
Exchange (IKE) protocol
IKE - see RFC 5996

32. CONNECTION-FREE FILTERS - IPSEC:
25. ESP FILTERS
• In all operating modes, IPv6 gateways SHOULD use filter state records for
Encapsulating Security Payload (ESP) [RFC4303] that are indexable by a 3-tuple
comprising the
• interior node address
• the exterior node address
• the ESP protocol identifier.
• In particular, the IPv4/NAT method of indexing state records also by the security
parameters index (SPI) SHOULD NOT be used.
• Likewise, any mechanism that depends on detection of Internet Key Exchange
(IKE) [RFC5996] initiations SHOULD NOT be used.

33. CONNECTION-FREE FILTERS - IPSEC:
26.
HOST IDENTITY
PROTOCOL
• In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the
forwarding of packets, to and from legitimate node addresses, with destination
extension headers of type "Host Identity Protocol (HIP)" in their outer IP extension
header chain.
The Host Identity Protocol (HIP) is a secure mechanism for
establishing host identity and secure communications between
authenticated hosts. Residential IPv6 gateways need not prohibit
inbound HIP flows.
HIP - See RFC 5201

34. CONNECTION-FREE FILTERS - MOBILITY:
27. MOBILE IPV6
• The state records for flows initiated by outbound packets that bear a Home
Address destination option are distinguished by the addition of the home address
of the flow as well as the interior care-of address. IPv6 gateways MUST NOT
prohibit the forwarding of any inbound packets bearing type 2 routing headers,
which otherwise match a flow state record, and where
• A) the address in the destination field of the IPv6 header matches the interior care-
of address of the flow, and
• B) the Home Address field in the Type 2 Routing Header matches the home
address of the flow.
Not all usage scenarios of mobility support in IPv6 are expected to
be compatible with IPv6 simple security. In particular, exterior
mobile nodes are expected to be prohibited from establishing bindings
with interior correspondent nodes by the filtering of unsolicited IPv6 Mobile IP
inbound Mobility Header messages, unless they are the subject of an
IPsec security policy.
- RFC 3775

35. CONNECTION-FREE FILTERS - MOBILITY:
28. MOBILITY FLOWS
• Valid
sequences of Mobility Header [RFC3775] packets MUST
be forwarded for all outbound and explicitly permitted
inbound Mobility Header flows.

36. CONNECTION-FREE FILTERS - MOBILITY:
29. MOBILITY FLOWS
• If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward, in both directions, the IPv4 and IPv6
packets that are encapsulated in IPv6 associated with the
tunnel between the home agent and the correspondent node.

37. CONNECTION-FREE FILTERS - MOBILITY:
30. MOBILITY FLOWS - ICMPV6
• If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward (in the reverse direction) ICMPv6
"Destination Unreachable" and "Packet Too Big" messages
containing any headers that match the associated flow state
records.

38. CONNECTION-ORIENTED FILTERS: TCP
31. TCP HANDSHAKES
• All
valid sequences of TCP packets (defined in [RFC0793])
MUST be forwarded for outbound flows and explicitly
permitted inbound flows.
• In
particular, both the normal TCP 3-way handshake mode of
operation and the simultaneous-open mode of operation
MUST be supported.
See RFC 793

39. CONNECTION-ORIENTED FILTERS: TCP
32. TCP WINDOW HANDLING
• The TCP window invariant MUST NOT be enforced on flows
for which the filter did not detect whether the window-scale
option was sent in the 3-way handshake or simultaneous-
open.
See RFC 1323

40. CONNECTION-ORIENTED FILTERS: TCP
33. TCP STATEFUL FILTERS
• If application transparency is most important, then a stateful packet filter
SHOULD have "endpoint-independent filtering" behavior for TCP.
• If a more stringent filtering behavior is most important, then a filter
SHOULD have "address-dependent filtering” behavior.
• The filtering behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering behavior for
UDP and other protocols.
• Filtering behavior SHOULD be endpoint independent by DEFAULT in
gateways intended for provisioning without service-provider management.

41. CONNECTION-ORIENTED FILTERS: TCP
34.
UNSOLICITED TCP SYN
PACKETS
• ByDEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (Communication with
destination administratively prohibited) to any unsolicited
inbound SYN packet after waiting at least 6 seconds without
first forwarding the associated outbound SYN or SYN/ACK
from the interior peer.

42. CONNECTION-ORIENTED FILTERS: TCP
35. TCP SESSION TIMEOUTS
• If a gateway cannot determine whether the endpoints of a
TCP flow are active, then it MAY abandon the state record if
it has been idle for some time. In such cases, the value of the
"established flow idle-timeout" MUST NOT be less than two
hours four minutes, as discussed in [RFC5382]. The value of
the "transitory flow idle-timeout" MUST NOT be less than four
minutes.
• The value of the idle-timeouts MAY be configurable by the
network administrator.

43. CONNECTION-ORIENTED FILTERS: TCP
36.
ICMPV6 RELATED TO TCP
SESSION
• Ifa gateway forwards a TCP flow, it MUST also forward
ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing TCP headers that match the flow state
record.
Several TCP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of TCP segments. One such
mechanism is path MTU discovery, which is required for correct
operation of TCP.

44. CONNECTION-ORIENTED FILTERS: TCP
37.
ICMPV6 RELATED TO TCP
SESSION STATES
• Receiptof any sort of ICMPv6 message MUST NOT
terminate the state record for a TCP flow.
Several TCP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of TCP segments. One such
mechanism is path MTU discovery, which is required for correct
operation of TCP.

45. CONNECTION-ORIENTED FILTERS: SCTP
38. SCTP CONNECTION SETUP
• All
valid sequences of SCTP packets (defined in [RFC4960])
MUST be forwarded for outbound associations and explicitly
permitted inbound associations. In particular, both the normal
SCTP association establishment and the simultaneous-open
mode of operation MUST be supported.
The RFC this presentation is
based upon - 6092 - includes
a lot of information about
SCTP security

46. CONNECTION-ORIENTED FILTERS: SCTP
39.
UNSOLICITED INIT
REQUESTS
• By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (Communication with
destination administratively prohibited), to any unsolicited
inbound INIT packet after waiting at least 6 seconds without
first forwarding the associated outbound INIT from the
interior peer.

47. CONNECTION-ORIENTED FILTERS: SCTP
40.
UNSOLICITED INIT
REQUESTS
• By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (Communication with
destination administratively prohibited), to any unsolicited
inbound INIT packet after waiting at least 6 seconds without
first forwarding the associated outbound INIT from the
interior peer.

48. CONNECTION-ORIENTED FILTERS: SCTP
41. SCTP RELATED ICMPV6
• Ifa gateway forwards an SCTP association, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too
Big" messages containing SCTP headers that match the
association state record.

49. CONNECTION-ORIENTED FILTERS: SCTP
42. SCTP RELATED ICMPV6
• Receiptof any sort of ICMPv6 message MUST NOT
terminate the state record for an SCTP association.

50. CONNECTION-ORIENTED FILTERS: DCCP
43. DCCP FLOWS
• All
valid sequences of DCCP packets (defined in [RFC4340])
MUST be forwarded for all flows to exterior servers, and for
any flows to interior servers that have explicitly permitted
service codes.
Datagram Congestion Control
protocol - DCCP - RFC 4340

51. CONNECTION-ORIENTED FILTERS: DCCP
44. DCCP FLOW TIMEOUTS
•A gateway MAY abandon a DCCP state record if it has been
idle for some time.
• In such cases, the value of the "open flow idle-timeout" MUST NOT be less
than two hours four minutes.
• The value of the "transitory flow idle-timeout" MUST NOT be less than eight
minutes.
• Thevalue of the idle-timeouts MAY be configurable by the
network administrator.

52. CONNECTION-ORIENTED FILTERS: DCCP
45. DCCP FLOW & ICMPV6
• Ifan Internet gateway forwards a DCCP flow, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing DCCP headers that match the flow state
record.

53. CONNECTION-ORIENTED FILTERS: DCCP
46. DCCP FLOW & ICMPV6
• Receiptof any sort of ICMPv6 message MUST NOT
terminate the state record for a DCCP flow.

54. CONNECTION-ORIENTED FILTERS
47. THE SHIM6 PROTOCOL
• Valid
sequences of packets bearing Shim6 payload extension
headers in their outer IP extension header chains MUST be
forwarded for all outbound and explicitly permitted flows. The
content of the Shim6 payload extension header MAY be
ignored for the purpose of state tracking.
Level 3 Multihoming Shim
Protocol for IPv6
RFC 5533

55. CONNECTION-ORIENTED FILTERS
47. THE SHIM6 PROTOCOL
• Valid
sequences of packets bearing Shim6 payload extension
headers in their outer IP extension header chains MUST be
forwarded for all outbound and explicitly permitted flows. The
content of the Shim6 payload extension header MAY be
ignored for the purpose of state tracking.
Level 3 Multihoming Shim
Protocol for IPv6
RFC 5533

56. PUBLISHING SERVICES:
48. INTERNAL SERVICES
• Internet gateways with IPv6 simple security capabilities
SHOULD implement a protocol to permit applications to
solicit inbound traffic without advance knowledge of the
addresses of exterior nodes with which they expect to
communicate.
This is very vague,
since the
IETF has not agreed on
a recommendation.

57. PUBLISHING SERVICES:
49.
DISABLING THE STATEFUL
FIREWALL
• Internetgateways with IPv6 simple security capabilities MUST
provide an easily selected configuration option that permits a
"transparent mode" of operation that forwards all unsolicited
flows regardless of forwarding direction, i.e., not to use the
IPv6 simple security capabilities of the gateway.
• Thetransparent mode of operation MAY be the default
configuration.
This assumes that the
IPv6 simple security capabilities
replace the role of
the IPv4 NAT.

58. FIREWALL MANAGEMENT:
50.
DO NOT LET THE HACKER
TAKE OVER...
• ByDEFAULT, subscriber-managed residential gateways MUST
NOT offer management application services to the exterior
network.
This assumes that the
IPv6 simple security capabilities
replace the role of
the IPv4 NAT.

59. NOTE
• ”The security functions described in this document may be
considered redundant in the event that all IPv6 hosts using a
particular gateway have their own IPv6 host firewall capabilities
enabled. At the time of this writing, the vast majority of commercially
available operating systems with support for IPv6 include IPv6 host
firewall capability.”
• ”The IETF makes no statement, expressed or implied, as to whether
using the capabilities described in this document ultimately improves
security for any individual users or for the Internet community as a
whole.”

60. NOW, GO READ THE
COMPLETE RFC.
http://tools.ietf.org/html/rfc6092
TWITTER @IPV6FRIDAY