Transcript PowerPoint - IPv6 Friday

IPv6 Simple security
capabilities.
50 issues from RFC 6092 edited by J. Woodyatt, Apple
Presentation by Olle E. Johansson, Edvina AB.
Abstract
•
The RFC which this presentation is based upon is
focused on IPv6 gateway CPEs - home routers,
business Internet gateways.
•
The RFC is informational and refers to other RFCs that
are standard documents.
•
The RFC was contributed to by a large group of very
experienced TCP/IP network engineers
Copyright for the RFC
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
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.
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
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.
1.
•
Stateless filters:
Multicast SOURCE
Packets bearing multicast source address in their outer
IPv6 headers MUST NOT be forwarded or transmitted
on any interface
2.
Stateless filters:
MULTICAST
DESTINATION
•
Packets bearing 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.
3.
•
Stateless filters:
Forbidden addresses
Packets bearing 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.
4.
•
Stateless filters:
BAD EXTENSION
HEADERS
Packets bearing 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.
5.
•
Stateless filters:
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.
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.
Stateless filters:
7.
•
Unique local addresses
By DEFAULT, packets with unique local source and/or
destination addresses SHOULD NOT be forwarded to
or from the exterior network.
ULA: RFC 4193
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.
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.
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
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.
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.
Connection-free filters:
13.
•
APPLICATION UPDATES
Residential IPv6 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.
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.
•
The value of the UDP state record idle timer MAY be
configurable.
•
Based on RFC 4787
which describes
best practise for IPv4
UDP filtering
The DEFAULT is five minutes.
Connection-free filters - UDP:
15.
•
UDP TIMEOUTS
A state 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
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.
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.
Connection-free filters - UDP:
18.
•
Connection RELATED
ICMP Messages
If a 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
Connection-free filters - UDP:
19.
•
ICMPv6 and the connection
state
Receipt of any sort of ICMPv6 message MUST NOT
terminate the state record for a UDP flow.
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.
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.
Connection-free filters - IPSEC:
22.
•
IPSec filtering -ESP
In their 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.
Connection-free filters - IPSEC:
23.
•
IPSEC related ICMPv6
If a 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.
Connection-free filters - IPSEC:
24.
•
IKE for IPsec
In their 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
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.
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
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
Not all
usage scenarios
of mobility
support
in IPv6 are expected to
home
address
of
the
flow.
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
inbound Mobility Header messages, unless they are the subject of an
IPsec security policy.
IPv6 Mobile IP
- RFC 3775
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.
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.
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.
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
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
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-
Connection-oriented filters: TCP
34.
•
UNSOLICITED TCP SYN
PACKETS
By DEFAULT, 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.
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 idletimeout" MUST NOT be less than four minutes.
•
The value of the idle-timeouts MAY be configurable by
the network administrator.
Connection-oriented filters: TCP
36.
•
ICMPv6 related to tcp
session
If a 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.
Connection-oriented filters: TCP
37.
•
ICMPv6 related to tcp
session states
Receipt of 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.
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
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.
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.
Connection-oriented filters: SCTP
41.
•
SCTP related ICMPv6
If a 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.
Connection-oriented filters: SCTP
42.
•
SCTP related ICMPv6
Receipt of any sort of ICMPv6 message MUST NOT
terminate the state record for an SCTP association.
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
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.
The value of the idle-timeouts MAY be configurable by
the network administrator.
Connection-oriented filters: DCCP
45.
•
DCCP FLOW & ICMPv6
If an 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.
Connection-oriented filters: DCCP
46.
•
DCCP FLOW & ICMPv6
Receipt of any sort of ICMPv6 message MUST NOT
terminate the state record for a DCCP flow.
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
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
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.
PUBLISHING SERVICES:
49.
DISABLING THE
STATEFUL FIREWALL
•
Internet gateways 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.
•
This assumes
thatdefault
the
The transparent mode of operation MAY
be the
IPv6 simple security
configuration.
capabilities replace the role
of
the IPv4 NAT.
Firewall management:
50.
•
Do not let the hacker
take over...
By DEFAULT, 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.
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.”
Now, go read the complete
RFC.
http://tools.ietf.org/html/rfc6092
TWITTER @IPV6FRIDAY