From owner-freebsd-net Fri Dec 1 8: 2:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.streamflo.com (gatekeeper.streamflo.com [204.209.251.6]) by hub.freebsd.org (Postfix) with ESMTP id 4E9ED37B400; Fri, 1 Dec 2000 08:02:13 -0800 (PST) Received: by gatekeeper.streamflo.com (8.9.3) id JAA35944; Fri, 1 Dec 2000 09:01:56 -0700 (MST) Received: from gatekeeper.streamflo.com by gatekeeper.streamflo.com via SMTP id xma035936; Fri, 1 Dec 00 09:01:29 -0700 Received: from mailhub.streamflo.com by mailhub.streamflo.com id eB1G1Ta38119; Fri, 1 Dec 2000 09:01:29 -0700 (MST) From: "Craig W. Penner" Organization: Stream-Flo Industries Ltd. To: Jim Flowers Date: Fri, 1 Dec 2000 09:01:10 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: SKIP port on 4.x (prize offer) Reply-To: cpenner@streamflo.com Cc: Archie Cobbs , freebsd-questions@freebsd.org, freebsd-net@freebsd.org Message-ID: <3A2768D6.19178.87E3A26@localhost> References: <200011301942.eAUJgcK92874@curve.dellroad.org> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jim, > What about it? Anyone with skills in this area interested in figuring > out what changed between 4.1 and 4.1.1 probably in the crypto changes > that prevents the MD5 authentication of a skip partner. I spent a couple of hours yesterday looking at the code, and while my C skills are a little rusty, here's how it looks to me: 1. SKIP contains its own built-in crypto functions, including its own MD5 routines. It doesn't appear to link against any of the system crypto libraries, and I don't think there's any chance of it using the wrong md5.h header file (most of SKIP's own MD5 functions are named slightly differently than the OS versions). So I don't think SKIP's brokenness results from changes in the FreeBSD crypto stuff (at least not directly). 2. A 4.2-STABLE SKIP kernel still properly signs outgoing packets, because they are correctly authenticated when received as incoming packets on a pre-4.1.1 system. 3. The problem appears to be with incoming packets on post 4.1-RELEASE systems. Is it possible that incoming packets are being changed slightly before SKIP gets a chance to process them, thereby causing a failure in the MD5 authentication? SKIP appears to ignore the ip_sum, ip_ttl, ip_tos and ip_off fields in the IP header when signing and authenticating packets, presumably because these fields are expected to change; is there some other field in an IP packet that now falls into this same category that didn't before? Maybe something related to IP options processing? (Now I'm totally guessing.) At this point, if I had to guess, I would guess that the problem is that the FreeBSD TCP/IP stack changed in some very subtle way with respect to incoming packets only. By looking at the CVS logs, it appears that there were some changes made during the time between 4.1-RELEASE and 4.1.1-RELEASE to the way IP packets are processed, but nothing that looks to my untrained eye to be obviously problematic. Unfortunately, I don't know enough about SKIP's internals, kernel networking internals, or how SKIP and the TCP/IP stack interact to go any further with this. Maybe I'm way off-base, but I thought I'd throw this out there in case it helps to point someone in the right direction. If I'm totally out to lunch, just disregard everything I've said. Regards, Craig To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message