Sebastien Roy wrote:
> Not for packets whose source and destination belong to the same IP
> stack. The core question being asked is whether this should be allowed
> for inter-shared-IP-zone communication which is looped-around within the
> ip module.
>
> I do believe that the same harm exists in allowing this type of traffic
> to cross shared-IP zone boundaries than exists for packets that go out
> on the wire. Either way, the packet can be considered a bogon that is
> forged and claims to be from somewhere which it is not.
I think the shared-IP zones code needs to be more intelligent about
dealing with 127.0.0.1. We already have one outstanding issue in that
the tcp classifier doesn't look at the zoneid. This is what makes the
TCP responses come back as John observed. (It also makes it impossible
to have 127.0.0.1 connections in different zones that have a fixed
source port number; such connections would have the same laddr, faddr,
fport, and lport i.e., the only differ in the zoneid.)
In addition to fixing that we should add some zoneid check in ip.c at
/*
* If the source address is a loopback address, the
* destination had best be local or multicast.
* The transports that can't handle multicast will reject
* those addresses.
*/
if (src_ire->ire_type == IRE_LOOPBACK &&
!(IRE_IS_LOCAL(dst_ire) || CLASSD(dst_addr))) {
Checking that an IRE_LOCAL has the same zoneid as the sender is
required. A multicast (on lo0) with a source address of 127.0.0.1 might
be tricker to fix. We clearly need to allow this for applications, but
the shared-IP zones semantics need to be that it only be delivered to
the sending zone.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
