Overblog Suivre ce blog
Editer l'article Administration Créer mon blog
10 septembre 2013 2 10 /09 /septembre /2013 15:39

We'll see here and discuss RFC6092 ( Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service ) and RFC4890 ( Recommendations for Filtering ICMPv6 Messages in Firewalls ) in details, as they provide the fundations for baseline IPv6 security, especially at consummer level.


RFC6092 - IPv6 Simple Security

RFC 6092 is labeled : Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
It defines a set of baselines for network appliances to provide homes and small offices Lans with a simple, default, perimeter IPv6 security.

They lay on users expectations and habits about IPv4 NAT, whose statefull nature de-facto created a pseudo-firewall functionning : Default allow out, default deny in, allow ( statefull ) traffic back in.

Here are IPv6 Simple Security basic foundations :

. Basic sanitation

. Statefull Firewalling

. Firewall exceptions management

. IPSEC allowed in

. Mobile IPv6 allowed in

. Some genuine inbound ICMPv6 traffic allowed in


Here is a map of RFC 6092 50 recomentations :

S7a.gif

Here is a detailed map :

 

S7b.gif

 

Let's review the different topics.


Basic Sanitation

Here are the packets to be dropped :

. Packets with a multicast source address
. Packets with a multicast destination address over or equal to the router multicast scope
. Packets non-Internet Routable : bogon address, unspecified address, loopback address, ORCHID address, documentation address, ULA, Link-local, Site-local, IPv4-mapped, IPv4-compatible, 6to4 martian and Teredo Martian.
. Packets with a deprecated extension header before the upper-layer payload ( routing extension header type 0, ... )
. Packets that fail the Ingress filtering
. Inbound DNS queries should not by resolved by the CPE ( by default )
. Inbound DHCPv6 queries should not be resolved or relayed by the CPE
. Inbound ICMPv6 Destination Unreachable and Packet Too Big error messages that do not belong to a previous outgoing state

Please note that regarding ICMPv6, RFC 4890 recommendations apply, with the addition of the discard of inbound, non-state related, Destination Unreachable and Packet Too Big error messages. The third part of this post deals with RFC 4890 + IPv6 Simple Security result

This implies that incomming echo request, time exceeded and parameter error are allowed in by default, even if unrelated to any current firewall state.

 

 

 

Statefull Firewalling

IPv6 Simple Security expects a classic statefull firewall functionning.
inbound ICMPv6 error messages related to current firewall states are allowed in.
There are provisions for simultaneous-open mode ( RFC 0793 ) for TCP and SCTP.
Special precisions are provided for state timeouts.

 

 

VPN and IPSEC

by default outbound VPN is allowed and inbound VPN is denied.

 

IPSEC is allowed in by default. Precisely :

AH and ESP allowed in by default
Dest 500 port ( IKE ) allowed in by default
HIP allowed in by default

Inbound ICMPv6 Destination Unreachable and Packet Too Big error messages related to current ESP firewall states allowed in by default.


Mobile IPv6

Mobility is a standard feature of IPv6. Here are the IPv6 Simple Security baselines :

Unsolicited inbound Mobility Header messages that are not the subject of an IPsec security policy are expected to be dropped.

Statefull 'mobile' must be allowed in

Inbound ICMPv6 Destination Unreachable and Packet Too Big error messages related to current Mobility Header flow states records are allowed.



General user's experience

CPE firmware update :
. automatic or manual updates
. pre-configuration of the download URL
. a mean of validating the firmware ( ex by a certificate )

Transparent mode :
. an easy option to cancel IPv6 Simple Security

Wan management of the CPE not allowed by default


A few notes

The question of ' Passive Listeners ' have not been settled yet. Technics like UPnP-IGD or NAT-PMP ( without NAT ), or some new emerging protocol may be used. The REC-49 states :

" REC-48: 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. "



RFC 4890

RFC 4890 is labeled ' Recommendations for Filtering ICMPv6 Messages in Firewalls '

Basically, RFC 4890 allows unexpected inbound :

. echo request

. some ICMPv6 error messages

