ipv6 simple security capabilities. 50 issues from rfc 6092 edited by j. woodyatt, apple presentation...

IPv6 Simple securitycapabilities.

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.

http://tools.ietf.org/html/rfc4294

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

RFC 4864

50 RecommendationsRead the RFC for details and references

to other documents and web pages. The RFC has muchmore background material. This is just a checklist based

onthe RFC to simplify your checks with current products and

firewall rulesets.

Stateless filters:Multicast SOURCE

• Packets bearing multicast source address in their outer IPv6 headers MUST NOT be forwarded or transmitted on any interface

1.

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.

2.

See RFC 4007

for scopes.

See RFC 4007

for scopes.

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.

3.

See RFC 3879

and 5156.

See RFC 3879

and 5156.

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.

4.

See RFC 2460

and 5095.

See RFC 2460

and 5095.

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.

5.

Stateless filters:

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.

6.

Don’t acceptspoofed

addresses.

Don’t acceptspoofed

addresses.

Stateless filters:

Unique local addresses

• By DEFAULT, packets with unique local source and/or destination addresses SHOULD NOT be forwarded to or from the exterior network.

7.

ULA: RFC 4193

ULA: RFC 4193

Stateless filters:

DNS Queries

• By DEFAULT, inbound DNS queries received on the exterior interfaces MUST NOT be processed by any integrated DNS resolving server.

8.

A gateway with DNS shouldserve the internal

network only.

A gateway with DNS shouldserve the internal

network only.

Stateless filters:

DHCPv6

• Inbound DHCPv6 discovery packets received on exterior interfaces MUST NOT be processed by any integrated DHCPv6 server or relay agent.

9.

A gateway with DHCPv6 should

serve the internal

network only.

A gateway with DHCPv6 should

serve the internal

network only.

Connection-free filters:

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

10.

RFC 4890 describesfiltering of

ICMPv6

RFC 4890 describesfiltering of

ICMPv6


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.

11.

A gateway is said to have "endpoint-independent filtering" behavior when the exterior address is not evaluated when matching a packet with a flow. A gateway is said to have "address-dependent filtering" behavior when the exterior address of a packet is required to match the exterior address for its flow.


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.

12.


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

13.

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:

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.

• The DEFAULT is five minutes.

14.

Based on RFC 4787 which describesbest practise for

IPv4 UDP filtering


IPv4 UDP filtering


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.

15.


IPv4 UDP filtering


IPv4 UDP filtering


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.

16.

NAT keepalivesshould come from

theinside.

NAT keepalivesshould come from

theinside.


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.


17.


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.

18.

See Path MTU DiscoveryRFC 1981

See Path MTU DiscoveryRFC 1981


ICMPv6 and the connection state

• Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a UDP flow.

19.


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.

20.


Connection-free filters - IPSEC:

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.

21.

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.



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.

22.



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.

23.


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

24.

IKE - see RFC 5996

IKE - see RFC 5996


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.

25.




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.

26.

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

HIP - See RFC 5201

Connection-free filters - mobility:

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.

27.

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 inbound Mobility Header messages, unless they are the subject of an IPsec security policy.

IPv6 Mobile IP- RFC 3775

IPv6 Mobile IP- RFC 3775


mobility flows

• Valid sequences of Mobility Header [RFC3775] packets MUST be forwarded for all outbound and explicitly permitted inbound Mobility Header flows.

28.



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.

29.



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.

30.


Connection-oriented filters: TCP

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.

31.

See RFC 793See RFC 793



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.

32.

See RFC 1323See RFC 1323


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.


33.


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.

34.


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.

35.



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.

36.

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.


ICMPv6 related to tcp session states

• Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a TCP flow.

37.

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

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.

38.

The RFC this presentation is based upon - 6092 - includes

a lot of information about

SCTP security

The RFC this presentation is based upon - 6092 - includes

a lot of information about

SCTP security



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.

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.

40.


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.

41.


SCTP related ICMPv6

• Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for an SCTP association.

42.

Connection-oriented filters: DCCP

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.

43.

Datagram Congestion Control protocol - DCCP -

RFC 4340

Datagram Congestion Control protocol - DCCP -

RFC 4340


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.

44.


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.

45.


DCCP FLOW & ICMPv6

• Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a DCCP flow.

46.

Connection-oriented filters

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.

47.

Level 3 Multihoming Shim Protocol for

IPv6RFC 5533

Level 3 Multihoming Shim Protocol for

IPv6RFC 5533

PUBLISHING SERVICES:

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.

48.

This is very vague, since the

IETF has not agreed on

a recommendation.

This is very vague, since the

IETF has not agreed on

a recommendation.

PUBLISHING SERVICES:

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.

• The transparent mode of operation MAY be the default configuration.

49.

This assumes that theIPv6 simple security

capabilities replace the role of

the IPv4 NAT.



the IPv4 NAT.

Firewall management:

Do not let the hackertake over...

• By DEFAULT, subscriber-managed residential gateways MUST NOT offer management application services to the exterior network.

50.



the IPv4 NAT.



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

ipv6 simple security capabilities. 50 issues from rfc 6092 edited by j. woodyatt, apple presentation...

Documents

public internet rfc

interior ipv6 network

interior network

destination network

ethernet network

wifi network

local network dhcpv6

business internet gateways