Proposal: qpidd to listen on multiple network interfaces

[Andrew Stitcher <as...@redhat.com>]

I've been working on getting the qpid C++ broker to listen only on specific
network interfaces if that is desired.

Currently there is no way to restrict the network interfaces that qpidd
listens to there are currently 2 broker command line options (and
corresponding config file settings and environment variables):
--port [default 5672] & --ssl-port [default 5671].
With these the broker will listen on all network interfaces to these
ports.

The proposal:

* New option setting --interface

Introduce a new command line option --interface (and corresponding
config file settings and environment variables). This option may be
repeated to indicate multiple listening endpoints. If --interface is not
specified at all then the behaviour is as before - listening on all
interfaces for both amqp and amqps (if configured). If even a single
interface is specified then we don't attempt to listen on all interfaces
anymore.

* Specifying interfaces:

Interfaces can be specified as either an interface name or an address
which must be a local address of an interface.

If the interface name is used then every address associated with that
interface will be used.

If a literal address is used it can be specified as usual for IPv4 (eg
127.0.0.1), but if an IPv6 address is specified it must be enclosed in
square braces ("[" and "]") (eq [::1]).

If --interface is specified then there are 2 possibilities:

* Specifying just an interface

For example --interface em1 or --interface 127.0.0.1 or
--interface [::1].

In this case the broker will listen on the specified interface on both
ports (regular and ssl) as required.

* Specifying an interface and a port

For example --interface wlan0:5672 or --interface 127.0.0.1:465 or
--interface [fe80::3e97:eff:fe14:bbc1%em1]:12002

In this case the broker will only listen on the specified port but will
listen for both regular and ssl connections on the same port.

* Error behaviour

The broker may be unable (for whatever reason) to listen on the
specified ports (Perhaps the specified network interface doesn't exist;
perhaps the specified address isn't actually an address of a connected
interface etc.). In this case we will not fall back to listening on
every network interface - the assumption here is that specifying some
interfaces is a deliberate restriction, quite possibly for security
reasons and so we must "fail safe" and not expose the broker to
potentially hostile network traffic because of a misconfiguration.

I'm keen to hear any comments.

Ideally I'd like to get some of this work into 0.20. And as the
behaviour is backward compatible I think that's feasible.

Andrew





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proposal: qpidd to listen on multiple network interfaces

[Florian Weimer <fw...@redhat.com>]

On 11/15/2012 03:50 PM, Andrew Stitcher wrote:
> On Thu, 2012-11-15 at 11:18 +0100, Florian Weimer wrote:
>> On 11/13/2012 11:44 PM, Andrew Stitcher wrote:
>>> I've been working on getting the qpid C++ broker to listen only on specific
>>> network interfaces if that is desired.
>>
>> I think that this isn't possible on most systems because IP addresses
>> belong to the system, not individual interfaces.  But I think that it is
>> sufficient to explain in the documentation that configuring interfaces
>> only affects the addresses picked up by Qpid, and does not directly
>> prevent hosts on other interfaces from connecting to the service.
>>
>
> I'm not sure I understand what you are saying here: Network interfaces
> have configured addresses and you can discover which addresses are
> configured to which interfaces - on Unix one user command that can do
> this is "ifconfig". So listening on a network interface is equivalent to
> listening on all interfaces of that interface.

"Listening to an interface" sounds like the system will only accept 
connections which arrive on that interface.  This is not the case 
because most systems follow the weak end system model, and unless 
host-based packet filters are configured, any address is reachable over 
any interface (including 127.0.0.1).

>> Do you intend to retry periodically, checking if the configured
>> interface has come up?  I think NetworkManager can generate events which
>> would help with that.  But other software does this as well (ntpd, for
>> example).
>
> That is not intended (at this point in any case) as I'm not aware of any
> portable (POSIX or even Win32) way of being notified of an address
> appearing.

Windows has APIs for that:

<http://msdn.microsoft.com/en-us/library/windows/desktop/aa366071%28v=vs.85%29.aspx>