. some mobile IPv6 messages

. authenticated headers

 

 

Let's look into the details


First, let's assume we use a statefull firewall, with default allow out, as it is the most common situation, and as it's RFC 6092 functionning.

So allow out rules won't be listed, neither allow in to previous outbound requests.

The third part of this post deals with the complete listing of RFC 4890.

 

 

Must Not Be Dropped :

   o  Destination Unreachable
   o  Packet Too Big
   o  Time Exceeded ( Hop limit only )
   o  Parameter Problem ( Codes 1 and 2 only )

   o  Echo Request

Should Not Be Dropped :

   o  any ICMPv6 Error message

   o  Echo Request

   o  Home Agent Address Discovery Request (Type 144) if the firewall is a Home Agent
   o  Mobile Prefix Solicitation (Type 146) if the firewall is a Home Agent


Delivery-authenticated messages (eg IPsec AH header or ESP header with authentication ) may be
subject to less strict policies than messages that cannot be authenticated.


Should be site confined :

Router Renumbering Messages

Node Information Query and Reply


in general : scopes should match

 

 

Consequences of RFC 4890 upon IPv6 Simple Security

As RFC 6092 builds upon RFC 4890 about ICMPv6 messages, here is the final RFC 6092 result about ICMPv6 :


Must Not Be Dropped :

   o  Time Exceeded ( Hop limit only )
   o  Parameter Problem ( Codes 1 and 2 only )

   o  Echo Request

Should Not Be Dropped

   o  Time Exceeded
   o  Parameter Problem

   o  Echo Request

   o  Home Agent Address Discovery Request (Type 144) if the firewall is a Home Agent
   o  Mobile Prefix Solicitation (Type 146) if the firewall is a Home Agent


Delivery-authenticated messages (eg IPsec AH header or ESP header with authentication ) may be
subject to less strict policies than messages that cannot be authenticated.


site confined :

Router Renumbering Messages

Node Information Query and Reply

in general : scopes should match

 

 

Complete RFC 4890

 

Here is the precise RFC 4890 :

 

Must Not Be Dropped :

   o  Destination Unreachable
   o  Packet Too Big
   o  Time Exceeded ( Hop limit only )
   o  Parameter Problem ( Codes 1 and 2 only )

   o  Echo Request
   o  Echo Response


Should Not Be Dropped

   o  any ICMPv6 Error message

   o  Echo Request
   o  Echo Response

   o  Home Agent Address Discovery Request (Type 144)
   o  Home Agent Address Discovery Reply (Type 145)
   o  Mobile Prefix Solicitation (Type 146)
   o  Mobile Prefix Advertisement (Type 147)

Delivery-authenticated messages (eg IPsec AH header or ESP header with authentication ) may be
   subject to less strict policies than messages that cannot be
   authenticated.


site confined :

Router Renumbering Messages

Node Information Query and Reply



in general : scopes should match
             address match ( ingress filtering )

Section A.14 suggestions for a more fine-grained IPv6 Mobile ICMPv6 Filtering

 

For Home Agents, the firewall must allow :

 

incoming Home Agent Address Discovery Request

Incoming Mobile Prefix Solicitation

Outgoing Home Agent Address Discovery Reply

Outgoing ICMP Mobile Prefix Advertisement


Advice : " It may be desirable to limit the destination addresses for the incoming messages to links that are known to support home agents "

 

For roaming mobile nodes hosting , the firewall must allow :

 

outgoing Home Agent Address Discovery Request

outgoing Mobile Prefix Solicitation

incoming Home Agent Address Discovery Reply

incoming ICMP Mobile Prefix Advertisement

 

For Administrators :

 

Advice : " Administrators may find it desirable to prevent static nodes that are normally resident on the site from behaving as mobile nodes by dropping Mobile IPv6 messages from these nodes. "

 

Partager cet article

Repost 0
Published by computer outlines - dans IPv6
commenter cet article

commentaires

Présentation

  • : Computer Outlines Blog
  • : Blog mainly focused over IPv6, Windows Server, and Networking in general.
  • Contact

Recherche

Liens