On 15 November 2013 15:08, Alexander Bluhm wrote:
> On Thu, Nov 14, 2013 at 05:38:14PM -0700, Theo de Raadt wrote:
>> Beautiful.
>
> I seems there was enough discussion. The Security argument is more
> important than the others. The new diff has no performance impact
> when pf is turned on.
>
>
> > >- It is pf's job to add more security.
> > It is. However, you will note that in IPv4 land we have sysctl
> > net.inet.ip.sourceroute. It defaults to 0 (off). RH is like IPv4 source
> > routing, except on steriods. Would any of us at this time recommend
> > net.inet.ip.sourceroute=1, or to
On Thu, Nov 14, 2013 at 05:38:14PM -0700, Theo de Raadt wrote:
> Beautiful.
I seems there was enough discussion. The Security argument is more
important than the others. The new diff has no performance impact
when pf is turned on.
So I need OKs.
bluhm
Index: net/pf.c
=
* Theo de Raadt [2013-11-15 01:38]:
> >My diff was on tech@ for one day during a hackathon before I commited it.
NOT hidden / circulated privately.
> >The reasons why I removed the check in the stack are:
> >- Scanning headers in the forwarding path is against the spirit of IPv6.
> One day someo
>My diff was on tech@ for one day during a hackathon before I commited it.
>Not enough people discussed it back then. Fine. Let's discuss it now.
>
>The reasons why I removed the check in the stack are:
>- Scanning headers in the forwarding path is against the spirit of IPv6.
One day someone sho
On Thu, Nov 14, 2013 at 11:00:37AM -0700, Theo de Raadt wrote:
> It was not shown to enough people. PERIOD.
My diff was on tech@ for one day during a hackathon before I commited it.
Not enough people discussed it back then. Fine. Let's discuss it now.
The reasons why I removed the check in the
* Theo de Raadt [2013-11-14 19:00]:
> > * Theo de Raadt [2013-11-14 18:47]:
> > > > it is the status quo *right now*
> > > Look, you can't call something the status quo when a commit was made 1
> > > month ago, to a REAL status quo that existed for 10 years when itojun
> > > made the change... a
> > we have discussed that with bluhm in berlin and initially i had the same
> > opinion: leave the check in the stack, but he has convinced me that it's
> > rather pf's job to do it. i'm not against bringing it back and his diff
> > looks fine to me, esp. since it avoids double check that was the
On Thu, Nov 14, 2013 at 10:04 PM, Mike Belopuhov wrote:
> On 14 November 2013 18:52, Henning Brauer wrote:
>> * Theo de Raadt [2013-11-14 18:47]:
>>> > it is the status quo *right now*
>>>
>>> Look, you can't call something the status quo when a commit was made 1
>>> month ago, to a REAL status
Mike,
> we have discussed that with bluhm in berlin and initially i had the same
> opinion: leave the check in the stack, but he has convinced me that it's
> rather pf's job to do it.
I agree. If pf is enabled, it can do the job and there is no need for
a second scan.
> i'm not against bringi
On 14 November 2013 18:52, Henning Brauer wrote:
> * Theo de Raadt [2013-11-14 18:47]:
>> > it is the status quo *right now*
>>
>> Look, you can't call something the status quo when a commit was made 1
>> month ago, to a REAL status quo that existed for 10 years when itojun
>> made the change...
> * Theo de Raadt [2013-11-14 18:47]:
> > > it is the status quo *right now*
> >
> > Look, you can't call something the status quo when a commit was made 1
> > month ago, to a REAL status quo that existed for 10 years when itojun
> > made the change... and immediately after this recent commit we
* Theo de Raadt [2013-11-14 18:47]:
> > it is the status quo *right now*
>
> Look, you can't call something the status quo when a commit was made 1
> month ago, to a REAL status quo that existed for 10 years when itojun
> made the change... and immediately after this recent commit we
> started a
> it is the status quo *right now*
Look, you can't call something the status quo when a commit was made 1
month ago, to a REAL status quo that existed for 10 years when itojun
made the change... and immediately after this recent commit we
started arguying about the change.
Go find out what "stat
* Theo de Raadt [2013-11-14 16:35]:
> > * Alexander Bluhm [2013-11-14 01:29]:
> > > Theo and others don't like that change as it decreases security.
> > > There are hosts out there that still process RH0 and there are
> > > OpenBSD routers with pf disabled.
> > >
> > > This diff brings back the
> * Alexander Bluhm [2013-11-14 01:29]:
> > Theo and others don't like that change as it decreases security.
> > There are hosts out there that still process RH0 and there are
> > OpenBSD routers with pf disabled.
> >
> > This diff brings back the header chain scanning. As an improvement
> > it
> I guess it would help people who decide to disable pf for slight
> performance benefit ?
Quite obviously people are doing this on a variety of machines,
such as bgp routers.
* Alexander Bluhm [2013-11-14 01:29]:
> Theo and others don't like that change as it decreases security.
> There are hosts out there that still process RH0 and there are
> OpenBSD routers with pf disabled.
>
> This diff brings back the header chain scanning. As an improvement
> it only scans if
On Thu, Nov 14, 2013 at 4:27 AM, Alexander Bluhm
wrote:
> On Fri, Oct 18, 2013 at 08:45:02PM +0200, Alexander Bluhm wrote:
>> Our IPv6 stack scans all extension headers for routing header type
>> 0 and drops the packet if it finds one. RFC 5095 demands to handle
>> a routing header type 0 like an
On Fri, Oct 18, 2013 at 08:45:02PM +0200, Alexander Bluhm wrote:
> Our IPv6 stack scans all extension headers for routing header type
> 0 and drops the packet if it finds one. RFC 5095 demands to handle
> a routing header type 0 like an unrecognised routing type. This
> is enough to protect the o
Hi,
Our IPv6 stack scans all extension headers for routing header type
0 and drops the packet if it finds one. RFC 5095 demands to handle
a routing header type 0 like an unrecognised routing type. This
is enough to protect the own machine.
To protect a network as a firewall, we have pf which do
21 matches
Mail list logo
