BCP/BCOP for ipv6 deployment and filtering policy
Hello all, I'm trying to deploy IPv6 in a small ISP of Italy (AS203847). While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed. For enterprise there exists RFC7381. Even though there are lot of similarities between enterprise and ISP there exists some differences. Small ISP with less human resource might find security considerations addressed on RFC9099, address planning mentioned in RIPE-690 a bit difficult to follow. So, what is your opinion to create a BCP/BCOP combining all these RFC and make it more easier to follow while deploying IPv6 in an ISP? If something like this already exists or someone already working, it will be really helpful if someone shares. --- Regards Sheikh.
Am 05.10.2024 um 21:11:22 Uhr schrieb Sheikh Md Seum via ipv6-wg:
While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed.
Don't filter it at all at the ISP level for your customers. The neighbor discovery packets can't be abused from other links because they will be discarded when they don't have TTL of 255. Make sure you reject RAs from the customers on your PPP links. Although, inside a link (e.g. on a office network), filtering for certain packages like RA is needed to avoid certain intended or accidental stuff. Other stuff like the destination unreachable must not be blocked at all. ICMPv6 isn't a security risk itself. -- Gruß Marco Send unsolicited bulk mail to 1728155482muell@cartoonies.org
I recommend that you take part in the RIPE IPv6 Security training course at the RIPEAcademy <https://academy.ripe.net/>. One of the topics covered is ICMPv6 filtering (Unit 4). In this unit, you will learn about best practices for filtering and rate limiting certain IPv6 and/or ICMPv6 packets. Rinse On 5-10-2024 21:20, Marco Moock wrote:
Am 05.10.2024 um 21:11:22 Uhr schrieb Sheikh Md Seum via ipv6-wg:
While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed. Don't filter it at all at the ISP level for your customers.
The neighbor discovery packets can't be abused from other links because they will be discarded when they don't have TTL of 255. Make sure you reject RAs from the customers on your PPP links.
Although, inside a link (e.g. on a office network), filtering for certain packages like RA is needed to avoid certain intended or accidental stuff.
Other stuff like the destination unreachable must not be blocked at all.
ICMPv6 isn't a security risk itself.
Am 05.10.2024 um 22:03:43 Uhr schrieb Rinse Kloek:
I recommend that you take part in the RIPE IPv6 Security training course at the RIPEAcademy <https://academy.ripe.net/>. One of the topics covered is ICMPv6 filtering (Unit 4). In this unit, you will learn about best practices for filtering and rate limiting certain IPv6 and/or ICMPv6 packets.
Well' I've done this online course and I can recommend it, but it is only theoretical. E.g. you need to find out on another place how to limit ICMP echo reply messages or destination unreachable. -- kind regards Marco Send unsolicited bulk mail to 1728158623muell@cartoonies.org
Well some months ago I did the course and that's what led to this discussion. I missed that in RFC 9288 it was recommended to drop packet with certain extension header if know that header is not used which I mistakenly got confused with ICMPv6. On 10/5/24 22:03, Rinse Kloek wrote:
I recommend that you take part in the RIPE IPv6 Security training course at the RIPEAcademy <https://academy.ripe.net/>. One of the topics covered is ICMPv6 filtering (Unit 4). In this unit, you will learn about best practices for filtering and rate limiting certain IPv6 and/or ICMPv6 packets.
Rinse
On 5-10-2024 21:20, Marco Moock wrote:
Am 05.10.2024 um 21:11:22 Uhr schrieb Sheikh Md Seum via ipv6-wg:
While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed. Don't filter it at all at the ISP level for your customers.
The neighbor discovery packets can't be abused from other links because they will be discarded when they don't have TTL of 255. Make sure you reject RAs from the customers on your PPP links.
Although, inside a link (e.g. on a office network), filtering for certain packages like RA is needed to avoid certain intended or accidental stuff.
Other stuff like the destination unreachable must not be blocked at all.
ICMPv6 isn't a security risk itself.
----- To unsubscribe from this mailing list or change your subscription options, please visit:https://mailman.ripe.net/mailman3/lists/ipv6-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at:https://www.ripe.net/membership/mail/mailman-3-migration/
-- Regards Sheikh Md Seum
Hi, On Sat, Oct 05, 2024 at 09:20:11PM +0200, Marco Moock wrote:
Am 05.10.2024 um 21:11:22 Uhr schrieb Sheikh Md Seum via ipv6-wg:
While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed.
Don't filter it at all at the ISP level for your customers.
+1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
http://shouldiblockicmp.com/ -----Original message----- Am 05.10.2024 um 21:11:22 Uhr schrieb Sheikh Md Seum via ipv6-wg:
While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed.
Don't filter it at all at the ISP level for your customers. The neighbor discovery packets can't be abused from other links because they will be discarded when they don't have TTL of 255. Make sure you reject RAs from the customers on your PPP links. Although, inside a link (e.g. on a office network), filtering for certain packages like RA is needed to avoid certain intended or accidental stuff. Other stuff like the destination unreachable must not be blocked at all. ICMPv6 isn't a security risk itself. -- Gruß Marco Send unsolicited bulk mail to 1728155482muell@cartoonies.org
Hi, On Sun, Oct 06, 2024 at 11:28:26AM +0200, Michiel Klaver via ipv6-wg wrote:
-----Original message----- Am 05.10.2024 um 21:11:22 Uhr schrieb Sheikh Md Seum via ipv6-wg:
While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed.
Don't filter it at all at the ISP level for your customers.
+1
The neighbor discovery packets can't be abused from other links because they will be discarded when they don't have TTL of 255. Make sure you reject RAs from the customers on your PPP links.
Although, inside a link (e.g. on a office network), filtering for certain packages like RA is needed to avoid certain intended or accidental stuff.
Other stuff like the destination unreachable must not be blocked at all.
ICMPv6 isn't a security risk itself.
Well, (in contrast to IPv4, unfortunately) it is. Else RFC 6105, RFC 6980 et al. wouldn't exist. Some guidance on filtering ICMPv6 in specific situations here: https://labs.ripe.net/author/enno_rey/local-packet-filtering-with-ipv6/ https://theinternetprotocolblog.wordpress.com/2020/11/28/ipv6-security-best-... cheers Enno
-- Gruß Marco
Send unsolicited bulk mail to 1728155482muell@cartoonies.org
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ipv6-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator IPv6 Blog: https://theinternetprotocolblog.wordpress.com
This RIPE Security PDF is also a good starting point: https://www.ripe.net/media/documents/IPv6Security-Slides.pdf <https://www.ripe.net/media/documents/IPv6Security-Slides.pdf> It advises blocking ICMP Type 137 (Redirect) and Type 138 (Route Renumbering). The other types should not be blocked; however, some prefer to rate limit Echo requests/replies (Type 128 and 129). You may want to rate limit these types of requests to your infrastructure nodes or handle them in the control plane on your nodes. Additionally, at the ISP level, you could implement some ingress ACLs such as: * Block everything to documentation address space (RFC3849): |deny ipv6 any 2001:db8::/32 icmp-off| * Block everything to benchmarking address space (RFC5180): |deny ipv6 any 2001:2::/48 icmp-off| * Block everything to Automatic Multicast Tunneling (RFC7450): |deny ipv6 any 2001:3::/32 icmp-off| * Block everything to deprecated ORCHID/ORCHIDv2 (RFC4843/RFC7343): |deny ipv6 any 2001:10::/28 icmp-off| |deny ipv6 any 2001:20::/28 icmp-off| * Block Router Advertisements (RAs): |deny icmpv6 any any router-advertisement icmp-off| * Allow everything else from locally connected internet customers to the IPv6 global unicast space (as a rudimentary/coarse anti-source-IP spoofing measure): |permit ipv6 <YOUR IPv6 space> 2000::/3| I think there are some more you could block, but always be sure you know what's in your filters and change them according to your network requirements. In addition, it's recommended to implement anti-spoofing protection at the ISP level. Only allow traffic from your customers originating from the IP space they were assigned via DHCPv6 or PPPoE. Rinse On 6-10-2024 11:28, Michiel Klaver via ipv6-wg wrote:
-----Original message----- Am 05.10.2024 um 21:11:22 Uhr schrieb Sheikh Md Seum via ipv6-wg:
While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed. Don't filter it at all at the ISP level for your customers.
The neighbor discovery packets can't be abused from other links because they will be discarded when they don't have TTL of 255. Make sure you reject RAs from the customers on your PPP links.
Although, inside a link (e.g. on a office network), filtering for certain packages like RA is needed to avoid certain intended or accidental stuff.
Other stuff like the destination unreachable must not be blocked at all.
ICMPv6 isn't a security risk itself.
Am 06.10.2024 um 17:14:56 Uhr schrieb Rinse Kloek:
*
Block everything to documentation address space (RFC3849): |deny ipv6 any 2001:db8::/32 icmp-off|
Why don't do that at the routing level by routing that net (and some others like fc00::/7) to Null0 (this generates a ICMP routes rejected)? Should be more performant. -- Gruß Marco Send unsolicited bulk mail to 1728227696muell@cartoonies.org
As a side note, there are now *TWO* documentation prefixes: * RFC 3849 2001:db8::/32 * RFC 9637 3fff::/20 -éric From: Rinse Kloek <rinse@kindes.nl> Date: Sunday, 6 October 2024 at 17:15 To: ipv6-wg@ripe.net <ipv6-wg@ripe.net> Subject: [ipv6-wg] Re: BCP/BCOP for ipv6 deployment and filtering policy This RIPE Security PDF is also a good starting point: https://www.ripe.net/media/documents/IPv6Security-Slides.pdf It advises blocking ICMP Type 137 (Redirect) and Type 138 (Route Renumbering). The other types should not be blocked; however, some prefer to rate limit Echo requests/replies (Type 128 and 129). You may want to rate limit these types of requests to your infrastructure nodes or handle them in the control plane on your nodes. Additionally, at the ISP level, you could implement some ingress ACLs such as: · Block everything to documentation address space (RFC3849): deny ipv6 any 2001:db8::/32 icmp-off · Block everything to benchmarking address space (RFC5180): deny ipv6 any 2001:2::/48 icmp-off · Block everything to Automatic Multicast Tunneling (RFC7450): deny ipv6 any 2001:3::/32 icmp-off · Block everything to deprecated ORCHID/ORCHIDv2 (RFC4843/RFC7343): deny ipv6 any 2001:10::/28 icmp-off deny ipv6 any 2001:20::/28 icmp-off · Block Router Advertisements (RAs): deny icmpv6 any any router-advertisement icmp-off · Allow everything else from locally connected internet customers to the IPv6 global unicast space (as a rudimentary/coarse anti-source-IP spoofing measure): permit ipv6 <YOUR IPv6 space> 2000::/3 I think there are some more you could block, but always be sure you know what's in your filters and change them according to your network requirements. In addition, it's recommended to implement anti-spoofing protection at the ISP level. Only allow traffic from your customers originating from the IP space they were assigned via DHCPv6 or PPPoE. Rinse On 6-10-2024 11:28, Michiel Klaver via ipv6-wg wrote: http://shouldiblockicmp.com/ -----Original message----- Am 05.10.2024 um 21:11:22 Uhr schrieb Sheikh Md Seum via ipv6-wg: While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed. Don't filter it at all at the ISP level for your customers. The neighbor discovery packets can't be abused from other links because they will be discarded when they don't have TTL of 255. Make sure you reject RAs from the customers on your PPP links. Although, inside a link (e.g. on a office network), filtering for certain packages like RA is needed to avoid certain intended or accidental stuff. Other stuff like the destination unreachable must not be blocked at all. ICMPv6 isn't a security risk itself.
Moin,
It advises blocking ICMP Type 137 (Redirect) and Type 138 (Route Renumbering). The other types should not be blocked; however, some prefer to rate limit Echo requests/replies (Type 128 and 129). You may want to rate limit these types of requests to your infrastructure nodes or handle them in the control plane on your nodes.
This is a somewhat good point; There is a somewhat annoying corner-case bug between OpenBSD and Linux that can lead to a bit of a packet storm in even more corner-case-y middle box interactions. The problem is, that sending packet-too-big is not rate-limited on Linux; On OpenBSD, there is no rate-limiting of retransmissions. For IPv6 there then is the problem that OpenBSD will retransmit for a packet-too-big signaling the _same_ MTU it already sent a packet for. This means that the OpenBSD box will shell out 'whatever it can' in terms of retransmits, until the connection times out. I hit this so far in two cases: - A middle box that slipped in a fragmentation header for 0 fragments into packets, pushing the framesize by 8b, leading to constant packet- to-big messages for 1476b; Over the Internet, ~50-100mbit sustained for 30-40m outbound from the OpenBSD system - A weird setup where i use iBGP as an IGP with asymetric routing over an asymetric MTU path, where the mismatch between overlay and underlay path lead to the system ignoring the pkt-too-big messages. That one gave 1gbit (link saturation) sustained. Problem here is that you imho do not really want to catch this on your core, as that likely can break more than not. But it might be good to watch for repeated pkt-too-big messages between consistent src/dest touples in one's monitoring, especially if you happen to have a lot of clients. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
Hi, You might also want to look at RFC 4890, though that is enterprise focused. Best wishes, Tim From: Sheikh Md Seum via ipv6-wg <ipv6-wg@ripe.net> Date: Saturday, 5 October 2024 at 20:11 To: ipv6-wg@ripe.net <ipv6-wg@ripe.net> Subject: [ipv6-wg] BCP/BCOP for ipv6 deployment and filtering policy Hello all, I'm trying to deploy IPv6 in a small ISP of Italy (AS203847). While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed. For enterprise there exists RFC7381. Even though there are lot of similarities between enterprise and ISP there exists some differences. Small ISP with less human resource might find security considerations addressed on RFC9099, address planning mentioned in RIPE-690 a bit difficult to follow. So, what is your opinion to create a BCP/BCOP combining all these RFC and make it more easier to follow while deploying IPv6 in an ISP? If something like this already exists or someone already working, it will be really helpful if someone shares. --- Regards Sheikh.
Hi Tim, On Mon, Oct 07, 2024 at 09:03:57AM +0000, Tim Chown via ipv6-wg wrote:
You might also want to look at RFC 4890, though that is enterprise focused.
That serves as a good background for understanding (and maybe for the "enterprise side" of the ISP, namely the backend systems). For "the ISP provides access to the Internet", I would expect my ISP to pass IP packets back and forth, and not apply heuristics on why they would want to drop some of them, based on "enterprise needs this"... (I'm fairly sure we agree on this, but the casual reader on the list might not see this destinction - thus, stressing it) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On 07/10/2024, 10:27, "Gert Doering" <gert@space.net> wrote: Hi Tim, On Mon, Oct 07, 2024 at 09:03:57AM +0000, Tim Chown via ipv6-wg wrote:
You might also want to look at RFC 4890, though that is enterprise focused.
That serves as a good background for understanding (and maybe for the "enterprise side" of the ISP, namely the backend systems). For "the ISP provides access to the Internet", I would expect my ISP to pass IP packets back and forth, and not apply heuristics on why they would want to drop some of them, based on "enterprise needs this"... (I'm fairly sure we agree on this, but the casual reader on the list might not see this destinction - thus, stressing it) Yes, very much agree, as per EHs more generally. Tim Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hello, On 10/7/24 12:46 PM, Tim Chown via ipv6-wg wrote:
Hi,
On 07/10/2024, 10:27, "Gert Doering" <gert@space.net> wrote:
Hi Tim,
On Mon, Oct 07, 2024 at 09:03:57AM +0000, Tim Chown via ipv6-wg wrote:
You might also want to look at RFC 4890, though that is enterprise focused.
That serves as a good background for understanding (and maybe for the
"enterprise side" of the ISP, namely the backend systems).
For "the ISP provides access to the Internet", I would expect my ISP to
pass IP packets back and forth,
Sure but ... no. ISPs drop/limit (as they should) many packets from/to subscribers, packets that are DDoS attack vectors: various UDP amplifications (DNS, NTP Chargen, SNMP, etc), sometimes fragments and you know what? ICMP(v4) also, as has been known to resurface as an attack vector in carpet bombing attacks. I'll be honest, I haven't seen much ICMPv6 used in the same fashion, but there again I haven't seen many IPv6-based DDoS attacks. I always believed that a sane and selective implementation of rfc4890 was not a bad thing, even for ISPs, even for their customers. Cheers, Yannis
and not apply heuristics on why they
would want to drop some of them, based on "enterprise needs this"...
(I'm fairly sure we agree on this, but the casual reader on the list might
not see this destinction - thus, stressing it)
Yes, very much agree, as per EHs more generally.
Tim
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla,
Karin Schuler, Sebastian Cler
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
----- To unsubscribe from this mailing list or change your subscription options, please visit:https://mailman.ripe.net/mailman3/lists/ipv6-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at:https://www.ripe.net/membership/mail/mailman-3-migration/
Hi, On Tue, Oct 15, 2024 at 05:37:16PM +0300, Yannis Nikolopoulos via ipv6-wg wrote:
I always believed that a sane and selective implementation of rfc4890 was not a bad thing, even for ISPs, even for their customers.
"not their job" (I agree with the part of "rate-limiting things that are rarely used in the WAN, if used in DDoS attacks" - like, NTP packets beyond a reasonable threshold) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (10)
-
Enno Rey -
Eric Vyncke (evyncke) -
Gert Doering -
Marco Moock -
Michiel Klaver -
Rinse Kloek -
Sheikh Md Seum -
Tim Chown -
Tobias Fiebig -
Yannis Nikolopoulos