Re: Backport facebook IPv6 routing table PMTU exception patch

2016-12-22 Thread Ben Hutchings
On Thu, 2016-12-22 at 14:37 -0800, Rumen Telbizov wrote:
> Thank you for your answer Ben.
> 
> I might have to consider switching over to 4.7/4.8 then.
> In that regard I was wondering what the support level for those newer
> kernels from jessie-backports is? Can I count on the same level of
> maintenance from Debian as 3.16 has? That is - security fixes will be
> backported just like for 3.16 for the lifetime of jessie, or 4.8 will be
> replaced by 4.9 and so on, thus sticking with the next upstream kernel.

jessie-backports follows what goes into stretch.  Since we expect to
release stretch with Linux 4.9, both stretch and jessie-backports
should settle down soon.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin



signature.asc
Description: This is a digitally signed message part


Re: Backport facebook IPv6 routing table PMTU exception patch

2016-12-22 Thread Rumen Telbizov
Thank you for your answer Ben.

I might have to consider switching over to 4.7/4.8 then.
In that regard I was wondering what the support level for those newer
kernels from jessie-backports is? Can I count on the same level of
maintenance from Debian as 3.16 has? That is - security fixes will be
backported just like for 3.16 for the lifetime of jessie, or 4.8 will be
replaced by 4.9 and so on, thus sticking with the next upstream kernel.

Regards,

On Wed, Dec 21, 2016 at 11:09 PM, Ben Hutchings  wrote:

> On Wed, 2016-12-21 at 13:14 -0800, Rumen Telbizov wrote:
> [...]
> > Due to the severity of this, I was wondering if you could consider
> > backporting that patch for the 3.16 kernel as well?
> >
> > Additional details regarding the patch are available at:
> > https://code.facebook.com/posts/1123882380960538/linux-
> ipv6-improvement-routing-cache-on-demand/
>
> Having read that page, this sounds much too risky to try backporting.
>
> Ben.
>
> --
> Ben Hutchings
> Man invented language to satisfy his deep need to complain. - Lily
> Tomlin
>
>


-- 
Rumen Telbizov
Unix Systems Administrator 


Re: Backport facebook IPv6 routing table PMTU exception patch

2016-12-21 Thread Ben Hutchings
On Wed, 2016-12-21 at 13:14 -0800, Rumen Telbizov wrote:
[...]
> Due to the severity of this, I was wondering if you could consider
> backporting that patch for the 3.16 kernel as well?
>
> Additional details regarding the patch are available at:
> https://code.facebook.com/posts/1123882380960538/linux-ipv6-improvement-routing-cache-on-demand/

Having read that page, this sounds much too risky to try backporting.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin



signature.asc
Description: This is a digitally signed message part


Re: Backport facebook IPv6 routing table PMTU exception patch

2016-12-21 Thread Ozgur Karatas
21.12.2016, 23:59, "Rumen Telbizov" :Hello, The original patch has been put together against 4.1/4.2 kernel and as such will probably need to be modified to work on 3.16. While I could try adapt it and patch my kernel, this would mean that going forward I'll need to maintain this and keep patching and rebuilding after every change from Debian. Not ideal. Moreover, no other Debian jessie 3.16 user would benefit from the fix. Again, even today users could run the 4.7 from backports and benefit from the patch but how many do that? I would assume that most users will run the default 3.16 which leaves them exposed to this DoS scenario. In short, if Debian maintains the patch all jessie IPv6 users running default kernel will benefit from this going forward. Thank you for your feedback and consideration. Regards,Rumen Telbizov Dear Telbizov; you are very right and please don't understand me wrong, I'm not a Debian maintainer :) but I just explain my idea. I think, maintainer's will be taken into your consideration. Thanks for information, Regards ~Ozgur

Re: Backport facebook IPv6 routing table PMTU exception patch

2016-12-21 Thread Rumen Telbizov
Hello,

The original patch has been put together against 4.1/4.2 kernel and as such
will probably need to be modified to work on 3.16. While I could try adapt
it and patch my kernel, this would mean that going forward I'll need to
maintain this and keep patching and rebuilding after every change from
Debian. Not ideal. Moreover, no other Debian jessie 3.16 user would benefit
from the fix.

Again, even today users could run the 4.7 from backports and benefit from
the patch but how many do that? I would assume that most users will run the
default 3.16 which leaves them exposed to this DoS scenario.

In short, if Debian maintains the patch all jessie IPv6 users running
default kernel will benefit from this going forward.

Thank you for your feedback and consideration.

Regards,
Rumen Telbizov

On Wed, Dec 21, 2016 at 1:22 PM, Ozgur Karatas 
wrote:

> Hello,
>
> As you have mentioned this patchset has already been reported for the
> linux-kernel.
> For now, you can patch to kernel and run udpflood and test to systems.
>
> The bug only module -not kernel-, I think, you can use the kernel module
> and fix it.
>
> http://www.spinics.net/lists/netdev/msg301225.html
>
> Thanks for report.
>
> Regards,
>
> ~Ozgur
>
> 21.12.2016, 23:14, "Rumen Telbizov" :
>
> Dear Debian kernel maintainers,
>
> This might be a long shot but I decided to ask here anyway. If nothing
> else I hope to bring more awareness.
>
> The current kernel in Debian Jessie (3.16) is prone to a
> resource-exhaustion attack against its IPv6 routing table. In short, every
> time a packet from a new IPv6 peer is received an entry is created in the
> IPv6 routing table. This serves as a cache (although it's in the same
> table) so that MTU and other parameters are stored on a per-peer basis.
> This creates the potential for an attacker to quickly fill up the table by
> sending packets from different source addresses. The effect is that as the
> table gets full the garbage collector starts running back-to-back using
> 100% system CPU causing the system to degrade rapidly.
>
> The above is my understanding anyway and might be partially incorrect.
>
> Facebook has contributed a patch which skips the creation of a new entry
> if the MTU is the same as the default route (which is almost always the
> case), thus keeping the table small. Unfortunately that patch has been
> introduced sometime after 4.1-4.2 kernels and is not present in the default
> Debian Jessie kernel. It does seem to be fixed in the 4.7 from backports.
>
> Due to the severity of this, I was wondering if you could consider
> backporting that patch for the 3.16 kernel as well?
>
> Additional details regarding the patch are available at:
> https://code.facebook.com/posts/1123882380960538/linux-
> ipv6-improvement-routing-cache-on-demand/
>
> ​Regards,​
> --
> Rumen Telbizov
> Unix Systems Administrator 
>
>


-- 
Rumen Telbizov
Unix Systems Administrator 


Re: Backport facebook IPv6 routing table PMTU exception patch

2016-12-21 Thread Ozgur Karatas
Hello, As you have mentioned this patchset has already been reported for the linux-kernel.For now, you can patch to kernel and run udpflood and test to systems. The bug only module -not kernel-, I think, you can use the kernel module and fix it. http://www.spinics.net/lists/netdev/msg301225.html Thanks for report. Regards, ~Ozgur 21.12.2016, 23:14, "Rumen Telbizov" :Dear Debian kernel maintainers,This might be a long shot but I decided to ask here anyway. If nothing else I hope to bring more awareness.The current kernel in Debian Jessie (3.16) is prone to a resource-exhaustion attack against its IPv6 routing table. In short, every time a packet from a new IPv6 peer is received an entry is created in the IPv6 routing table. This serves as a cache (although it's in the same table) so that MTU and other parameters are stored on a per-peer basis. This creates the potential for an attacker to quickly fill up the table by sending packets from different source addresses. The effect is that as the table gets full the garbage collector starts running back-to-back using 100% system CPU causing the system to degrade rapidly.The above is my understanding anyway and might be partially incorrect.Facebook has contributed a patch which skips the creation of a new entry if the MTU is the same as the default route (which is almost always the case), thus keeping the table small. Unfortunately that patch has been introduced sometime after 4.1-4.2 kernels and is not present in the default Debian Jessie kernel. It does seem to be fixed in the 4.7 from backports. Due to the severity of this, I was wondering if you could consider backporting that patch for the 3.16 kernel as well?Additional details regarding the patch are available at: https://code.facebook.com/posts/1123882380960538/linux-ipv6-improvement-routing-cache-on-demand/ ​Regards,​--Rumen TelbizovUnix Systems Administrator

Backport facebook IPv6 routing table PMTU exception patch

2016-12-21 Thread Rumen Telbizov
Dear Debian kernel maintainers,

This might be a long shot but I decided to ask here anyway. If nothing else
I hope to bring more awareness.

The current kernel in Debian Jessie (3.16) is prone to a
resource-exhaustion attack against its IPv6 routing table. In short, every
time a packet from a new IPv6 peer is received an entry is created in the
IPv6 routing table. This serves as a cache (although it's in the same
table) so that MTU and other parameters are stored on a per-peer basis.
This creates the potential for an attacker to quickly fill up the table by
sending packets from different source addresses. The effect is that as the
table gets full the garbage collector starts running back-to-back using
100% system CPU causing the system to degrade rapidly.

The above is my understanding anyway and might be partially incorrect.

Facebook has contributed a patch which skips the creation of a new entry if
the MTU is the same as the default route (which is almost always the case),
thus keeping the table small. Unfortunately that patch has been introduced
sometime after 4.1-4.2 kernels and is not present in the default Debian
Jessie kernel. It does seem to be fixed in the 4.7 from backports.

Due to the severity of this, I was wondering if you could consider
backporting that patch for the 3.16 kernel as well?

Additional details regarding the patch are available at:
https://code.facebook.com/posts/1123882380960538/linux-ipv6-improvement-routing-cache-on-demand/

​Regards,​
-- 
Rumen Telbizov
Unix Systems Administrator