Re: RE : RE : [midcom] More on new work item

Jonathan Rosenberg <jdrosen@dynamicsoft.com> Tue, 04 May 2004 07:45 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14855 for <midcom-archive@odin.ietf.org>; Tue, 4 May 2004 03:45:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuad-0003wV-GC for midcom-archive@odin.ietf.org; Tue, 04 May 2004 03:43:43 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i447hhD2015156 for midcom-archive@odin.ietf.org; Tue, 4 May 2004 03:43:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuUC-0001uS-Ng; Tue, 04 May 2004 03:37:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuSd-0001Y5-W2 for midcom@optimus.ietf.org; Tue, 04 May 2004 03:35:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14214 for <midcom@ietf.org>; Tue, 4 May 2004 03:35:25 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKuSb-0007ZL-Hp for midcom@ietf.org; Tue, 04 May 2004 03:35:25 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKuRj-0007LG-00 for midcom@ietf.org; Tue, 04 May 2004 03:34:32 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKuR5-00079V-00 for midcom@ietf.org; Tue, 04 May 2004 03:33:51 -0400
Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i447X9us024163; Tue, 4 May 2004 03:33:10 -0400 (EDT)
Message-ID: <4096EB1B.4000105@dynamicsoft.com>
Date: Mon, 03 May 2004 21:00:11 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joel Tran <joel.tran@USherbrooke.ca>
CC: midcom@ietf.org, 'Melinda Shore' <mshore@cisco.com>
Subject: Re: RE : RE : [midcom] More on new work item
References: <000401c43122$e35cdee0$b248d284@kamel>
In-Reply-To: <000401c43122$e35cdee0$b248d284@kamel>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_06_12 autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Joel Tran wrote:

> IMHO, It is not meant to be a deep analysis for all the pros and the cons of
> DHCP and how things can be done or not. At the beginning, you raised some
> good questions about the applicability of this technique. It was a good
> call. However, as discuss earlier, I think that there are some circumstances
> where this technique is applicable and where we might need the end-points to
> communicate directly with the Midcom middlebox.

Well, I'm trying to poke into that. I don't think it makes sense to take 
on this work item if it turns out that it only makes sense as part of a 
network that is designed with serious security issues or complexity 
problems. If that is so, there is no point in doing this DHCP work.


>>>I don't think we require a big correlation (User/PWD/IP) in
>>
>>> order to
>>
>>>> > provide a security mechanism. For example, the rules can be :
>>>> >
>>>> >   1 - Pinholes can only be created for the source address.
>>>> >   2 - User joe can only create 10 pinholes or IP source can only
>>>> > create 10 pinholes.
>>>> >   3 - ...
>>
>>>
>>> This rule is susceptible to source address spoofing attacks. It would
>>> allow me to direct traffic at a target by faking my source IP
>>> to be that
>>> of the target.
> 
> 
> I think DHCP is used mainly by ISP in two cases. The first case concerns the
> assingment of pseudo-static IP address to client using a DHCP. This
> technique is mainly used in a shared medium context (cable user for
> instance). The second case concerns the assingment of dynamic IP address to
> client. This is mainly used with PPP link (PPOE ADSL network and dialup for
> instance).
> 
> In the first case, it is easy to make a policy with the IP/MAC to an user
> since it is pseudo-static. An attacker would have to clone the MAC/IP and
> find the correct user/pwd to do a sproofing attacks.

This depends on how the username/password are distributed. In any case, 
pseurandom is the same as being totally random, since once its not 
static, you need a way to communicate the assignment from the DHCP 
server to the middlebox. Of course, there are probably several 
middleboxes, and so you need to distribute the usernames and passwords 
to those. Or, add a AAA system to avoid having the firewall actually 
know everyones username and passwords...

Anyway, what I'm driving at here is that this gets to be a reall, really 
complex system. Complex systems are expensive, and they make security 
more problematic. I think something like STUN or one of the many 
documented relay techniques are going to be far simpler and also far 
more secure.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom