Subject: RE: MBone tunnel and FreeBSD

From: Yves Lepage <[email-masked]>
Date: Tue, 14 Apr 1998 19:52:00 -0400

Hi,

This is indeed unfortunate.

Bill, wouldn't it make more sense not to treat a physical interface as a
superset of the tunnels that go through it. 

Maybe treating the VIF's based on the type of mcast traffic they carry
(encapsulated vs native) could be done so that phys interfaces and
tunnels are segregated?

Thanks,
Yves

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, April 14, 1998 4:55 PM
> To:	Bill Fenner
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: MBone tunnel and FreeBSD
> 
> 
> 
> On Tue, 14 Apr 1998, Bill Fenner wrote:
> 
> > Unfortunately, a rate limit of 0 on a physical interface will stop
> > the host from receiving packets also.  Mark's solution of a discard
> > interface (which has to have a real subnet address so wastes address
> > space) is the best way to do this.
> > 
> >   Bill
> > 
> 
> Thx Bill and thx to all who replied so quickly. I'll do the mods to my
> kernel as suggested and see how things go. 
> 
> On a slightly more wishful note what needs to be done to the kernel
> (other
> than the mod suggested above) to realise a solution to this problem??
> It
> seems to me that a general solution to prevent the leakage of
> multicast
> traffic back out would be highly desirable (such as during testing and
> not
> wanting to flood the local subnet). 
> 
> Once again thx.
> 
> Regards
> nand

---

From: Bill Fenner <[email-masked]>
Date: Tue, 14 Apr 1998 17:14:38 PDT

>superset of the tunnels that go through it. 

It isn't.  The restriction I mentioned comes from the architecture of
the UNIX kernel's multicast routing: the forwarder and the host are
completely seperate entities.  The "host part" of the multicast router
appears exactly the same as any other host connected to the same set of
physical networks.  Thus, if you limit the packets that you send out to
a physical network, you also limit the packets that processes on the
multicast router itself receive.

  Bill

---

From: Dave Thaler <[email-masked]>
Date: Wed, 15 Apr 1998 13:26:28 -0400 (EDT)

> multicast router itself receive.

How about allowing an application to join on a loopback interface?

-Dave

---

From: Mark Handley <[email-masked]>
Date: Wed, 15 Apr 1998 15:07:19 -0400

>How about allowing an application to join on a loopback interface?

That's pretty much what I'm doing using the FreeBSD discard
interface.  The trouble is the "host part" of the mrouter needs to
send multicast packets from an interface before the "router part" can
receive them and route them.  For that, the packets need a source
address, and 127.0.0.1 doesn't cut it as the source address of IP
packets that are going to be routed.  Hence using the discard
interface with a real IP address that I can advertise in DVMRP...

Cheers,
	Mark

---

From: Luigi Rizzo <[email-masked]>
Date: Tue, 28 Apr 1998 08:37:08 +0200 (MET DST)

It appears that there is a problem with running multiple instances of
SDR -- by different users -- on FreeBSD. It is not a problem in
sdr, but rather on bind(), and I wonder if it affects:
  1) other systems;
  2) other multicast applications.

The problem (in sdr) is as follows: when two instances of sdr are
run by different users, the second one fails to bind to the same
port, unless it is root or has the same UID as the first one.
Haven't verified if the test is made on the UID, EUID, GID or
what. Nor I have verified if it is specific of FreeBSD or it also
occurs on other systems.

I can see a reason for checking privileges on a bind -- if multiple
processes bind to the same port, some unprivileged process might
steal packet to another, more privileged one -- especially for
unicast traffic.

For multicast, though, my belief is that there is intrinsically no
security in the use of this type of transport, so the check should be
relaxed.

[in sdr, the offending bind() is called for INADDR_ANY ; i have tried
to set the address to a multicast group but it seems to make no
difference].

Comments/suggestions ?

	cheers
	luigi
-----------------------------+--------------------------------------
Luigi Rizzo                  |  Dip. di Ingegneria dell'Informazione
email: [email-masked]    |  Universita' di Pisa
tel: +39-50-568533           |  via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522           |  http://www.iet.unipi.it/~luigi/
_____________________________|______________________________________

---

From: Bill Fenner <[email-masked]>
Date: Tue, 28 Apr 1998 09:22:19 PDT

>steal packet to another, more privileged one -- especially for

Right, but with multicast, the packets are replicated to all
processes bound to the port, so this case doesn't apply.

>I wonder if it affects:

I believe this particular diff came from OpenBSD:

1.39 Sun Mar 1 19:39:26 1998 UTC by guido 

Make sure that you can only bind a more specific address when it is
done by the same uid.
Obtained from: OpenBSD

so OpenBSD is presumably affected in the same way.

Here's a straightforward fix to try.

  Bill

Index: in_pcb.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.43
diff -u -r1.43 in_pcb.c
--- in_pcb.c	1998/04/19 17:22:30	1.43
+++ in_pcb.c	1998/04/28 16:16:17
@@ -197,7 +197,7 @@
 			if (ntohs(lport) < IPPORT_RESERVED && p &&
 			    suser(p->p_ucred, &p->p_acflag))
 				return (EACCES);
-			if (so->so_uid) {
+			if (so->so_uid && !IN_MULTICAST(ntohl(sin->sin_addr.s_addr))) {
 				t = in_pcblookup_local(inp->inp_pcbinfo,
 				    sin->sin_addr, lport, INPLOOKUP_WILDCARD);
 				if (t && (so->so_uid != t->inp_socket->so_uid))

---

From: [email-masked] (Jeremy Hall)
Date: Tue, 28 Apr 1998 12:28:16 -0400 (EDT)

I don't think two processes can own the same group/port combination. This
is so the kernel knows where to send the packets. It is annoying if you're
trying to run a transcoder.

_J

---

From: Bill Fenner <[email-masked]>
Date: Tue, 28 Apr 1998 10:12:45 PDT

>trying to run a transcoder.

If you set SO_REUSEADDR (or SO_REUSEPORT on 4.4BSD), multiple sockets
may be bound to the same address/port, and multicast packets are delivered
to each matching socket.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Tue, 28 Apr 1998 10:14:35 PDT

>Here's a straightforward fix to try.

Way too straightforward, of course; the problem is that sdr binds to
INADDR_ANY which is not IN_MULTICAST().  Sigh.  Sounds like this needs
to be solved at demux time, not bind time, since multicast and unicast
are treated differently even if you do the exact same bind.

  Bill

---

From: [email-masked] (Jeremy Hall)
Date: Tue, 28 Apr 1998 13:16:53 -0400 (EDT)

then why won't two copies of rat coexist on the same  group/port
combination? (one as a standard tool, and one as a transcoder)

Rat seems to set SO_REUSEADDR when it starts its initial connection in
src/net.c.

_J

---

From: Luigi Rizzo <[email-masked]>
Date: Tue, 28 Apr 1998 18:54:47 +0200 (MET DST)

> processes bound to the port, so this case doesn't apply.
...
> Make sure that you can only bind a more specific address when it is

ok, then you have spotted the problem. Your fix will do the job
then, by changing sdr to bind to the multicast addr instead of
INADDR_ANY. After all the address is known by then.

But this ownership check from OpenBSD is not too convincing. 

	thanks
	luigi