I don't think POSIX standardizes anything related to network interfaces, 
so you're stuck with non-portable APIs anyway.

 > It certainly is a factor to consider, I must admin I'm not
> sure what the current behaviour would be for interfaces that come up
> during the running of qpidd. If you are listening on the "any" address
> do you get incoming connections on interfaces that appear after you are
> started?

If you listen on 0.0.0.0/::, a service becomes reachable on any 
additional addresses the host might receive.

-- 
Florian Weimer / Red Hat Product Security Team

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proposal: qpidd to listen on multiple network interfaces

[Andrew Stitcher <as...@redhat.com>]

On Thu, 2012-11-15 at 11:18 +0100, Florian Weimer wrote:
> On 11/13/2012 11:44 PM, Andrew Stitcher wrote:
> > I've been working on getting the qpid C++ broker to listen only on specific
> > network interfaces if that is desired.
> 
> I think that this isn't possible on most systems because IP addresses 
> belong to the system, not individual interfaces.  But I think that it is 
> sufficient to explain in the documentation that configuring interfaces 
> only affects the addresses picked up by Qpid, and does not directly 
> prevent hosts on other interfaces from connecting to the service.
> 

I'm not sure I understand what you are saying here: Network interfaces
have configured addresses and you can discover which addresses are
configured to which interfaces - on Unix one user command that can do
this is "ifconfig". So listening on a network interface is equivalent to
listening on all interfaces of that interface.

It is true that this is assuming that addresses are fixed to interfaces
which is not strictly true, but for many server type cases is true
enough. See your other point below.

> > * Error behaviour
> >
> > The broker may be unable (for whatever reason) to listen on the
> > specified ports (Perhaps the specified network interface doesn't exist;
> > perhaps the specified address isn't actually an address of a connected
> > interface etc.). In this case we will not fall back to listening on
> > every network interface - the assumption here is that specifying some
> > interfaces is a deliberate restriction, quite possibly for security
> > reasons and so we must "fail safe" and not expose the broker to
> > potentially hostile network traffic because of a misconfiguration.
> 
> Do you intend to retry periodically, checking if the configured 
> interface has come up?  I think NetworkManager can generate events which 
> would help with that.  But other software does this as well (ntpd, for 
> example).

That is not intended (at this point in any case) as I'm not aware of any
portable (POSIX or even Win32) way of being notified of an address
appearing. It certainly is a factor to consider, I must admin I'm not
sure what the current behaviour would be for interfaces that come up
during the running of qpidd. If you are listening on the "any" address
do you get incoming connections on interfaces that appear after you are
started?

Andrew
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proposal: qpidd to listen on multiple network interfaces

[Florian Weimer <fw...@redhat.com>]

On 11/13/2012 11:44 PM, Andrew Stitcher wrote:
> I've been working on getting the qpid C++ broker to listen only on specific
> network interfaces if that is desired.

I think that this isn't possible on most systems because IP addresses 
belong to the system, not individual interfaces.  But I think that it is 
sufficient to explain in the documentation that configuring interfaces 
only affects the addresses picked up by Qpid, and does not directly 
prevent hosts on other interfaces from connecting to the service.

> * Error behaviour
>
> The broker may be unable (for whatever reason) to listen on the
> specified ports (Perhaps the specified network interface doesn't exist;
> perhaps the specified address isn't actually an address of a connected
> interface etc.). In this case we will not fall back to listening on
> every network interface - the assumption here is that specifying some
> interfaces is a deliberate restriction, quite possibly for security
> reasons and so we must "fail safe" and not expose the broker to
> potentially hostile network traffic because of a misconfiguration.

Do you intend to retry periodically, checking if the configured 
interface has come up?  I think NetworkManager can generate events which 
would help with that.  But other software does this as well (ntpd, for 
example).

-- 
Florian Weimer / Red Hat Product Security Team

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proposal: qpidd to listen on multiple network interfaces

[Andrew Stitcher <as...@redhat.com>]

