Date: Thu, 29 Jun 2017 15:03:42 -0700 X-RT-Incoming-Encryption: Not encrypted content-type: text/plain; charset="utf-8" Return-Path: X-Mailer: Apple Mail (2.3124) To: dhcp-confidential@isc.org Subject: Re: [ISC-Bugs #45451] [confidential] DHCPv6 client class matching bug in DHCP server 4.3.5 Delivered-To: dhcp-confidential@bugs.isc.org Message-ID: <7955C2C9-B433-43B9-9F18-AF9152B65808@stanford.edu> In-Reply-To: Content-Transfer-Encoding: quoted-printable From: "Rob Riepel" X-RT-Original-Encoding: utf-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham autolearn_force=no version=3.4.0 X-Original-To: dhcp-confidential@bugs.isc.org References: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-29_15:,, signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-29_15:,, signatures=0 From riepel@stanford.edu Thu Jun 29 22:03:51 2017 Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id 7E705D78A9D for ; Thu, 29 Jun 2017 22:03:51 +0000 (UTC) Received: from mx0a-00000d04.pphosted.com (mx0a-00000d04.pphosted.com [148.163.149.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 972B93494AC for ; Thu, 29 Jun 2017 22:03:48 +0000 (UTC) Received: from pps.filterd (m0102890.ppops.net [127.0.0.1]) by mx0a-00000d04.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5TM2u9s018837 for ; Thu, 29 Jun 2017 15:03:44 -0700 Received: from mx0b-00000d03.pphosted.com (mx0b-00000d03.pphosted.com [148.163.153.234]) by mx0a-00000d04.pphosted.com with ESMTP id 2bctf2uj48-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 29 Jun 2017 15:03:44 -0700 Received: from pps.filterd (m0102882.ppops.net [127.0.0.1]) by mx0a-00000d03.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5TM1TdY018286 for ; Thu, 29 Jun 2017 15:03:43 -0700 Received: from codegreen7.stanford.edu (codegreen7.stanford.edu [171.67.224.9]) by mx0a-00000d03.pphosted.com with ESMTP id 2bd8539dhp-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 29 Jun 2017 15:03:43 -0700 Received: from codegreen7.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen7.stanford.edu (Postfix) with ESMTP id A0B9047 for ; Thu, 29 Jun 2017 15:03:37 -0700 (PDT) Received: from smtp.stanford.edu (smtp1.stanford.edu [171.67.219.81]) by codegreen7.stanford.edu (Postfix) with ESMTP id 9369447 for ; Thu, 29 Jun 2017 15:03:37 -0700 (PDT) Received: from noxzema.stanford.edu (noxzema.stanford.edu [171.64.20.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: riepel) by smtp.stanford.edu (Postfix) with ESMTPSA id 3CB15666A3 for ; Thu, 29 Jun 2017 15:03:42 -0700 (PDT) X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706290353 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org X-RT-Interface: Email MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) RT-Message-ID: Content-Length: 2095 On Jun 29, 2017, at 1:29 PM, Thomas Markwalder via RT wrote: > I have reproduced the issue and it is not related to the size of your configuration but then I didn't really think it would be. The problem is that the client classification of a packet is done BEFORE the global statements are executed for that packet. This means the classification is actually being done based on the binding variables set by previous packet. > > You can see this in the logs. A SOLICIT from a bad client matches because the previous packet was from a good client. The ensuing REQUEST from the bad client does not match because the variables are now based on the bad client's SOLICIT. Well, it all makes perfect sense now. Glad it's not a bug. > The reason this is not an issue for your V4 configuration is because your match argument is "hardware" and that value is available directly from the packet when classification is done. > > The "match" clause can support expressions such as match pick_first_value(...) or match suffix(option dhcp6.client-id,6) and so forth. Those are calculated as part of the classification evaluation. You should be able to come up with expressions that will meet your needs but you would have to repeat them for each class declaration. Not as clean as what you wanted to do but the software currently won't support that. I'll give that a go. > I'll continue to explore this and will keep you updated. Thanks. Also, consider the following: In 2009 David W. Haskins wrote, with respect to DHCPv6 and hardware addresses(*): > I'm inclined to make 'hardware ethernet ...;' just work, assuming > the client is sending either of those two types of DUID, ... Clearly that's happened. If ISC would extend that to "match hardware", all my dhcpd.conf futzing to tease the hardware address out of the clientid would be unnecessary. (And, I suspect, there would be much rejoicing.) Thank you very much for the quick turnaround and detailed explanation. -- Rob Riepel (*) https://lists.isc.org/pipermail/dhcp-users/2009-February/008463.html