On Thu, 2008-09-04 at 11:21 -0700, Erik Nordmark wrote:
> I've merged the clearview-noipmp bits with my work and in doing so some
> issues and questions came up.
>
> Looking at the source zoneid in the transmit code path the current code
> (which looks up the source address in the packet) has several issues
> because the source address might not uniquely identify the sending zone.
That's true, although in some cases, when we have the conn_t, we use
conn_zoneid.
> The cases I know of are:
> - application sets IP{,V6}_UNSPEC_SRC thus the packets are sent with a
> zero source address
> - an application in zoneA sets SO_ALLZONES and binds to an address
> assigned to zoneB.
> - With trusted extensions an IP address can be assigned to multiple zones.
All of these cases could be addressed easily if we either always had a
conn_t, or the DB_CRED(mp) were accurate at the hook locations (except
for kernel-generated packets...). Ignoring the fact that IP data-path
refactoring will blow this all up, I know that the former isn't true
today, but I wonder if the latter is. Do you know? Could (until
data-path refactoring delivers) we simply use DB_CRED() in all cases
instead of the source IP address?
> In the onnv-gate code base it is hard to do something about those cases.
> But my question is whether we actually want to capture the zoneid of the
> sending process. (It would be easy to do that in the refactored IP code.)
We need to, yes, because filtering is based on zoneid. For example, a
stream originating in zone A should only be able to see packets
originating from zone A or destined to zone A, and this filtering is
done in the ipnet module based on the zoneid's associated with the
source and destination.
> But if we do that things will not be symmetric with the receive side
> (the destination zoneid on the receive side to be specific.)
> For instance, while we can know the sending zoneid when SO_ALLZONES is
> used, on the receive side it isn't until we hit the top of IP (looking
> for a conn_t) that we can tell that SO_ALLZONES was used. Likewise for
> the TX shared IP address; we do a fanout once we know the label. (Hmm we
> do know the db_credp early on in ip_input with TX; I don't know if the
> cred has the zoneid set at that point in time though.)
tsol_get_pkt_label() fixes the label in the db_credp early on (early
enough), then the ipobs code does a tsol_packet_to_zoneid(mp) which
turns this label to an accurate zoneid.
> For IP_UNSPEC_SRC the corresponding receive side is a multicast or
> broadcast packet. I went back and re-read your design document and I
> didn't see any examples in how multicast and broadcast is handled.
>
> How does the multicast and broadcast packets match non-global zones in
> ipnet?
This is indeed missing from the design doc, and the code currently
doesn't handle this correctly (we have a bug filed on this). The
desired behavior is that the destination zoneid of multicast and
broadcast packets are unknown. All zones are allowed to observe
multicast and 255.255.255.255, and subnet broadcast is filtered based on
the IP interface being observed.
The PSARC materials (2006/475) contain some discussion on how
DL_PROMISC_MULTI causes the ip module to enable DL_PROMISC_MULTI on the
underlying device so that we can have observability of all multicast
traffic, and not just the traffic associated with joined groups.
> In my head it also isn't clear how to handle certain transmitted packets
> generated by the kernel. The tricky one is IPv6 ND packets where we've
> had various attempts at determining the zoneid. The ND packets, just
> like ARP packets, are essentially sent as a part of a service which is
> shared for all the zones (the ARP and NCE information is shared for all
> the zones.) However, the ND (and ARP) packets have a source IP address
> which is assigned to some zone. I don't know if the current onnv-gate
> code uses that as the zoneid passed to ip_output.
Good question. The definition of "correctness" isn't all too clear to
me either. Using the zoneid associated with the source address would
allow zones to view ND packets sent on their behalf. On the other hand,
since the "process" of neighbor-discovery is essentially in the global
zone and the packets are generated from the global zone (but this is not
well-defined, but then again zones in general are poorly defined),
associating those packets with the global zone would not seem
incorrect. :-(
-Seb
