restrict implicit binding to interfaces - Networking

This is a discussion on restrict implicit binding to interfaces - Networking ; Say I have 4 interfaces, eth0, eth1, tun0, ppp0. On the system there are to be running several deamons, which shall be bound to all interfaces, except ppp0. One way to do this, is binding them explicitly to eth{0,1}, tun0 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 28

Thread: restrict implicit binding to interfaces

  1. restrict implicit binding to interfaces

    Say I have 4 interfaces, eth0, eth1, tun0, ppp0. On the system
    there are to be running several deamons, which shall be bound to
    all interfaces, except ppp0. One way to do this, is binding them
    explicitly to eth{0,1}, tun0 only. If however a program is
    hardcoded to be bound to all interfaces or the configuration
    code has a bug, then it might be bound to ppp0, too, which is,
    what I want to prevent.

    Also Say I have some daemon, which shall listen on ppp0, so just
    closing of ppp0 using iptables is not what I want.

    How can I do that, I mean: If a program requests to be bound to a
    certain interface explicitly, then and only then it bound to
    that interface. Otherwise it's just bound implicitly to the not
    restricted interfaces.

    Any ideas?

    In the particular case it's a proxy server (the deamon is not
    buggy, so explicit binding works, but I'd like to have some
    fallback). Squid shall listen only to the internal network, so
    it can't be abused from outside. But there's a also a OpenVPN
    running for incomming connections, to enable a route to the
    storage server which won't permit incomming connections from the
    internet. And then the system shall be also ordinary router,
    routing traffic into the subnet (which is a public IP address
    space). I know, that using paravirtualization and some network
    trickery would do the trick, but I'd like to do it on a single
    logical host.

    However I considered to use a small UML process, that would
    contain the ppp0 device, so that this one has it's own router.

    Wolfgang Draxinger
    --
    E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867


  2. Re: restrict implicit binding to interfaces

    On Oct 29, 4:13*am, Wolfgang Draxinger
    wrote:

    > How can I do that, I mean: If a program requests to be bound to a
    > certain interface explicitly, then and only then it bound to
    > that interface. Otherwise it's just bound implicitly to the not
    > restricted interfaces.


    Programs don't bind to interfaces. Your question doesn't make any
    sense.

    > In the particular case it's a proxy server (the deamon is not
    > buggy, so explicit binding works, but I'd like to have some
    > fallback). Squid shall listen only to the internal network, so
    > it can't be abused from outside.


    Programs don't listen to networks. Again, your question doesn't make
    any sense.

    > But there's a also a OpenVPN
    > running for incomming connections, to enable a route to the
    > storage server which won't permit incomming connections from the
    > internet. And then the system shall be also ordinary router,
    > routing traffic into the subnet (which is a public IP address
    > space). I know, that using paravirtualization and some network
    > trickery would do the trick, but I'd like to do it on a single
    > logical host.
    >
    > However I considered to use a small UML process, that would
    > contain the ppp0 device, so that this one has it's own router.


    Can you state precisely what it is you are trying to do? What is the
    rule for whether a connection should or should not be allowed to the
    proxy?

    You seem to be under the misconception that addresses belong to
    interfaces. They don't under Linux, they belong to the machine as a
    whole. When you bind to an address, you accept packets sent to that
    address regardless of what interface they arrive on. Otherwise, it
    would be impossible to set up a functional router.

    DS

  3. Re: restrict implicit binding to interfaces

    David Schwartz wrote:
    > On Oct 29, 4:13 am, Wolfgang Draxinger
    > wrote:
    >
    >> How can I do that, I mean: If a program requests to be bound to a
    >> certain interface explicitly, then and only then it bound to
    >> that interface. Otherwise it's just bound implicitly to the not
    >> restricted interfaces.

    >
    > Programs don't bind to interfaces. Your question doesn't make any
    > sense.
    >
    >> In the particular case it's a proxy server (the deamon is not
    >> buggy, so explicit binding works, but I'd like to have some
    >> fallback). Squid shall listen only to the internal network, so
    >> it can't be abused from outside.

    >
    > Programs don't listen to networks. Again, your question doesn't make
    > any sense.
    >
    >> But there's a also a OpenVPN
    >> running for incomming connections, to enable a route to the
    >> storage server which won't permit incomming connections from the
    >> internet. And then the system shall be also ordinary router,
    >> routing traffic into the subnet (which is a public IP address
    >> space). I know, that using paravirtualization and some network
    >> trickery would do the trick, but I'd like to do it on a single
    >> logical host.
    >>
    >> However I considered to use a small UML process, that would
    >> contain the ppp0 device, so that this one has it's own router.

    >
    > Can you state precisely what it is you are trying to do? What is the
    > rule for whether a connection should or should not be allowed to the
    > proxy?


    I think what he's asking is how he can control on what addresses an app
    listener opens a socket. Most apps open sockets on 0.0.0.0 (i.e., every
    interface) by default. Some let you specify listening addresses. He
    appears to want a way to designate some interfaces as "restricted" and
    others as "not restricted" so that apps open listeners on the "not
    restricted" interfaces by default, but can open listeners on the
    "restricted" interfaces if their configs specifically request it.

    I doubt that what he wants is possible. It would take rethinking the
    call to open a socket at the API in order to apply to apps (e.g., ntpd)
    that don't let you specify listening on only some addresses. (I
    understand there have been flame wars over ntpd on this point. I only
    use it as an example, not as a spark for another war.)

    > You seem to be under the misconception that addresses belong to
    > interfaces. They don't under Linux, they belong to the machine as a
    > whole. When you bind to an address, you accept packets sent to that
    > address regardless of what interface they arrive on. Otherwise, it
    > would be impossible to set up a functional router.


  4. Re: restrict implicit binding to addresses

    David Schwartz wrote:

    >> How can I do that, I mean: If a program requests to be bound
    >> to a certain interface explicitly, then and only then it bound
    >> to that interface. Otherwise it's just bound implicitly to the
    >> not restricted interfaces.

    >
    > Programs don't bind to interfaces. Your question doesn't make
    > any sense.


    s/interface/address/ then. Well in my case that's equivalent
    (for IPv4), as two of the networks (read, logical networks,
    address/netmask level) use private IP address ranges, thus
    my wrong naming. I'm thinking mostly in secure and insecure
    interfaces right now.

    (Anyway, some programs _do_ bind to interfaces, think about
    dhcpd; alas, that's on the raw level).

    >> In the particular case it's a proxy server (the deamon is not
    >> buggy, so explicit binding works, but I'd like to have some
    >> fallback). Squid shall listen only to the internal network, so
    >> it can't be abused from outside.

    >
    > Programs don't listen to networks. Again, your question doesn't
    > make any sense.


    With network I didn't mean physical network, but logical
    network like in IP subnet.

    > Can you state precisely what it is you are trying to do? What
    > is the rule for whether a connection should or should not be
    > allowed to the proxy?


    If a socket is bound to a port only, it will listen to connection
    attempts on all addresses of the machine. One can of course bind
    to certain addresses explicitly.

    Now I'd like, that programs/sockets not bound to a certain address
    won't get an incomming connection for all but a set of selected
    addresses, whereas programs/sockets bound explicitly to an address
    not in that set, will get a connection.

    Let's have a look at `netstat -lnp` on one of my private
    systems that has two interfaces/addresses on separate subnets
    (in this case the interfaces are also connected to those
    physical networks in which the machines are using addresses
    from the assigned subnet). It's not the system I'm referring
    to, but it makes a good example case. Two networks, where
    some logical segregation makes sense, but the machine itself
    is also router between both networks.

    192.168.1./24
    192.168.2./24

    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
    tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 6188/smbd
    tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 6188/smbd
    tcp6 0 0 192.168.1.2:53 :::* LISTEN 6172/dnscache
    tcp6 0 0 :::22 :::* LISTEN 11152/sshd
    udp 0 0 0.0.0.0:137 0.0.0.0:* 6198/nmbd
    udp 0 0 0.0.0.0:138 0.0.0.0:* 6198/nmbd
    udp 0 0 0.0.0.0:123 0.0.0.0:* 6224/ntpd
    udp6 0 0 127.0.0.1:53 :::* 6166/tinydns
    udp6 0 0 192.168.1.2:53 :::* 6172/dnscache
    udp6 0 0 fe80::2e0:81ff:feb3:123 :::* 6224/ntpd
    udp6 0 0 ::1:123 :::* 6224/ntpd
    udp6 0 0 :::123 :::* 6224/ntpd

    You can see, that there's a program dnscache, listening on .1.2:53
    Using a interface based iptables rule it's easy to block all
    incoming connection requests from (sub)nets not designated to
    that interface. No problems there. In this case dnscache is
    bound to a specific address explicitly, because it must so.
    The same goes for tinydns, which is turn cached by dnscache.

    Now there's also a Samba and a NTP running on the system. And
    those are not bound explicitly to a certain address. What I'd
    like to have, independent of ports on which a socket listens,
    is that all sockets, which are not bound to an address explicitly,
    behave as if the had been bound to a preselected set of addresses,
    and that addresses only, so that programs, that can't be configured
    to listen on specific addresses, or a buggy won't attach to those.

    A iptables makes it then easy to block all traffic from a certain
    interface, designated to that set of addresses.

    The machine will be something like a major data storage and exchange
    hub, providing services for private internal and public external
    users, but only certain services/programs shall be made public.
    Normally one would do that using separate machines or
    paravirtualization. In that case it was ruled out for performance
    reasons: huge DB, full access to the RDBS from two intern
    (sub)networks (physical and logical), access from extern network
    only through special proxy daemons.

    > You seem to be under the misconception that addresses belong to
    > interfaces.


    Nah, I'm just sketching out stuff on the physical level for 2
    weeks now, and I seem to default into thinking and writing that
    way ATM.

    Wolfgang Draxinger
    --
    E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867


  5. Re: restrict implicit binding to interfaces

    Allen Kistler wrote:

    > I think what he's asking is how he can control on what
    > addresses an app
    > listener opens a socket. Most apps open sockets on 0.0.0.0
    > (i.e., every
    > interface) by default. Some let you specify listening
    > addresses. He appears to want a way to designate some
    > interfaces as "restricted" and others as "not restricted" so
    > that apps open listeners on the "not restricted" interfaces by
    > default, but can open listeners on the "restricted" interfaces
    > if their configs specifically request it.


    Yes, that's exactly what I want.

    Wolfgang Draxinger
    --
    E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867


  6. Re: restrict implicit binding to interfaces

    David Schwartz wrote:
    > On Oct 29, 4:13?am, Wolfgang Draxinger
    > wrote:
    > > How can I do that, I mean: If a program requests to be bound to a
    > > certain interface explicitly, then and only then it bound to that
    > > interface. Otherwise it's just bound implicitly to the not
    > > restricted interfaces.


    > Programs don't bind to interfaces. Your question doesn't make any
    > sense.


    While "Linux" is very much not such a stack on a "Strong End-System
    Model" system binding to a given IP address is pretty much the same
    thing since the traffic to that IP will only be accepted on that
    interface.

    > You seem to be under the misconception that addresses belong to
    > interfaces. They don't under Linux, they belong to the machine as a
    > whole. When you bind to an address, you accept packets sent to that
    > address regardless of what interface they arrive on. Otherwise, it
    > would be impossible to set up a functional router.


    In fact, Linux takes the weak end-system mantra farther than any other
    system I've encountered - by default ARP on any interface will be more
    than happy to respond for any IP on the system, not just that on the
    interface on which the ARP request was received. Leads to lots of
    "fun" when connecting multiple interfaces to the same broadcast
    domain, even if those interfaces are configured into different IP
    subnets.

    rick jones
    --
    Process shall set you free from the need for rational thought.
    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...

  7. Re: restrict implicit binding to interfaces

    On Oct 29, 3:49*pm, Allen Kistler wrote:

    > I think what he's asking is how he can control on what addresses an app
    > listener opens a socket. *Most apps open sockets on 0.0.0.0 (i.e., every
    > interface) by default. *Some let you specify listening addresses. *He
    > appears to want a way to designate some interfaces as "restricted" and
    > others as "not restricted" so that apps open listeners on the "not
    > restricted" interfaces by default, but can open listeners on the
    > "restricted" interfaces if their configs specifically request it.


    I don't think that's what he's asking. As that would still allow
    people to connect to the restricted services on the restricted
    interfaces, simply by using an unrestricted destination address.

    DS

  8. Re: restrict implicit binding to addresses

    On Oct 29, 4:55*pm, Wolfgang Draxinger
    wrote:

    > > Programs don't bind to interfaces. Your question doesn't make
    > > any sense.


    > s/interface/address/ then. Well in my case that's equivalent
    > (for IPv4), as two of the networks (read, logical networks,
    > address/netmask level) use private IP address ranges, thus
    > my wrong naming. I'm thinking mostly in secure and insecure
    > interfaces right now.


    Then the solution is to use the machine's firewalling capability to
    block connections to restricted ports from untrusted source addresses.

    > (Anyway, some programs _do_ bind to interfaces, think about
    > dhcpd; alas, that's on the raw level).


    Right, and that's not what you're talking about.

    > >> In the particular case it's a proxy server (the deamon is not
    > >> buggy, so explicit binding works, but I'd like to have some
    > >> fallback). Squid shall listen only to the internal network, so
    > >> it can't be abused from outside.


    > > Programs don't listen to networks. Again, your question doesn't
    > > make any sense.


    > With network I didn't mean physical network, but logical
    > network like in IP subnet.


    You need a firewall. The best solution is to block all incoming
    traffic from untrusted sources to undesired ports.

    > > Can you state precisely what it is you are trying to do? What
    > > is the rule for whether a connection should or should not be
    > > allowed to the proxy?


    > If a socket is bound to a port only, it will listen to connection
    > attempts on all addresses of the machine. One can of course bind
    > to certain addresses explicitly.


    That doesn't provide any level of security. It simply provides service
    differentiation. It is a mistake to rely on this for security.

    > You can see, that there's a program dnscache, listening on .1.2:53
    > Using a interface based iptables rule it's easy to block all
    > incoming connection requests from (sub)nets not designated to
    > that interface. No problems there. In this case dnscache is
    > bound to a specific address explicitly, because it must so.
    > The same goes for tinydns, which is turn cached by dnscache.
    >
    > Now there's also a Samba and a NTP running on the system. And
    > those are not bound explicitly to a certain address. What I'd
    > like to have, independent of ports on which a socket listens,
    > is that all sockets, which are not bound to an address explicitly,
    > behave as if the had been bound to a preselected set of addresses,
    > and that addresses only, so that programs, that can't be configured
    > to listen on specific addresses, or a buggy won't attach to those.


    > A iptables makes it then easy to block all traffic from a certain
    > interface, designated to that set of addresses.


    Right, that's what you want. You need a set of allow rules to allow
    inbound connections to be established from untrusted addresses to
    those services you want to allow, and to refuse them on those you
    don't want to allow.

    You need to configure allowed and un-allowed services, obviously, so
    why not do it in the iptables? You can do it by user, by port, or by
    any other method iptables allows.

    > The machine will be something like a major data storage and exchange
    > hub, providing services for private internal and public external
    > users, but only certain services/programs shall be made public.
    > Normally one would do that using separate machines or
    > paravirtualization. In that case it was ruled out for performance
    > reasons: huge DB, full access to the RDBS from two intern
    > (sub)networks (physical and logical), access from extern network
    > only through special proxy daemons.


    Normally this would be done by a firewall. Why is iptables not the
    answer?

    DS

  9. Re: restrict implicit binding to interfaces

    David Schwartz writes:

    > Programs don't bind to interfaces. Your question doesn't make any
    > sense.


    You can write a C program that does exactly that.
    I agree than most programs don't.
    >
    > Programs don't listen to networks. Again, your question doesn't make
    > any sense.


    Programs do listen to networks.

    > You seem to be under the misconception that addresses belong to
    > interfaces.


    ifconfig(1) associates addresses to interfaces.

    > whole. When you bind to an address, you accept packets sent to that
    > address regardless of what interface they arrive on.


    If you configure an interface to one address, it's won't accept
    packets addressed to other (unicast) addresses.

    Some systems allow you to create a second address on the same
    interface using a 'virtual interface.'

    Unless you put the interface into promiscuous mode using a network sniffer.

    > Otherwise, it
    > would be impossible to set up a functional router.


    Usually interfaces are connected to different networks.



  10. Re: restrict implicit binding to interfaces

    Wolfgang Draxinger writes:

    > Allen Kistler wrote:
    >
    >> I think what he's asking is how he can control on what
    >> addresses an app
    >> listener opens a socket. Most apps open sockets on 0.0.0.0
    >> (i.e., every
    >> interface) by default. Some let you specify listening
    >> addresses. He appears to want a way to designate some
    >> interfaces as "restricted" and others as "not restricted" so
    >> that apps open listeners on the "not restricted" interfaces by
    >> default, but can open listeners on the "restricted" interfaces
    >> if their configs specifically request it.

    >
    > Yes, that's exactly what I want.


    Then you will likely have to change the source code of those apps.

    It's not hard. Although It was 15 years ago when I did this.

    Normally the bind() call uses some constant for one of the parameters.
    I think it's INADDR_ANY. (which usually has the value 0x00).

    You change this to match the IP address you explicitly want.

    So if a device has multiple interfaces, this forces the application to
    only listen to the interface specified. If you have an inside network,
    and an outside network, you can force the app to listen to one of the
    other.

    This is uncommon for many apps. Luckily for Linux, the source code is
    usually available.


  11. Re: restrict implicit binding to addresses

    David Schwartz wrote:

    > Normally this would be done by a firewall. Why is iptables not
    > the answer?


    Well, iptables will do the job, it just _must_ be configured
    correctly.

    The human factor is the problem: The system will be run mostly by
    students, which don't care about such things. Important thing
    is, that their simulation programs (running on the cluster in
    one of the private networks) do their job. And on the data hub
    they can install their own deamons for data selection and
    proxying. A security nightmare, those programs won't be checked
    for exploits and similiar stuff. The problem is, that the data
    hub also needs reasonably fast connection to the local backbone
    (M√ľnchner Wissenschaftsnetz), either to transfer the data to the
    supercomputer in the LRZ, the group sometimes get computing time
    on it, or to feed a grid.

    > You need to configure allowed and un-allowed services,
    > obviously, so why not do it in the iptables? You can do it by
    > user, by port, or by any other method iptables allows.


    Tonight I figured, I could filter for programs pid, gid and
    command line for outgoing packets. Then put a small helper
    program around the daemon, that opens the firewall for the
    programs that are started by it. Hmm, thinking about it, I could
    also ptrace for bind and open the ports in the iptable on demand
    (think about protocols, that are as brain dead like FTP...).

    Wolfgang Draxinger
    --
    E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867


  12. Re: restrict implicit binding to addresses

    On Oct 30, 1:40*am, Wolfgang Draxinger
    wrote:

    > Well, iptables will do the job, it just _must_ be configured
    > correctly.


    That's true of any solution. Since you want to allow some things and
    not others, somewhere there is going to have to be a configuration of
    what's allowed and what isn't. I don't see that you have an
    alternative.

    > The human factor is the problem: The system will be run mostly by
    > students, which don't care about such things. Important thing
    > is, that their simulation programs (running on the cluster in
    > one of the private networks) do their job. And on the data hub
    > they can install their own deamons for data selection and
    > proxying. A security nightmare, those programs won't be checked
    > for exploits and similiar stuff. The problem is, that the data
    > hub also needs reasonably fast connection to the local backbone
    > (MŁnchner Wissenschaftsnetz), either to transfer the data to the
    > supercomputer in the LRZ, the group sometimes get computing time
    > on it, or to feed a grid.


    You probably want a firewall that is not administered by the students.

    > > You need to configure allowed and un-allowed services,
    > > obviously, so why not do it in the iptables? You can do it by
    > > user, by port, or by any other method iptables allows.


    > Tonight I figured, I could filter for programs pid, gid and
    > command line for outgoing packets. Then put a small helper
    > program around the daemon, that opens the firewall for the
    > programs that are started by it. Hmm, thinking about it, I could
    > also ptrace for bind and open the ports in the iptable on demand
    > (think about protocols, that are as brain dead like FTP...).


    You really can't do it by port?

    DS

  13. Re: restrict implicit binding to interfaces

    On Oct 29, 5:54*pm, Rick Jones wrote:

    > While "Linux" is very much not such a stack on a "Strong End-System
    > Model" system binding to a given IP address is pretty much the same
    > thing since the traffic to that IP will only be accepted on that
    > interface.


    Umm, no!!! That would make building a router virtually impossible.

    Traffic to any IP assigned to the machine will, and must, be accepted
    regardless of what interface it arrives on.

    DS

  14. Re: restrict implicit binding to interfaces

    On Oct 29, 8:11*pm, Maxwell Lol wrote:

    > > You seem to be under the misconception that addresses belong to
    > > interfaces.


    > ifconfig(1) associates addresses to interfaces.


    Right, and then that address belongs to the machine.

    > > whole. When you bind to an address, you accept packets sent to that
    > > address regardless of what interface they arrive on.


    > If you configure an interface to one address, it's won't accept
    > packets addressed to other (unicast) addresses.


    Yes, it will. IP would not work if that was the case, you could never
    have a functional router.

    > Some systems allow you to create a second address on the same
    > interface using a 'virtual interface.'


    > Unless you put the interface into promiscuous mode using a network sniffer.


    You are completely confused. Promiscuous mode is a level 2 thing. It
    has nothing whatsoever to do with IP addresses.

    > > Otherwise, it
    > > would be impossible to set up a functional router.


    > Usually interfaces are connected to different networks.


    And usually traffic to any particular IP address flows over many
    different networks.

    DS

  15. Re: restrict implicit binding to interfaces

    David Schwartz writes:

    > On Oct 29, 5:54¬*pm, Rick Jones wrote:
    >
    >> While "Linux" is very much not such a stack on a "Strong End-System
    >> Model" system binding to a given IP address is pretty much the same
    >> thing since the traffic to that IP will only be accepted on that
    >> interface.

    >
    > Umm, no!!! That would make building a router virtually impossible.
    >
    > Traffic to any IP assigned to the machine will, and must, be accepted
    > regardless of what interface it arrives on.
    >
    > DS


    Sounds like a real security risk to me. That says I can send packets
    to a router/firewall with the destination being the inside address,
    and it will respond.




  16. Re: restrict implicit binding to interfaces

    On Oct 30, 5:08*am, Maxwell Lol wrote:

    > Sounds like a real security risk to me. That says I can send packets
    > to a router/firewall with the destination being the inside address,
    > and it will respond.


    Since you can send packets to that router/firewall with the
    destination being the outside address much more easily, why would you
    think this matters?

    DS

  17. Re: restrict implicit binding to interfaces

    David Schwartz wrote:

    > On Oct 30, 5:08¬*am, Maxwell Lol wrote:
    >
    >> Sounds like a real security risk to me. That says I can send
    >> packets to a router/firewall with the destination being the
    >> inside address, and it will respond.

    >
    > Since you can send packets to that router/firewall with the
    > destination being the outside address much more easily, why
    > would you think this matters?


    I think, he's fallen for the misconception, that NAT and private
    address ranges are means of security. Tell the people about
    IPv6, and they'll respond in the same way.

    Wolfgang Draxinger
    --
    E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867


  18. Re: restrict implicit binding to interfaces

    On Oct 30, 8:10*am, Wolfgang Draxinger
    wrote:

    > I think, he's fallen for the misconception, that NAT and private
    > address ranges are means of security. Tell the people about
    > IPv6, and they'll respond in the same way.


    They provide some security accidentally, which leads some people to
    expect them to be reliable security schemes. This can cause a lot of
    harm.

    Another example is the mistaken notion that switches only send traffic
    to the destination port, and therefore can be used as a means to keep
    communications private. They provide some privacy accidentally, but
    are not designed to do so securely unless specifically configured to
    do so.

    Both a bridge and a NAT device will generally, by default, be
    configured to do everything they possibly can to make things "just
    work" and this is the opposite of making things secure.

    DS

  19. Re: restrict implicit binding to interfaces

    David Schwartz wrote:
    > On Oct 29, 5:54?pm, Rick Jones wrote:


    > > While "Linux" is very much not such a stack on a "Strong End-System
    > > Model" system binding to a given IP address is pretty much the same
    > > thing since the traffic to that IP will only be accepted on that
    > > interface.


    > Umm, no!!! That would make building a router virtually impossible.


    Indeed, it wouldn't take to routing changes very well, but it could
    still route. However, given the term has "end system" in it, that
    would (IIRC) be out of the context of something acting as an IP
    router.

    > Traffic to any IP assigned to the machine will, and must, be accepted
    > regardless of what interface it arrives on.


    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.

    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...

  20. Re: restrict implicit binding to interfaces

    David Schwartz wrote:
    > On Oct 29, 8:11?pm, Maxwell Lol wrote:


    > > > You seem to be under the misconception that addresses belong to
    > > > interfaces.


    > > ifconfig(1) associates addresses to interfaces.


    > Right, and then that address belongs to the machine.


    In the weak end system model. In the strong end system model the
    address belongs to the interface.

    > > If you configure an interface to one address, it's won't accept
    > > packets addressed to other (unicast) addresses.


    It will under Linux and under any system using the weak end system
    model. It will not (for local delivery anyway) on a system configured
    for the strong end system model.

    > Yes, it will. IP would not work if that was the case, you could
    > never have a functional router.


    There are routers, there are end systems. While the two may coexist
    within the same sheet metal, they are still separate concepts.
    Accepting a datagram for local (ie within the machine) delivery would
    follow the rules for "end system." Accepting a datagram for
    forwarding presumably would not follow the rules for "end system."

    rick jones
    somehow reading all of this I think of:
    http://snltranscripts.jt.org/75/75ishimmer.phtml

    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    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...

+ Reply to Thread
Page 1 of 2 1 2 LastLast