On Wed, 2012-11-14 at 16:14 +0100, Jakub Scholz wrote:
> Actually, I do not care so much about the internal port which currently
> allows regular connections only - should it allowed both, it will be not an
> issue. The important part is to allow only SSL on the external network. The
> reason is that a) we do not want external customers to connect unencrypted
> and b) on SSL we can easily disable the username/password access and allow
> only certificate based authentication.
> 
> So if we get instead of the three options (ssl-only, regular-only and both)
> only two options - both and ssl-only - it would be fine for us. It would
> then work as a kind of "minimal security level".

Yep, that answers the question.

Thanks

I wonder if there is any good reason to only want a non encrypted
connection.

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proposal: qpidd to listen on multiple network interfaces

[Jakub Scholz <ja...@scholz.cz>]

Actually, I do not care so much about the internal port which currently
allows regular connections only - should it allowed both, it will be not an
issue. The important part is to allow only SSL on the external network. The
reason is that a) we do not want external customers to connect unencrypted
and b) on SSL we can easily disable the username/password access and allow
only certificate based authentication.

So if we get instead of the three options (ssl-only, regular-only and both)
only two options - both and ssl-only - it would be fine for us. It would
then work as a kind of "minimal security level".

Did this answered your question?

Regards
Jakub


On Wed, Nov 14, 2012 at 3:39 PM, Andrew Stitcher <as...@redhat.com>wrote:

> On Wed, 2012-11-14 at 00:00 +0100, Jakub Scholz wrote:
> > ...
> > For example on some of our brokers we have one
> > network interface which connects the broker to our internal network and
> > where we would like to use regular (non SSL) port only. The second
> > interface connects our external customers which always use only SSL.
>
> Just a quick question about the internal ports that accept non-SSL
> connections: Would there be any reason why you specifically would want
> to accept SSL on these ports as well as TCP?
>
> I'm thinking that the perhaps the options should be by default to accept
> both TCP and SSL. And with a specific option to drop the TCP and only
> accept SSL - some sort of encrypted connection only option.
>
> What do you think?
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Proposal: qpidd to listen on multiple network interfaces

[Andrew Stitcher <as...@redhat.com>]

On Wed, 2012-11-14 at 00:00 +0100, Jakub Scholz wrote:
> ...
> For example on some of our brokers we have one
> network interface which connects the broker to our internal network and
> where we would like to use regular (non SSL) port only. The second
> interface connects our external customers which always use only SSL.

Just a quick question about the internal ports that accept non-SSL
connections: Would there be any reason why you specifically would want
to accept SSL on these ports as well as TCP?

I'm thinking that the perhaps the options should be by default to accept
both TCP and SSL. And with a specific option to drop the TCP and only
accept SSL - some sort of encrypted connection only option.

What do you think?

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proposal: qpidd to listen on multiple network interfaces

[Jakub Scholz <ja...@scholz.cz>]

Hi Alan,

In my opinion, this sounds also acceptable ...

Regards
Jakub


On Fri, Nov 30, 2012 at 5:54 PM, Alan Conway <ac...@redhat.com> wrote:

