From owner-cvs-all@FreeBSD.ORG Thu Jan 26 21:13:41 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A58116A420; Thu, 26 Jan 2006 21:13:41 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAAFC43D45; Thu, 26 Jan 2006 21:13:40 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k0QLDY5T040803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2006 00:13:35 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k0QLDY2d040802; Fri, 27 Jan 2006 00:13:34 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 27 Jan 2006 00:13:34 +0300 From: Gleb Smirnoff To: "Bjoern A. Zeeb" Message-ID: <20060126211334.GF83922@FreeBSD.org> References: <200601261306.k0QD6o4P070834@repoman.freebsd.org> <43D927B4.9040602@elischer.org> <20060126195806.GC83922@FreeBSD.org> <20060126202334.W24703@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060126202334.W24703@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.6i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Julian Elischer , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netgraph ng_pppoe.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 21:13:41 -0000 On Thu, Jan 26, 2006 at 08:58:18PM +0000, Bjoern A. Zeeb wrote: B> >The other change I'm planning to do is the following - if the B> >original PADI had empty Service-Name, and we are servicing a B> >specific Service-Name, then return remove empty one from PADO, B> >returning only our specific Service-Name. B> B> Why would you want that? I haven't re-read the RFC but I think it said B> that PADOs have to include the Service-Name the client requested first, B> optionally followed by other Services-Names the AC may want to B> announce. You are right. I don't need this change. B> Only in PADS you will then reply with only the one Name you accepted. B> B> I can see the problem with your change and the above coming: B> What would happen if you B> a) accepted the 'any service' request B> b) replied with 'any service' and 'service-name1, ...' B> c) the client now requests 'any service' B> d) you don't want to serve 'any service' B> B> Well you should have been silent from a) to b) *ups* This client won't connect, and will timeout on server. I don't see problem here. B> Ok, so the only solution to this problem is what should also be in B> that RFC - it's a ploicy decicion of the AC -- of what to accept B> as Service-Name in a PADI. We had a clear policy up to now name it B> closed system. With your change we will have an open system (everyone B> will see the Service-Names we may serve if requested). You are right again. I think that default behavior should be old one. We don't want to tell everyone all our available Service-Names. B> The first thing might be a sysctl to toggle old and new behavior but B> actually one may also want to decide on a peer by peer base depending B> on a lookup perhaps based on mac address and/or Service-Name requested B> or even simpler on a per ("Ethernet") port base and fall back to B> a default policy if there is nothing (no hook) to do such a lookup. B> [ I am () ethernet because it's not always a physical ethernet port B> at the other end at the AC ] If you want to implement more complicated access control, do it :) B> The other question is what to do with clients requesting Service-Names B> we don't know of but we know that we should serve the client? B> I think this is a common scenario here in DE that some clients set a B> Service-Name to "foo" and the ACs silently ignore and just serves it B> (server all Service-Names policy)[1]. It's also a policy decision that B> people might need ... Isn't this what we always did with "*" Service-Name? B> [1] There are people speculating what will happen if they need to make B> use of service-names ... ;) Fun with nnK users ... -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE