X-RT-Incoming-Encryption: Not encrypted Subject: Re: [ISC-Bugs #45451] [confidential] DHCPv6 client class matching bug in DHCP server 4.3.5 Delivered-To: dhcp-confidential@bugs.isc.org References: X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706270369 MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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 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 487B2D78A66 for ; Tue, 27 Jun 2017 23:40:41 +0000 (UTC) Received: from mx0b-00000d04.pphosted.com (mx0b-00000d04.pphosted.com [148.163.153.235]) (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 3A2E9349420 for ; Tue, 27 Jun 2017 23:40:38 +0000 (UTC) Received: from pps.filterd (m0102891.ppops.net [127.0.0.1]) by mx0a-00000d04.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5RNbfvF015280 for ; Tue, 27 Jun 2017 16:40:33 -0700 Received: from mx0a-00000d03.pphosted.com (mx0a-00000d03.pphosted.com [148.163.149.244]) by mx0a-00000d04.pphosted.com with ESMTP id 2b9n1f9va9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 27 Jun 2017 16:40:33 -0700 Received: from pps.filterd (m0102881.ppops.net [127.0.0.1]) by mx0a-00000d03.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5RNe2X4006853 for ; Tue, 27 Jun 2017 16:40:32 -0700 Received: from codegreen7.stanford.edu (codegreen7.stanford.edu [171.67.224.9]) by mx0a-00000d03.pphosted.com with ESMTP id 2bbd1rk7uh-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Jun 2017 16:40:32 -0700 Received: from codegreen7.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen7.stanford.edu (Postfix) with ESMTP id DCAA846 for ; Tue, 27 Jun 2017 16:40:28 -0700 (PDT) Received: from smtp.stanford.edu (smtp1.stanford.edu [171.67.219.81]) by codegreen7.stanford.edu (Postfix) with ESMTP id CF9C046 for ; Tue, 27 Jun 2017 16:40:28 -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 081E66627A for ; Tue, 27 Jun 2017 16:40:32 -0700 (PDT) In-Reply-To: To: dhcp-confidential@isc.org X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org X-Original-To: dhcp-confidential@bugs.isc.org From riepel@stanford.edu Tue Jun 27 23:40:41 2017 X-RT-Interface: Email X-RT-Original-Encoding: utf-8 Date: Tue, 27 Jun 2017 16:40:31 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: From: "Rob Riepel" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-27_15:,, signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-27_15:,, signatures=0 content-type: text/plain; charset="utf-8" X-Mailer: Apple Mail (2.3124) Return-Path: RT-Message-ID: Content-Length: 1015 On Jun 27, 2017, at 10:41 AM, Thomas Markwalder via RT wrote: > This is an intriguing problem. Thus far, using your configuration we have not been able to produce a mismatch. We are winding up work on our next releases, 4.3.6/4.1-ESV-R15, which are due out 7/31/17, so our resources are somewhat limited. > > Could you supply us with pcaps of the traffic that causes the mismatch? As you can see from the files, I restart the server, started tcpdump (dst port 547 or dst port 546), and then told the "vile" client (same one as before) to configure IPv6 automatically. It matched "roaming" right off. The subsequent client, ac:bc:32:d3:2a:f1, which is a valid "roaming" client didn't explicitly match "roaming," but it didn't get an address either. About 15 seconds later it matched "roaming" and got an address. I've put the full config, log, and pcap files up at http://web.stanford.edu/~riepel/dhcpv6/ Let me know when you've got them so I remove them. Thanks. -- Rob Riepel