Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
On Sat, 14 Jan 2017 09:58:21 +1100, Mark Andrews said: > In message , Fernando > Gont writes: > > Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been > > several one-packet crashes disclosed for Cisco's (an the list continues). > > And they would have issued fixes for them. Machines get attacked > from inside firewalls. Only idiots do not apply security fixes. Evidence suggests that our industry is highly overstocked with idiots. pgpRjl32KdUaS.pgp Description: PGP signature
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
In message <954a2fbd-580a-044b-07e7-63a0bf1bb...@si6networks.com>, Fernando Gont writes: > On 01/12/2017 11:14 PM, Mark Andrews wrote: > > In message > > > > , Fernando Gont writes: > >> El 12/1/2017 16:32, "Saku Ytti" escribi=C3=B3: > >> > >> On 12 January 2017 at 17:02, Fernando Gont wrote: > >>> That's the point: If you don't allow fragments, but your peer honors > >>> ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > >> > >> Thanks. I think I got it now. Best I can offer is that B could try to > >> verify the embedded original packet? Hopefully attacker won't have > >> access to that information. An if attacker has access to that > >> information, they may as well do TCP RST, right? > >> > >> Didn't we have same issues in IPv4 with ICMP unreachable and frag > >> neeeded, DF set? And vendors implemented more verification if the ICMP > >> message should be accepted. > >> > >> > >> Yes and no. > >> > >> 1) there was no way in v4 to trigger use of fragmentation for an arbitrary > >> flow. > >> > >> 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload. > >> In ipv6, you aren't (think ipv6 EHs) > > > > So drop the packet if you don't get to the end of the extension > > headers in the ICMPv6 payload. Has anyone, except in testing, seen > > a extension header chain that was not fully containable in the > > ICMPv6 payload? > > Because of the extra IPv6+ICMPv6 headers that you need for sending the > ICMP error, even if the original packet did have the entire IPv6 header > chain, you might be unable to include it in the ICMPv6 payload. 1280 - 40 - 8 which give a effective final header fitting in the initial 1252 bytes. Still bigger than header chains that you see in practice today. > Yes, in practice you'd be fine dropping ICMP errors that don't embed a > full payload. Whether vendors do it or not, is a different question. Dropping a payload that don't include the entire header chain. The entire packet is another thing. It is expected to be truncated at 1252 bytes unless you add extension headers to the ICMPv6 packet. > FWIW, it took me 6 years to publish RFC5927. And, because folks > *opposed* to it in tcpm wg, it was published as Informational, rather > than Std Track. RFC4443 points to it, still as informational thing that > you might want to do. > > If we don't convey the right message in specs, not sure we can expect > good implementations, and even less flame the folk that tries to run his > network in the best possible way with "what he gets". As a DNS developer I actually do look at ICMP packets if I don't want to timeout. A PTB can be used to trigger the resend of a DNS query (unlikely but possible). You can also remember that and set IPV6_USE_MIN_MTU=1 on future responses to that client rather than relying on the lower levels of the stack remembering the PTB and adjusting the packet size. You can extract data from the payload like the query id and even the question. You can assume that it is a EDNS response and reconstruct the response to resend assuming that DNS Cookie/TSIG/SIG(0) is not in use as all of that is at the end of the packet. Time exceeded and unreachables can move you onto the next server faster. I have code that does some of that after matching addresses, ports id etc. None of this is hard to do. All of this should be obvious to anyone with a little bit of thinking. Senders know that ICMPv6 packets are limited to 1280 bytes. They can construct their echoed back packets to fit the headers into the available size. They want the traffic to flow and that requires getting back the information to be able to restart the flow. Instead the firewall developers do as little as they can. They don't think about the ramifications of their actions. Mark > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
In message , Fernando Gont writes: > On 01/12/2017 11:07 PM, Mark Andrews wrote: > > In message > > > > , Fernando Gont writes: > >> El 12/1/2017 16:28, "Mark Andrews" escribi=C3=B3: > >> > >>> In message <11ff128d-2fba-7c26-4a9c-5611433d8...@si6networks.com>, > >>> Fernando Gont writes: > Hi, Saku, > > On 01/12/2017 11:43 AM, Saku Ytti wrote: > > On 12 January 2017 at 13:19, Fernando Gont > >>> wrote: > > > > Hey, > > > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > >> welcome). > > > > Generally may be understood differently by different people. If > > generally is defined as single most typical behaviour/configuration, > > then generally people don't protect their infrastructure in any way at > > all, but fully rely vendor doing something reasonable. > > > > I would argue BCP is to have 'strict' CoPP. Where you specifically > > allow what you must then have ultimate rule to deny everything. If you > > have such CoPP, then this attack won't work, as you clearly didn't > > allow any fragments at all (as you didn't expect to receive BGP > > fragments from your neighbours). > > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > >>> > >>> And fragments are a *normal* part of IP for both IPv4 and IPv6. > >>> This obsession with dropping all fragments (and yes it is a obsession) > >>> is breaking the internet. > >> > >> Vendors got the frag reassembly code wrong so many times , that I > >> understand the folk that decides to drop them if deemed unnecessary. > > > > Most of them literally decades ago. > > Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been > several one-packet crashes disclosed for Cisco's (an the list continues). And they would have issued fixes for them. Machines get attacked from inside firewalls. Only idiots do not apply security fixes. > > 20+ years ago while you waited > > for you vendor to fix the bug it made some sense as most of your > > boxes were vulnerable. It was a new threat back then. It doesn't > > make sense today. > > Let's face it: The quality of many IPv6 implementations is that of IPv4 > implementations in the '90s. Sad, but true. Not really. For most of them the two stacks are in basically similar states. Most of the code is shared. > > Packet bigger than 1500 are a part of todays internet. Have a look > > a the stats for dropped fragments. They aren't for the most part > > attack traffic. Its legitmate reply traffic that has been requested. > > I don't disagree with you wrt the need for fragmentation in some > scenarios. I'm just saying that when you only employ TCP-based services, > it may make sense to drop fragments targeted *at you*. > > Fragmentation is only needed for non-TCP services. and if your system > does not use non-tcp services, it may be a sensible thing to drop > fragments targetted at you. Firstly framentation happens with TCP and IPv6 today. Just set IPV6_USE_MIN_MTU on the socket. It shouldn't happen as TCP is supposed to use the MTU information on the socket but it doesn't in many implementations. Secondly there is no site that doesn't use protocols that send fragmentent packets. They will all be using DNS and DNS sends fragmented UDP in its replies. This has been the case since the late 1990's. Mark > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
On 01/12/2017 11:14 PM, Mark Andrews wrote: > In message > > , Fernando Gont writes: >> El 12/1/2017 16:32, "Saku Ytti" escribi=C3=B3: >> >> On 12 January 2017 at 17:02, Fernando Gont wrote: >>> That's the point: If you don't allow fragments, but your peer honors >>> ICMPv6 PTB<1280, then dropping fragments creates the attack vector. >> >> Thanks. I think I got it now. Best I can offer is that B could try to >> verify the embedded original packet? Hopefully attacker won't have >> access to that information. An if attacker has access to that >> information, they may as well do TCP RST, right? >> >> Didn't we have same issues in IPv4 with ICMP unreachable and frag >> neeeded, DF set? And vendors implemented more verification if the ICMP >> message should be accepted. >> >> >> Yes and no. >> >> 1) there was no way in v4 to trigger use of fragmentation for an arbitrary >> flow. >> >> 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload. >> In ipv6, you aren't (think ipv6 EHs) > > So drop the packet if you don't get to the end of the extension > headers in the ICMPv6 payload. Has anyone, except in testing, seen > a extension header chain that was not fully containable in the > ICMPv6 payload? Because of the extra IPv6+ICMPv6 headers that you need for sending the ICMP error, even if the original packet did have the entire IPv6 header chain, you might be unable to include it in the ICMPv6 payload. Yes, in practice you'd be fine dropping ICMP errors that don't embed a full payload. Whether vendors do it or not, is a different question. FWIW, it took me 6 years to publish RFC5927. And, because folks *opposed* to it in tcpm wg, it was published as Informational, rather than Std Track. RFC4443 points to it, still as informational thing that you might want to do. If we don't convey the right message in specs, not sure we can expect good implementations, and even less flame the folk that tries to run his network in the best possible way with "what he gets". Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
On 01/12/2017 11:07 PM, Mark Andrews wrote: > In message > > , Fernando Gont writes: >> El 12/1/2017 16:28, "Mark Andrews" escribi=C3=B3: >> >>> In message <11ff128d-2fba-7c26-4a9c-5611433d8...@si6networks.com>, Fernando >>> Gont writes: Hi, Saku, On 01/12/2017 11:43 AM, Saku Ytti wrote: > On 12 January 2017 at 13:19, Fernando Gont >>> wrote: > > Hey, > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are >> welcome). > > Generally may be understood differently by different people. If > generally is defined as single most typical behaviour/configuration, > then generally people don't protect their infrastructure in any way at > all, but fully rely vendor doing something reasonable. > > I would argue BCP is to have 'strict' CoPP. Where you specifically > allow what you must then have ultimate rule to deny everything. If you > have such CoPP, then this attack won't work, as you clearly didn't > allow any fragments at all (as you didn't expect to receive BGP > fragments from your neighbours). That's the point: If you don't allow fragments, but your peer honors ICMPv6 PTB<1280, then dropping fragments creates the attack vector. >>> >>> And fragments are a *normal* part of IP for both IPv4 and IPv6. >>> This obsession with dropping all fragments (and yes it is a obsession) >>> is breaking the internet. >> >> Vendors got the frag reassembly code wrong so many times , that I >> understand the folk that decides to drop them if deemed unnecessary. > > Most of them literally decades ago. Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been several one-packet crashes disclosed for Cisco's (an the list continues). > 20+ years ago while you waited > for you vendor to fix the bug it made some sense as most of your > boxes were vulnerable. It was a new threat back then. It doesn't > make sense today. Let's face it: The quality of many IPv6 implementations is that of IPv4 implementations in the '90s. Sad, but true. > Packet bigger than 1500 are a part of todays internet. Have a look > a the stats for dropped fragments. They aren't for the most part > attack traffic. Its legitmate reply traffic that has been requested. I don't disagree with you wrt the need for fragmentation in some scenarios. I'm just saying that when you only employ TCP-based services, it may make sense to drop fragments targeted *at you*. Fragmentation is only needed for non-TCP services. and if your system does not use non-tcp services, it may be a sensible thing to drop fragments targetted at you. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
In message , Fernando Gont writes: > El 12/1/2017 16:32, "Saku Ytti" escribi=C3=B3: > > On 12 January 2017 at 17:02, Fernando Gont wrote: > > That's the point: If you don't allow fragments, but your peer honors > > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > > Thanks. I think I got it now. Best I can offer is that B could try to > verify the embedded original packet? Hopefully attacker won't have > access to that information. An if attacker has access to that > information, they may as well do TCP RST, right? > > Didn't we have same issues in IPv4 with ICMP unreachable and frag > neeeded, DF set? And vendors implemented more verification if the ICMP > message should be accepted. > > > Yes and no. > > 1) there was no way in v4 to trigger use of fragmentation for an arbitrary > flow. > > 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload. > In ipv6, you aren't (think ipv6 EHs) So drop the packet if you don't get to the end of the extension headers in the ICMPv6 payload. Has anyone, except in testing, seen a extension header chain that was not fully containable in the ICMPv6 payload? Mark > Thanks, > Fernando -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
In message , Fernando Gont writes: > El 12/1/2017 16:28, "Mark Andrews" escribi=C3=B3: > > > In message <11ff128d-2fba-7c26-4a9c-5611433d8...@si6networks.com>, Fernando > > Gont writes: > > > Hi, Saku, > > > > > > On 01/12/2017 11:43 AM, Saku Ytti wrote: > > > > On 12 January 2017 at 13:19, Fernando Gont > > wrote: > > > > > > > > Hey, > > > > > > > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > > > >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > > > >> welcome). > > > > > > > > Generally may be understood differently by different people. If > > > > generally is defined as single most typical behaviour/configuration, > > > > then generally people don't protect their infrastructure in any way at > > > > all, but fully rely vendor doing something reasonable. > > > > > > > > I would argue BCP is to have 'strict' CoPP. Where you specifically > > > > allow what you must then have ultimate rule to deny everything. If you > > > > have such CoPP, then this attack won't work, as you clearly didn't > > > > allow any fragments at all (as you didn't expect to receive BGP > > > > fragments from your neighbours). > > > > > > That's the point: If you don't allow fragments, but your peer honors > > > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > > > > And fragments are a *normal* part of IP for both IPv4 and IPv6. > > This obsession with dropping all fragments (and yes it is a obsession) > > is breaking the internet. > > Vendors got the frag reassembly code wrong so many times , that I > understand the folk that decides to drop them if deemed unnecessary. Most of them literally decades ago. 20+ years ago while you waited for you vendor to fix the bug it made some sense as most of your boxes were vulnerable. It was a new threat back then. It doesn't make sense today. Packet bigger than 1500 are a part of todays internet. Have a look a the stats for dropped fragments. They aren't for the most part attack traffic. Its legitmate reply traffic that has been requested. > > Even if you don't want to allow all fragments through you can allow > > fragments between the two endpoints of a "active" connection. > > > > > At times folks want to get rid of fragments directed to them, rather than > > those going *through* them. > > > > > > You > > can apply port filters to the offset 0 fragments. If that fragment > > doesn't have enough headers to be able to filter then drop it. If > > your firewall is incapable of doing this then find a better firewall > > as the current one is a piece of garbage and should be in the recycle > > bin. > > > Which DoS is the bigger issue? Firewalls dropping fragments or > > reassembly buffers being exhausted? > > > > If there is no way for an attacker to trigger the use of fragmentation, and > > you don't need fragments (e.g. only tcp-based services), from a security > > pov you're certainly better off dropping frags that are thrown at you. Not > > that I like it, but > > Thanks, > Fernando > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
El 12/1/2017 16:32, "Saku Ytti" escribió: On 12 January 2017 at 17:02, Fernando Gont wrote: > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. Thanks. I think I got it now. Best I can offer is that B could try to verify the embedded original packet? Hopefully attacker won't have access to that information. An if attacker has access to that information, they may as well do TCP RST, right? Didn't we have same issues in IPv4 with ICMP unreachable and frag neeeded, DF set? And vendors implemented more verification if the ICMP message should be accepted. Yes and no. 1) there was no way in v4 to trigger use of fragmentation for an arbitrary flow. 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload. In ipv6, you aren't (think ipv6 EHs) Thanks, Fernando
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
El 12/1/2017 16:28, "Mark Andrews" escribió: In message <11ff128d-2fba-7c26-4a9c-5611433d8...@si6networks.com>, Fernando Gon t writes: > Hi, Saku, > > On 01/12/2017 11:43 AM, Saku Ytti wrote: > > On 12 January 2017 at 13:19, Fernando Gont wrote: > > > > Hey, > > > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > >> welcome). > > > > Generally may be understood differently by different people. If > > generally is defined as single most typical behaviour/configuration, > > then generally people don't protect their infrastructure in any way at > > all, but fully rely vendor doing something reasonable. > > > > I would argue BCP is to have 'strict' CoPP. Where you specifically > > allow what you must then have ultimate rule to deny everything. If you > > have such CoPP, then this attack won't work, as you clearly didn't > > allow any fragments at all (as you didn't expect to receive BGP > > fragments from your neighbours). > > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. And fragments are a *normal* part of IP for both IPv4 and IPv6. This obsession with dropping all fragments (and yes it is a obsession) is breaking the internet. Vendors got the frag reassembly code wrong so many times , that I understand the folk that decides to drop them if deemed unnecessary. Even if you don't want to allow all fragments through you can allow fragments between the two endpoints of a "active" connection. At times folks want to get rid of fragments directed to them, rather than those going *through* them. You can apply port filters to the offset 0 fragments. If that fragment doesn't have enough headers to be able to filter then drop it. If your firewall is incapable of doing this then find a better firewall as the current one is a piece of garbage and should be in the recycle bin. Which DoS is the bigger issue? Firewalls dropping fragments or reassembly buffers being exhausted? If there is no way for an attacker to trigger the use of fragmentation, and you don't need fragments (e.g. only tcp-based services), from a security pov you're certainly better off dropping frags that are thrown at you. Not that I like it, but Thanks, Fernando
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
On 12 January 2017 at 21:53, Fernando Gont wrote: > besides, becaude of ipv6 ehs, you're not really guaranteed to receive e.g. > the tcp header in the embedded payload (the embedded payload could easily be > fixed ipv6 header + ehs). If the CoPP drops what has not been explicitly allowed, then packets with EH should be dropped. Particularly if you're not allowing 'tcp' but you're allowing 'next-header tcp'. I.e. the real BGP session (that attacker is trying to disrupt) would not have EH, on account that it would not come up if it had. But I agree if you do need and do use EH, things can get really dirty really fast, fundamentally no one implements standard compliant IPv6, if we're insisting that even pathological EH chains should work (which is fair viewpoint, while not one that I share). Maybe embedded flow-label could used to add confidence ICMP message is for packet we've actually sent? Make flow-label hash, a'la syn cookie. Spooffed ICMP message to disrupt existing TCP isn't novel. Coincidentally one service I use stopped working yesterday, but just for me, after short debugging, there was route cache entry on the server for my client ip which needed to be flushed, perhaps ended up there due to rogue ICMP redirect. -- ++ytti
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
Many (most?) Implementations don't even check the embedded port numbers...do tye attacker does not even need to guess the client port. besides, becaude of ipv6 ehs, you're not really guaranteed to receive e.g. the tcp header in the embedded payload (the embedded payload could easily be fixed ipv6 header + ehs). Cheers, Fernando El 12/1/2017 16:32, "Saku Ytti" escribió: > On 12 January 2017 at 17:02, Fernando Gont wrote: > > That's the point: If you don't allow fragments, but your peer honors > > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > > Thanks. I think I got it now. Best I can offer is that B could try to > verify the embedded original packet? Hopefully attacker won't have > access to that information. An if attacker has access to that > information, they may as well do TCP RST, right? > > Didn't we have same issues in IPv4 with ICMP unreachable and frag > neeeded, DF set? And vendors implemented more verification if the ICMP > message should be accepted. > > -- > ++ytti >
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
On 12 January 2017 at 17:02, Fernando Gont wrote: > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. Thanks. I think I got it now. Best I can offer is that B could try to verify the embedded original packet? Hopefully attacker won't have access to that information. An if attacker has access to that information, they may as well do TCP RST, right? Didn't we have same issues in IPv4 with ICMP unreachable and frag neeeded, DF set? And vendors implemented more verification if the ICMP message should be accepted. -- ++ytti
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
In message <11ff128d-2fba-7c26-4a9c-5611433d8...@si6networks.com>, Fernando Gon t writes: > Hi, Saku, > > On 01/12/2017 11:43 AM, Saku Ytti wrote: > > On 12 January 2017 at 13:19, Fernando Gont wrote: > > > > Hey, > > > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > >> welcome). > > > > Generally may be understood differently by different people. If > > generally is defined as single most typical behaviour/configuration, > > then generally people don't protect their infrastructure in any way at > > all, but fully rely vendor doing something reasonable. > > > > I would argue BCP is to have 'strict' CoPP. Where you specifically > > allow what you must then have ultimate rule to deny everything. If you > > have such CoPP, then this attack won't work, as you clearly didn't > > allow any fragments at all (as you didn't expect to receive BGP > > fragments from your neighbours). > > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. And fragments are a *normal* part of IP for both IPv4 and IPv6. This obsession with dropping all fragments (and yes it is a obsession) is breaking the internet. Even if you don't want to allow all fragments through you can allow fragments between the two endpoints of a "active" connection. You can apply port filters to the offset 0 fragments. If that fragment doesn't have enough headers to be able to filter then drop it. If your firewall is incapable of doing this then find a better firewall as the current one is a piece of garbage and should be in the recycle bin. Which DoS is the bigger issue? Firewalls dropping fragments or reassembly buffers being exhausted? Yes, firewalls dropping fragments is a denial of service attack. The initial TCP exchange does not contain fragments. Most UDP protocols don't start with a packet that will need to be fragmented. For other protocols YMMV. Mark > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
Hi, Saku, On 01/12/2017 11:43 AM, Saku Ytti wrote: > On 12 January 2017 at 13:19, Fernando Gont wrote: > > Hey, > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are >> welcome). > > Generally may be understood differently by different people. If > generally is defined as single most typical behaviour/configuration, > then generally people don't protect their infrastructure in any way at > all, but fully rely vendor doing something reasonable. > > I would argue BCP is to have 'strict' CoPP. Where you specifically > allow what you must then have ultimate rule to deny everything. If you > have such CoPP, then this attack won't work, as you clearly didn't > allow any fragments at all (as you didn't expect to receive BGP > fragments from your neighbours). That's the point: If you don't allow fragments, but your peer honors ICMPv6 PTB<1280, then dropping fragments creates the attack vector. -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
On 12 January 2017 at 13:19, Fernando Gont wrote: Hey, > I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > welcome). Generally may be understood differently by different people. If generally is defined as single most typical behaviour/configuration, then generally people don't protect their infrastructure in any way at all, but fully rely vendor doing something reasonable. I would argue BCP is to have 'strict' CoPP. Where you specifically allow what you must then have ultimate rule to deny everything. If you have such CoPP, then this attack won't work, as you clearly didn't allow any fragments at all (as you didn't expect to receive BGP fragments from your neighbours). -- ++ytti
ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
Folks, I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 and/or IPv6 fragments targeted to BGP routers (off-list datapoints are welcome). In any case, you mind find it worth reading to check if you're affected (from Section 2 of recently-published RFC8021): cut here The security implications of IP fragmentation have been discussed at length in [RFC6274] and [RFC7739]. An attacker can leverage the generation of IPv6 atomic fragments to trigger the use of fragmentation in an arbitrary IPv6 flow (in scenarios in which actual fragmentation of packets is not needed) and can subsequently perform any type of fragmentation-based attack against legacy IPv6 nodes that do not implement [RFC6946]. That is, employing fragmentation where not actually needed allows for fragmentation-based attack vectors to be employed, unnecessarily. We note that, unfortunately, even nodes that already implement [RFC6946] can be subject to DoS attacks as a result of the generation of IPv6 atomic fragments. Let us assume that Host A is communicating with Host B and that, as a result of the widespread dropping of IPv6 packets that contain extension headers (including fragmentation) [RFC7872], some intermediate node filters fragments between Host B and Host A. If an attacker sends a forged ICMPv6 PTB error message to Host B, reporting an MTU smaller than 1280, this will trigger the generation of IPv6 atomic fragments from that moment on (as required by [RFC2460]). When Host B starts sending IPv6 atomic fragments (in response to the received ICMPv6 PTB error message), these packets will be dropped, since we previously noted that IPv6 packets with extension headers were being dropped between Host B and Host A. Thus, this situation will result in a DoS scenario. Another possible scenario is that in which two BGP peers are employing IPv6 transport and they implement Access Control Lists (ACLs) to drop IPv6 fragments (to avoid control-plane attacks). If the aforementioned BGP peers drop IPv6 fragments but still honor received ICMPv6 PTB error messages, an attacker could easily attack the corresponding peering session by simply sending an ICMPv6 PTB message with a reported MTU smaller than 1280 bytes. Once the attack packet has been sent, the aforementioned routers will themselves be the ones dropping their own traffic. cut here Is this something waiting to be exploited? Am I missing something? Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
