From owner-freebsd-current@freebsd.org Wed Sep 27 12:13:22 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 777F5E01ED1; Wed, 27 Sep 2017 12:13:22 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B9B7700F9; Wed, 27 Sep 2017 12:13:22 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: by mail-wr0-x22f.google.com with SMTP id h16so1841339wrf.6; Wed, 27 Sep 2017 05:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3nnVqT89k7JX7Jg7I5DZqTWoXTq+ldKiYFcWxZX7Kmg=; b=l0Cpie+iCo1BHTo+DbrPNJtAundH6npz3KLoJKPL/547EuxQD7VS1MQBYLAscnxdmp elQM76JNmq1VZ5QXMKigUF2Ocf0XSga8XdMSkPrCpD84RqSpWzsqxEfgDDlk8kC6nPeX 5wrkShZydoccC0BlrBKNhgNFzfK4jGA2XUVqHn7b1QBm1JMfNZk5UB6tBqLnOhuVJcQb q5FTQ3qKyjY/dcWWrbBk+fZ7wM1W3/X0xRhpjr+9iGWkjlIs4zt1AyiHteOboKzC0t+v 9NULyxbWyCbuOQuzFvxZNSA3kMqkUsrq0ajToBumNi8//MpXUcSfmeN89dc2kFqU3cL4 zKvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3nnVqT89k7JX7Jg7I5DZqTWoXTq+ldKiYFcWxZX7Kmg=; b=X3adIxRHQj+mApdHdPb9f2feuK0zC947dJGhVRhiZmP/9qByqfbn1t+ae6I9gGS/GJ Lrbq2HKYHlLl28A4NAOGkWPkKGPCME3SC1bq6sQGgn+ylhUcZctPZeKSEJrJnNp0gGcv QBPARbjDzR4DxUn1QMKetWqAyY4//SwTSvYduqrcFVrPQsAz9JAj1jb/d6slEbVjFpvA OqiSAFpku6L3JPST4EcmAZ8ZwL8ERXg4EXkcFpF+uluGFgmdmKEpzftdhcZrTHbIu/NC utOLCgj09yTKqgzhbP94Md+8TnO7os9MlsgVkTz7ra7c94tF7M7wPZEItb70tCw9uPeA x8Vg== X-Gm-Message-State: AMCzsaVUXT+/clfCKsW1O1Qu12OvCSXQNySGWDVgeilBDaKnwkmvEpG6 ZQdZpYO8IontU0pdagIQliO+yVCkr5YdvuyIHEu3lw== X-Google-Smtp-Source: AOwi7QAxp7AAYLVu7SYZia2NRNRgM4Ofivlm+6c5T1GzC6P+a9ajqpAX4A3eB0r6Vt2zrQoc3VTYTjQ/PO8z2cCwe2E= X-Received: by 10.25.24.231 with SMTP id 100mr467357lfy.241.1506514399417; Wed, 27 Sep 2017 05:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.89.13 with HTTP; Wed, 27 Sep 2017 05:12:58 -0700 (PDT) In-Reply-To: References: <20170926103543.0aa03c7a@freyja.zeit4.iv.bundesimmobilien.de> From: Damjan Jovanovic Date: Wed, 27 Sep 2017 14:12:58 +0200 Message-ID: Subject: Re: FreeBSD, IPFW and the SIP/VoIP NAT problem To: Guido Falsi Cc: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 12:13:22 -0000 On Tue, Sep 26, 2017 at 11:27 AM, Guido Falsi wrote: > On 09/26/2017 10:35, O. Hartmann wrote: > > > of the RTP connection doesn't make it through IPFW/NAT. As often I > search the > > net, I always get informed this is a typical problem and solutions are > > provided by so called ALGs - since SIP protocol's SDP indicates within > the > > This would require coding it in IPFW, and the load on the firewall could > be significant. > > It could be done in userland maybe, leveraging divert(4) and having a > daemon listening there and doing the extra work, but this would be quite > expensive. Depending on your call volume the load could be too much for > your firewall. > > SIP headers like Proxy-Authorization need to send a cryptographic quality hash of data that includes the password and the SDP when qop=auth-int, and the ALG needs to change the IP address and port in the SDP, which changes this hash. The ALG would have to know your password to calculate the new hash. A SIP ALG can thus only work with the weaker qop=auth protection, which doesn't hash the SDP and is thus less secure (MITM attacks can capture/modify RTP in transit), and even then it would have to be careful not to change the SIP headers which are included in the hash. Since it is the provider that chooses the allowed qop, a general SIP ALG is impossible unless the ALG knows the password. Linux has a SIP ALG in iptables, and it's full of problems and best disabled.