Mailing List Archive

Hi,

> Is there a good online resource for IPv6 firewall policy/hardening for MX series routers?

I would start with the IPv6 filter example starting on page 336 of Juniper MX Series, 2nd Edition (ISBN: 978-1-4919-3272-8). There are eBook versions available, and o'Reilly Safari gives you online access. See https://www.juniper.net/us/en/training/jnbooks/oreilly-juniper-library/mx-series/.

If you have the 1st edition it should be around page 260.

Cheers,
Sander

2nd edition page 332 "IPv6 RE Protection Filter"

-Aaron


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

It's a good start but there are many issues with it.

I think you need to take some time to understand IPv6 before implementing.
The book examples don't restrict RS/RA to link local, are too open on
things like BGP and traceroute. Trio hardware also has payload-protocol
available in addition to next-header for matching.

The IETF opsec-v6 draft is a useful resource to begin with

https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/


On Fri, 28 Jun 2019, 20:28 Aaron Gould, <aaron1@gvtc.com> wrote:

> 2nd edition page 332 "IPv6 RE Protection Filter"
>
> -Aaron
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hey Lee,

> I think you need to take some time to understand IPv6 before implementing.
> The book examples don't restrict RS/RA to link local, are too open on
> things like BGP and traceroute. Trio hardware also has payload-protocol
> available in addition to next-header for matching.

I don't think there is any need to. We've troubleshooted many outages
caused by customers limiting NS/NA to link-local or GUA, which may
work and may stop working when one end changes.

Robust and secure rule would be something like:

term icmp:nd {
from {
next-header icmp6;
icmp-type [ router-solicit router-advertisement
neighbor-solicit neighbor-advertisement ];
hop-limit 255;
}
then {
count icmp:nd;
accept;
}
}
term icmp {
from {
next-header icmp6;
icmp-type [ echo-reply echo-request time-exceeded
destination-unreachable packet-too-big parameter-problem ];
}
then {
policer police_local;
count icmp;
accept;
}
}

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

>
>
>
> > I think you need to take some time to understand IPv6 before
> implementing.
> > The book examples don't restrict RS/RA to link local, are too open on
> > things like BGP and traceroute. Trio hardware also has payload-protocol
> > available in addition to next-header for matching.
>
> I don't think there is any need to. We've troubleshooted many outages
> caused by customers limiting NS/NA to link-local or GUA, which may
> work and may stop working when one end changes.
>

Hi Ytti

I have been using prefixes but of course, I missed the obvious solution
here - matching on hop-limit 255.


> Robust and secure rule would be something like:
>
> term icmp:nd {
> from {
> next-header icmp6;
> icmp-type [ router-solicit router-advertisement
> neighbor-solicit neighbor-advertisement ];
> hop-limit 255;
> }
> then {
> count icmp:nd;
> accept;
> }
> }
> term icmp {
> from {
> next-header icmp6;
> icmp-type [ echo-reply echo-request time-exceeded
> destination-unreachable packet-too-big parameter-problem ];
> }
> then {
> policer police_local;
> count icmp;
> accept;
> }
> }
>
>

Thanks for this.

>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp