netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Namespaces and inetpeer
@ 2012-03-10 13:25 Herbert Xu
  2012-03-12  8:57 ` Steffen Klassert
  0 siblings, 1 reply; 7+ messages in thread
From: Herbert Xu @ 2012-03-10 13:25 UTC (permalink / raw)
  To: David S. Miller, netdev

Hi:

While looking through the inetpeer code I noticed that there is
no namespace support at all.  This means that metric and other
information will be leaking across namespaces.  As IP addresses
are meant to be independent between them, this is not a good thing.

We need to get the namespace folks to fix this.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Namespaces and inetpeer
  2012-03-10 13:25 Namespaces and inetpeer Herbert Xu
@ 2012-03-12  8:57 ` Steffen Klassert
  2012-03-12  9:35   ` David Miller
  2012-03-12 12:11   ` Herbert Xu
  0 siblings, 2 replies; 7+ messages in thread
From: Steffen Klassert @ 2012-03-12  8:57 UTC (permalink / raw)
  To: Herbert Xu; +Cc: David S. Miller, netdev

On Sun, Mar 11, 2012 at 12:25:29AM +1100, Herbert Xu wrote:
> Hi:
> 
> While looking through the inetpeer code I noticed that there is
> no namespace support at all.  This means that metric and other
> information will be leaking across namespaces.  As IP addresses
> are meant to be independent between them, this is not a good thing.
> 

Actually, it would be nice if we could have an inetpeer base per
fib table. This would imply namespace awareness and it would
handle the problem when we have mulitiple routes (with different
metrics etc.) to the same ip address on policy routing.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Namespaces and inetpeer
  2012-03-12  8:57 ` Steffen Klassert
@ 2012-03-12  9:35   ` David Miller
  2012-03-12  9:58     ` Steffen Klassert
  2012-03-12 12:11   ` Herbert Xu
  1 sibling, 1 reply; 7+ messages in thread
From: David Miller @ 2012-03-12  9:35 UTC (permalink / raw)
  To: steffen.klassert; +Cc: herbert, netdev

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 12 Mar 2012 09:57:56 +0100

> On Sun, Mar 11, 2012 at 12:25:29AM +1100, Herbert Xu wrote:
>> Hi:
>> 
>> While looking through the inetpeer code I noticed that there is
>> no namespace support at all.  This means that metric and other
>> information will be leaking across namespaces.  As IP addresses
>> are meant to be independent between them, this is not a good thing.
>> 
> 
> Actually, it would be nice if we could have an inetpeer base per
> fib table. This would imply namespace awareness and it would
> handle the problem when we have mulitiple routes (with different
> metrics etc.) to the same ip address on policy routing.

Then you will ask for one per security policy too, to handle IPSEC.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Namespaces and inetpeer
  2012-03-12  9:35   ` David Miller
@ 2012-03-12  9:58     ` Steffen Klassert
  2012-03-12 10:05       ` David Miller
  0 siblings, 1 reply; 7+ messages in thread
From: Steffen Klassert @ 2012-03-12  9:58 UTC (permalink / raw)
  To: David Miller; +Cc: herbert, netdev

On Mon, Mar 12, 2012 at 02:35:05AM -0700, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Mon, 12 Mar 2012 09:57:56 +0100
> 
> > On Sun, Mar 11, 2012 at 12:25:29AM +1100, Herbert Xu wrote:
> >> Hi:
> >> 
> >> While looking through the inetpeer code I noticed that there is
> >> no namespace support at all.  This means that metric and other
> >> information will be leaking across namespaces.  As IP addresses
> >> are meant to be independent between them, this is not a good thing.
> >> 
> > 
> > Actually, it would be nice if we could have an inetpeer base per
> > fib table. This would imply namespace awareness and it would
> > handle the problem when we have mulitiple routes (with different
> > metrics etc.) to the same ip address on policy routing.
> 
> Then you will ask for one per security policy too, to handle IPSEC.

Hm, I don't see why this would be needed too.

It was just an idea to handle the metrcis with policy routing.
Better ideas are very welcome of course :)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Namespaces and inetpeer
  2012-03-12  9:58     ` Steffen Klassert
@ 2012-03-12 10:05       ` David Miller
  0 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2012-03-12 10:05 UTC (permalink / raw)
  To: steffen.klassert; +Cc: herbert, netdev

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 12 Mar 2012 10:58:40 +0100

> On Mon, Mar 12, 2012 at 02:35:05AM -0700, David Miller wrote:
>> Then you will ask for one per security policy too, to handle IPSEC.
> 
> Hm, I don't see why this would be needed too.

Oh, that's right, we use independent kmalloc'd metrics for IPSEC
routes.

> It was just an idea to handle the metrcis with policy routing.

Right :-)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Namespaces and inetpeer
  2012-03-12  8:57 ` Steffen Klassert
  2012-03-12  9:35   ` David Miller
@ 2012-03-12 12:11   ` Herbert Xu
  2012-03-13  9:41     ` Steffen Klassert
  1 sibling, 1 reply; 7+ messages in thread
From: Herbert Xu @ 2012-03-12 12:11 UTC (permalink / raw)
  To: Steffen Klassert; +Cc: David S. Miller, netdev

On Mon, Mar 12, 2012 at 09:57:56AM +0100, Steffen Klassert wrote:
>
> Actually, it would be nice if we could have an inetpeer base per
> fib table. This would imply namespace awareness and it would
> handle the problem when we have mulitiple routes (with different
> metrics etc.) to the same ip address on policy routing.

How would you handle incoming ICMP need-to-frag messages?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Namespaces and inetpeer
  2012-03-12 12:11   ` Herbert Xu
@ 2012-03-13  9:41     ` Steffen Klassert
  0 siblings, 0 replies; 7+ messages in thread
From: Steffen Klassert @ 2012-03-13  9:41 UTC (permalink / raw)
  To: Herbert Xu; +Cc: David S. Miller, netdev

On Mon, Mar 12, 2012 at 11:11:30PM +1100, Herbert Xu wrote:
> On Mon, Mar 12, 2012 at 09:57:56AM +0100, Steffen Klassert wrote:
> >
> > Actually, it would be nice if we could have an inetpeer base per
> > fib table. This would imply namespace awareness and it would
> > handle the problem when we have mulitiple routes (with different
> > metrics etc.) to the same ip address on policy routing.
> 
> How would you handle incoming ICMP need-to-frag messages?
> 

I thought we could do a (reverse) lookup for the fib table
on incomming ICMP messages. While this would probaply work
if the source address etc. was used as the lookup key for the
initial fib table lookup, this is a real problem if a netfilter
mark was used as the lookup key.

While looking closer at this issue, I've got some doubts if we
ever handled the metrics correct when we choose the fib tables
based on marks. And indeed, in this case it never really worked.
When we updated the mtu based on an incomming ICMP from a certain
IP address, all routes to this ip address used this updated mtu.

If we choose the fib table based on source addresses, it worked as
long as we cached the metrics in the routing cache entries.
While we probaply could fix this case, I don't see how we can handle
the metrics when the initial fib table lookup is base on marks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-03-13  9:41 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-10 13:25 Namespaces and inetpeer Herbert Xu
2012-03-12  8:57 ` Steffen Klassert
2012-03-12  9:35   ` David Miller
2012-03-12  9:58     ` Steffen Klassert
2012-03-12 10:05       ` David Miller
2012-03-12 12:11   ` Herbert Xu
2012-03-13  9:41     ` Steffen Klassert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).