[j-nsp] IPv6 'protect-re' sanity check

[David B Funk]

On Thu, 30 Jun 2011, Rafael Rodriguez wrote:

> Hello List,
>
> I need some help with a sanity check on a couple routing engine filters for
> IPv6; specifically on the ICMPv6 section.  The router will connect to
> routers only, no end hosts (not allowing RA and RS).   Filters based off the
> Juniper Day One ebook Securing the Routing Engine.  Should anything be added
> or removed?  How are others doing this?  Thanks in advanced.
>
[snip..]

> filter accept-icmpv6 {
>     apply-flags omit;
>     term accept-icmp {
>         from {
>             destination-prefix-list {
>                 router-ipv6;
>                 router-ipv6-logical-systems;
>             }
>             next-header icmpv6;
>             icmp-type [ echo-reply echo-request time-exceeded unreachable
> source-quench parameter-problem neighbor-advertisement neighbor-solicit
> packet-too-big ];
>         }
>         then {
>             policer management-5m;
>             count accept-icmpv6;
>             accept;
>         }
>     }
> }
[snip..]

Rafael,
 I'll address your ICMPv6 section. With out knowing the contents of
your router-ipv6 & router-ipv6-logical-systems prefix lists I can only
guess, but it looks like you're allowing both too much and not enough.

ICMPv6 is a more important beast than ICMPv4 because of it's larger
role (EG it replaces ARP, and the lack of v6 broadcasts make proper
multicast handling more important).

Specifically, you should differenciate between local scope traffic and
global scope traffic. Some ICMPv6 messages should only be acceped from
local scope addresses, others should be both local & global scoped.

EG: RS/RA & NS/NA messages should only be acceped when sourced from
a local-scope address & sent to a local-scope or multi-cast addr.
Same goes for the Multicast varients of those messages
(EG Multicast Router Discovery/MRA & Listner Query/Listner Report).
So for this type of message, your destination-prefix-list needs
to contain fe80::/10 & ff00::/8 as well as making sure that the
source address is fe80::/10.

A good source of info on this topic is the NIST IPv6 deployment
guidelines. They have specific chapters dealing with handling
ICMPv6 and multicast traffic. See:
 http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf

In chapter 3 they have a nice table that lists recommended ICMPv6
filtering actions: "must not drop", "should not drop" and should
not transit a router for various message types.

Be aware that each v6 router interface needs both a global-scope
and local-scope address. If you only specify a global-scope address
the router will SLAAC a local-scope address. For debugging & logging
purposes, it's better to specify both so they're deterministic.
EG:
    xe-1/0/0 {
        mtu 9192;
        unit 0 {
            family inet {
                mtu 9178;
                filter {
                    input world-input;
                }
                address 129.255.21.50/30;
            }
            family inet6 {
                mtu 9178;
                filter {
                    input world-input-v6;
                }
                address 2611:0:e50:7016::1/64 {
                    primary;
                }
                address fe80::e50:7016:0:1/64;
            }
        }
    }

I chose the bottom 64 bits of that LinkLocal addr to partially reflect the
global-scope subnet addr so to make it easier to identify packets from the
router when trying to debug problems on clients.

Note that if you're talking to any Microsoft Windows clients be sure that
the top 64 bits of that LinkLocal addr are fe80:: otherwise due to a bug
in their firewall filters they won't hear you. ;(

IE: fe80:0:e50:7016::1 is a legal LinkLocal addr but windows clients
won't 'hear' it (found this out the hard way).

IPv6, it's a whole new challenge.

-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{