Re: restrict implicit binding to interfaces
On Oct 30, 10:57*am, Rick Jones <rick.jon...@hp.com> wrote:
[color=blue][color=green]
> > Traffic to any IP assigned to the machine will, and must, be accepted
> > regardless of what interface it arrives on.[/color][/color]
[color=blue]
> In the weak end system model, yes. *In the strong end system model
> that does not apply. *Some systems (eg HP-UX, perhaps Solaris) allow
> the system to be put into (some variation on the theme of) the strong
> end system model.[/color]
Why would a machine reject a packet:
1) Destined for a non-local address assigned to that machine;
2) That was routed to it by the network; and
3) That is not prohibited by any firewall rule?
Just to break things for the sheer hell of it?
DS
Re: restrict implicit binding to interfaces
David Schwartz <davids@webmaster.com> wrote:[color=blue]
> On Oct 30, 10:57?am, Rick Jones <rick.jon...@hp.com> wrote:[color=green]
> > In the weak end system model, yes. ?In the strong end system model
> > that does not apply. ?Some systems (eg HP-UX, perhaps Solaris)
> > allow the system to be put into (some variation on the theme of)
> > the strong end system model.[/color][/color]
[color=blue]
> Why would a machine reject a packet:[/color]
[color=blue]
> 1) Destined for a non-local address assigned to that machine;
> 2) That was routed to it by the network; and
> 3) That is not prohibited by any firewall rule?
> Just to break things for the sheer hell of it?[/color]
Routing behaviour. End System behavour. Two distinct behaviour sets
which may happen simultaneously in the same sheetmetal. Need to think
of them separately from one another.
As for why the strong end system model exists this may be as good a
starting point as any: [url]http://tools.ietf.org/html/rfc1122[/url]
rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Re: restrict implicit binding to interfaces
On Oct 30, 11:20*am, Rick Jones <rick.jon...@hp.com> wrote:
[color=blue]
> Routing behaviour. *End System behavour. *Two distinct behaviour sets
> which may happen simultaneously in the same sheetmetal. *Need to think
> of them separately from one another.[/color]
I agree. A router cannot assume that a packet it received is probably
for it. But an end system can.
[color=blue]
> As for why the strong end system model exists this may be as good a
> starting point as any:[url]http://tools.ietf.org/html/rfc1122[/url][/color]
Yes, it says:
"Be liberal in what you accept, and
conservative in what you send"
That is, don't throw away a packet when there is only one possible
thing it could mean.
Its only defense is:
With respect to (A), proponents of the Strong ES
model note that automatic Internet routing
mechanisms could not route a datagram to a
physical interface that did not correspond to
the
destination address.
This is in direct defiance to the robustness principle. Ignore
something because it can't happen, even when it most definitely *can*
and *does* happen, as this thread proves.
DS
Re: restrict implicit binding to interfaces
One example of where a strong end system model might be useful would
be a DMZ system. You might not want a server bound to the "internal
IP" to receive traffic routed via the external interface. So, if the
strong end system model is active, it will only accept datagrams
destined to the internal IP on the "internal" interface.
There are of course other ways to arrive at the same end condition -
configure the server application to only accept connections from a
configured range of intenal IP addresses, or setup firewall rules to
drop datagrams arriving on the external interface with the internal IP
as the destination - of course that last one is simply using the
firewall rules to make the system behave as if it were using the
strong end system model :)
rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Re: restrict implicit binding to interfaces
On Oct 31, 10:39*am, Rick Jones <rick.jon...@hp.com> wrote:
[color=blue]
> One example of where a strong end system model might be useful would
> be a DMZ system. *You might not want a server bound to the "internal
> IP" to receive traffic routed via the external interface. *So, if the
> strong end system model is active, it will only accept datagrams
> destined to the internal IP on the "internal" interface.[/color]
Right, but then you'd be trusting the service to bind to the right
place. If you could trust the service to manage its own security, why
wouldn't you want it bound to the external interface?
[color=blue]
> There are of course other ways to arrive at the same end condition -
> configure the server application to only accept connections from a
> configured range of intenal IP addresses, or setup firewall rules to
> drop datagrams arriving on the external interface with the internal IP
> as the destination - of course that last one is simply using the
> firewall rules to make the system behave as if it were using the
> strong end system model :)[/color]
Since a firewall is both necessary and sufficient, what does the
strong end system model add?
DS
Re: restrict implicit binding to interfaces
David Schwartz <davids@webmaster.com> wrote:[color=blue]
> On Oct 31, 10:39?am, Rick Jones <rick.jon...@hp.com> wrote:[color=green]
> > One example of where a strong end system model might be useful would
> > be a DMZ system. ?You might not want a server bound to the "internal
> > IP" to receive traffic routed via the external interface. ?So, if the
> > strong end system model is active, it will only accept datagrams
> > destined to the internal IP on the "internal" interface.[/color][/color]
[color=blue]
> Right, but then you'd be trusting the service to bind to the right
> place. If you could trust the service to manage its own security,
> why wouldn't you want it bound to the external interface?[/color]
Simplicity. If I have a strong end system model all I have to do is
tell the applcation on which IPs it should listen and I'm done. I
don't have to teach it anything further about the topology of my
internal networks.
[color=blue][color=green]
> > There are of course other ways to arrive at the same end condition -
> > configure the server application to only accept connections from a
> > configured range of intenal IP addresses, or setup firewall rules to
> > drop datagrams arriving on the external interface with the internal IP
> > as the destination - of course that last one is simply using the
> > firewall rules to make the system behave as if it were using the
> > strong end system model :)[/color][/color]
[color=blue]
> Since a firewall is both necessary and sufficient, what does the
> strong end system model add?[/color]
Firewalls may be sufficient, but IMO they are only necessary because
we either don't, won't or can't trust application/OS security.
rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Re: restrict implicit binding to interfaces
On Oct 31, 2:06*pm, Rick Jones <rick.jon...@hp.com> wrote:
[color=blue][color=green]
> > Right, but then you'd be trusting the service to bind to the right
> > place. If you could trust the service to manage its own security,
> > why wouldn't you want it bound to the external interface?[/color][/color]
[color=blue]
> Simplicity. *If I have a strong end system model all I have to do is
> tell the applcation on which IPs it should listen and I'm done. *I
> don't have to teach it anything further about the topology of my
> internal networks.[/color]
But that's because you've already taught it everything about the
topology of your internal networks, and you're relying upon that
knowledge for your security.
[color=blue][color=green][color=darkred]
> > > There are of course other ways to arrive at the same end condition -
> > > configure the server application to only accept connections from a
> > > configured range of intenal IP addresses, or setup firewall rules to
> > > drop datagrams arriving on the external interface with the internal IP
> > > as the destination - of course that last one is simply using the
> > > firewall rules to make the system behave as if it were using the
> > > strong end system model :)[/color][/color][/color]
[color=blue][color=green]
> > Since a firewall is both necessary and sufficient, what does the
> > strong end system model add?[/color][/color]
[color=blue]
> Firewalls may be sufficient, but IMO they are only necessary because
> we either don't, won't or can't trust application/OS security.[/color]
We don't trust "accidental security". We only trust engineered
security. So it comes down to whether a strong end system model can be
considered secured by design or just secured by accident.
Frankly, it makes no sense whatsoever to me. It forces you into a
bizarre all-or-nothing decision that relies on the network topology to
provide the security. Worse, it forever prevents the device for
performing any routing functions, which is very limiting because even
traditional end systems often wind up having to do some kinds of
routing functions.
DS
Re: restrict implicit binding to interfaces
David Schwartz <davids@webmaster.com> wrote:[color=blue]
> We don't trust "accidental security". We only trust engineered
> security. So it comes down to whether a strong end system model can
> be considered secured by design or just secured by accident.[/color]
[color=blue]
> Frankly, it makes no sense whatsoever to me. It forces you into a
> bizarre all-or-nothing decision that relies on the network topology to
> provide the security.[/color]
A firewall isn't part of the network topology?
rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...