> On Wed, 2012-11-14 at 09:37 +0100, Jakub Scholz wrote:
> > Hi Andrew,
> >
> > Honestly, the first question I asked my self was how to specify it ... I
> do
> > not think I have some great solution :-(.
> >
> > My best idea was to kind of reuse the URLs from the clients .... i.e.
> > --interface=ssl:eth0:5671 for ssl only, --interface=tcp:eth0:5672 for
> > regular only and --interface=eth0:1234 for both. Yes, I agree this might
> be
> > more complicated to parse and configure. Also, it will be more
> complicated
> > to "verify" a consistent configuration and test the whole change, because
> > you have to expect that at least few people would
> > enter --interface=ssl:eth0:5671 and --interface=eth0:5671 at the same
> time.
> >
>
> Another possibility:
> --interface-ssl=foo    # only SSL
> --interface-no-ssl=foo # only non-SSL
> --interface=foo        # both
> It's a bit clunky but it doesn't complicate the URL syntax and it can be
> added in a backward compatible way after --interface has been
> implemented.
>
> > Regards
> > Jakub
> >
> >
> > On Wed, Nov 14, 2012 at 4:51 AM, Andrew Stitcher <astitcher@redhat.com
> >wrote:
> >
> > > On Wed, 2012-11-14 at 00:00 +0100, Jakub Scholz wrote:
> > > > Hi Andrew,
> > > >
> > > > It is not clear to me from your proposal whether I can specify
> multiple
> > > > interfaces to listen on. Can I pass multiple "interface=..." options
> in
> > > the
> > > > config file in the same way I can use multiple "log-level=..."
> options?
> > >
> > > Yes you can use multiple "interface" options.
> > >
> > > >
> > > > Also I think it would be great if I can distinguish between SSL and
> PLAIN
> > > > on different interfaces. For example on some of our brokers we have
> one
> > > > network interface which connects the broker to our internal network
> and
> > > > where we would like to use regular (non SSL) port only. The second
> > > > interface connects our external customers which always use only SSL.
> > > Right
> > > > now we use firewall to allow only regular port from internal network
> and
> > > > only SSL port from external. But it would be nice to have the
> interface
> > > > feature support this scenario.
> > >
> > > This capability is not part of this proposal, although I agree it is a
> > > useful one. The major reason I've not included it here is that I can't
> > > think of any good (and fairly simple) way of specifying this on a per
> > > --interface option level.
> > >
> > > I also think that this capability can be added later as another
> backward
> > > compatible option once we decide the best way to specify it.
> > >
> > > At the moment my thoughts on this are either extending the --interface
> > > syntax, but I don't want it to be too fiddly to understand or parse;
> > > inventing a new option to specify tcp only or ssl only on given
> > > interfaces (perhaps something like --tcp-only <interface> or --ssl-only
> > > <interface> repeated as necessary); something else?
> > >
> > > Thanks for the comments.
> > >
> > > Andrew
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Proposal: qpidd to listen on multiple network interfaces

[Alan Conway <ac...@redhat.com>]

On Wed, 2012-11-14 at 09:37 +0100, Jakub Scholz wrote:
> Hi Andrew,
> 
> Honestly, the first question I asked my self was how to specify it ... I do
> not think I have some great solution :-(.
> 
> My best idea was to kind of reuse the URLs from the clients .... i.e.
> --interface=ssl:eth0:5671 for ssl only, --interface=tcp:eth0:5672 for
> regular only and --interface=eth0:1234 for both. Yes, I agree this might be
> more complicated to parse and configure. Also, it will be more complicated
> to "verify" a consistent configuration and test the whole change, because
> you have to expect that at least few people would
> enter --interface=ssl:eth0:5671 and --interface=eth0:5671 at the same time.
> 

Another possibility:
--interface-ssl=foo    # only SSL
--interface-no-ssl=foo # only non-SSL
--interface=foo        # both
It's a bit clunky but it doesn't complicate the URL syntax and it can be
added in a backward compatible way after --interface has been
implemented.

> Regards
> Jakub
> 
> 
> On Wed, Nov 14, 2012 at 4:51 AM, Andrew Stitcher <as...@redhat.com>wrote:
> 
> > On Wed, 2012-11-14 at 00:00 +0100, Jakub Scholz wrote:
> > > Hi Andrew,
> > >
> > > It is not clear to me from your proposal whether I can specify multiple
> > > interfaces to listen on. Can I pass multiple "interface=..." options in
> > the
> > > config file in the same way I can use multiple "log-level=..." options?
> >
> > Yes you can use multiple "interface" options.
> >
> > >
> > > Also I think it would be great if I can distinguish between SSL and PLAIN
> > > on different interfaces. For example on some of our brokers we have one
> > > network interface which connects the broker to our internal network and
> > > where we would like to use regular (non SSL) port only. The second
> > > interface connects our external customers which always use only SSL.
> > Right
> > > now we use firewall to allow only regular port from internal network and
> > > only SSL port from external. But it would be nice to have the interface
> > > feature support this scenario.
> >
> > This capability is not part of this proposal, although I agree it is a
> > useful one. The major reason I've not included it here is that I can't
> > think of any good (and fairly simple) way of specifying this on a per
> > --interface option level.
> >
> > I also think that this capability can be added later as another backward
> > compatible option once we decide the best way to specify it.
> >
> > At the moment my thoughts on this are either extending the --interface
> > syntax, but I don't want it to be too fiddly to understand or parse;
> > inventing a new option to specify tcp only or ssl only on given
> > interfaces (perhaps something like --tcp-only <interface> or --ssl-only
> > <interface> repeated as necessary); something else?
> >
> > Thanks for the comments.
> >
> > Andrew
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proposal: qpidd to listen on multiple network interfaces

[Jakub Scholz <ja...@scholz.cz>]

Hi Andrew,

Honestly, the first question I asked my self was how to specify it ... I do
not think I have some great solution :-(.

My best idea was to kind of reuse the URLs from the clients .... i.e.
--interface=ssl:eth0:5671 for ssl only, --interface=tcp:eth0:5672 for
regular only and --interface=eth0:1234 for both. Yes, I agree this might be
more complicated to parse and configure. Also, it will be more complicated
to "verify" a consistent configuration and test the whole change, because
you have to expect that at least few people would
enter --interface=ssl:eth0:5671 and --interface=eth0:5671 at the same time.

Regards
Jakub


On Wed, Nov 14, 2012 at 4:51 AM, Andrew Stitcher <as...@redhat.com>wrote:

> On Wed, 2012-11-14 at 00:00 +0100, Jakub Scholz wrote:
> > Hi Andrew,
> >
> > It is not clear to me from your proposal whether I can specify multiple
> > interfaces to listen on. Can I pass multiple "interface=..." options in
> the
> > config file in the same way I can use multiple "log-level=..." options?
>
> Yes you can use multiple "interface" options.
>
> >
> > Also I think it would be great if I can distinguish between SSL and PLAIN
> > on different interfaces. For example on some of our brokers we have one
> > network interface which connects the broker to our internal network and
> > where we would like to use regular (non SSL) port only. The second
> > interface connects our external customers which always use only SSL.
> Right
> > now we use firewall to allow only regular port from internal network and
> > only SSL port from external. But it would be nice to have the interface
> > feature support this scenario.
>
> This capability is not part of this proposal, although I agree it is a
> useful one. The major reason I've not included it here is that I can't
> think of any good (and fairly simple) way of specifying this on a per
> --interface option level.
>
> I also think that this capability can be added later as another backward
> compatible option once we decide the best way to specify it.
>
> At the moment my thoughts on this are either extending the --interface
> syntax, but I don't want it to be too fiddly to understand or parse;
> inventing a new option to specify tcp only or ssl only on given
> interfaces (perhaps something like --tcp-only <interface> or --ssl-only
> <interface> repeated as necessary); something else?
>
> Thanks for the comments.
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Proposal: qpidd to listen on multiple network interfaces

[Andrew Stitcher <as...@redhat.com>]

On Wed, 2012-11-14 at 00:00 +0100, Jakub Scholz wrote:
> Hi Andrew,
> 
> It is not clear to me from your proposal whether I can specify multiple
> interfaces to listen on. Can I pass multiple "interface=..." options in the
> config file in the same way I can use multiple "log-level=..." options?

Yes you can use multiple "interface" options.

> 
> Also I think it would be great if I can distinguish between SSL and PLAIN
> on different interfaces. For example on some of our brokers we have one
> network interface which connects the broker to our internal network and
> where we would like to use regular (non SSL) port only. The second
> interface connects our external customers which always use only SSL. Right
> now we use firewall to allow only regular port from internal network and
> only SSL port from external. But it would be nice to have the interface
> feature support this scenario.

This capability is not part of this proposal, although I agree it is a
useful one. The major reason I've not included it here is that I can't
think of any good (and fairly simple) way of specifying this on a per
--interface option level.

I also think that this capability can be added later as another backward
compatible option once we decide the best way to specify it.

At the moment my thoughts on this are either extending the --interface
syntax, but I don't want it to be too fiddly to understand or parse;
inventing a new option to specify tcp only or ssl only on given
interfaces (perhaps something like --tcp-only <interface> or --ssl-only
<interface> repeated as necessary); something else?

Thanks for the comments.

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proposal: qpidd to listen on multiple network interfaces

[Jakub Scholz <ja...@scholz.cz>]

Hi Andrew,

It is not clear to me from your proposal whether I can specify multiple
interfaces to listen on. Can I pass multiple "interface=..." options in the
config file in the same way I can use multiple "log-level=..." options?

Also I think it would be great if I can distinguish between SSL and PLAIN
on different interfaces. For example on some of our brokers we have one
network interface which connects the broker to our internal network and
where we would like to use regular (non SSL) port only. The second
interface connects our external customers which always use only SSL. Right
now we use firewall to allow only regular port from internal network and
only SSL port from external. But it would be nice to have the interface
feature support this scenario.

Thanks & Regards
Jakub


On Tue, Nov 13, 2012 at 11:44 PM, Andrew Stitcher <as...@redhat.com>wrote:

> I've been working on getting the qpid C++ broker to listen only on specific
> network interfaces if that is desired.
>
> Currently there is no way to restrict the network interfaces that qpidd
> listens to there are currently 2 broker command line options (and
> corresponding config file settings and environment variables):
> --port [default 5672] & --ssl-port [default 5671].
> With these the broker will listen on all network interfaces to these
> ports.
>
> The proposal:
>
> * New option setting --interface
>
> Introduce a new command line option --interface (and corresponding
> config file settings and environment variables). This option may be
> repeated to indicate multiple listening endpoints. If --interface is not
> specified at all then the behaviour is as before - listening on all
> interfaces for both amqp and amqps (if configured). If even a single
> interface is specified then we don't attempt to listen on all interfaces
> anymore.
>
> * Specifying interfaces:
>
> Interfaces can be specified as either an interface name or an address
> which must be a local address of an interface.
>
> If the interface name is used then every address associated with that
> interface will be used.
>
> If a literal address is used it can be specified as usual for IPv4 (eg
> 127.0.0.1), but if an IPv6 address is specified it must be enclosed in
> square braces ("[" and "]") (eq [::1]).
>
> If --interface is specified then there are 2 possibilities:
>
> * Specifying just an interface
>
> For example --interface em1 or --interface 127.0.0.1 or
> --interface [::1].
>
> In this case the broker will listen on the specified interface on both
> ports (regular and ssl) as required.
>
> * Specifying an interface and a port
>
> For example --interface wlan0:5672 or --interface 127.0.0.1:465 or
> --interface [fe80::3e97:eff:fe14:bbc1%em1]:12002
>
> In this case the broker will only listen on the specified port but will
> listen for both regular and ssl connections on the same port.
>
> * Error behaviour
>
> The broker may be unable (for whatever reason) to listen on the
> specified ports (Perhaps the specified network interface doesn't exist;
> perhaps the specified address isn't actually an address of a connected
> interface etc.). In this case we will not fall back to listening on
> every network interface - the assumption here is that specifying some
> interfaces is a deliberate restriction, quite possibly for security
> reasons and so we must "fail safe" and not expose the broker to
> potentially hostile network traffic because of a misconfiguration.
>
> I'm keen to hear any comments.
>
> Ideally I'd like to get some of this work into 0.20. And as the
> behaviour is backward compatible I think that's feasible.
>
> Andrew
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Proposal: qpidd to listen on multiple network interfaces

[Justin Ross <jr...@redhat.com>]

On Tue, 13 Nov 2012, Andrew Stitcher wrote:

[snip]

> Ideally I'd like to get some of this work into 0.20. And as the
> behaviour is backward compatible I think that's feasible.

I've reviewed this and discussed it with Andrew.  I favor including it for 
0.20.

Justin


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org