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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 May 2004 08:39:00 -0400

inline.

Joel Tran wrote:

>>-----Message d'origine-----
>>De : Jonathan Rosenberg [mailto:[email-masked]]
>>Envoyé : 30 avril, 2004 11:42
>>À : Joel Tran
>>Cc : 'Melinda Shore'; [email-masked]
>>Objet : Re: RE : [midcom] More on new work item
>>
> 
>>* if there is any other NAT intervening the user and the
>>ISP's nat (very
>>common here in the US at least, due to residential NAT devices like
>>those made by linksys), this of course won't help even if you
>>work out
>>the ACL issues
> 
> 
> Yes traversing the home NAT is a problem. Just a quick question, is there a
> solution avaible for traversing both home and ISP NAT (excluding relaying)
> when two peers are under such topology? If yes, we could probably learn form
> them how they solve the situtation.

Sure, STUN would allow this.

> 
> 
>>* assuming no other nats between the user and the ISP NAT, there is a
>>correlation that needs to be made somewhere between the
>>username/password and the IP address thats allocated to them.
>>This would
>>require some really convoluted coupling between DHCP (which
>>can tell you
>>the MAC/IP binding) and customer provisioning systems (which
>>*might* be
>>able to tell you the MAC used by a customers cable modem) and the ISP
>>firewall, to make sure that a user can only make changes for
>>their own
>>IP. This seems pretty complicated to me.
> 
> 
> 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.

If you further reduce the scope of this problem by making, say, 
relatively short timeouts on the bindings that are created, and only 
allow a single port to be allocated at a time, you come to an 
interesting point - you could obtain exactly the same kind of allocation 
from a midcom-unaware NAT by sending a STUN query through it.

> 
>>* Its also not clear to me that there aren't security holes
>>in the whole
>>thing that might enable someone to learn the passwords and usernames
>>needed to control bindings for other IP addresses.
> 
> 
> I'm not an SNMPv3 expert but I think that the security mechanism
> (USM/encryption) provided by SNMPv3 is strong enough so that it will be hard
> for someone to break trough and discover the user name/password or try to
> get unrestricted access.

I was concerned more about system level security, if you try and 
correlate the username/pass with DHCP and MAC information.

-Jonathan R.

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

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Joel Tran" <[email-masked]>
Date: Mon, 3 May 2004 11:25:38 -0400

I think we are diverging from the basic scope of the discussion. The scope
of the discussion is to find if DHCP or anoother means of configuration
might be needed in some circumstances for Midcom.

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.

What we are now performing is an in deep analysis of how we can/can't
implement this. IMHO, this is the next step of development and means that
DHCP or another means for configuring end-points might be needed.

I think now we are at a turn point in the discussion where we have do decide
whatever we need or not DHCP or another mechanism for midcom.

As for my opinion, I still think that midcom will benefit from DHCP or other
means of configuration of end-points.

Regards,

...J

> Envoyé : 3 mai, 2004 08:39
> À : Joel Tran
> Cc : [email-masked]; 'Melinda Shore'
> Envoyé : 30
> >>avril, 2004 11:42 À : Joel Tran
> >>* if there is any other NAT intervening the user and the ISP's nat
> >>(very common here in the US at least, due to residential
> NAT devices
> >>like those made by linksys), this of course won't help even if you
> >>work out
> >>the ACL issues
> >
> >
> > Yes traversing the home NAT is a problem. Just a quick question, is
> > there a solution avaible for traversing both home and ISP NAT
> > (excluding relaying) when two peers are under such
> topology? If yes,
> > we could probably learn form them how they solve the situtation.
>
> >>username/password and the IP address thats allocated to them. This
> >>would require some really convoluted coupling between DHCP (which
> >>can tell you
> > 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 :
> >
> >   2 - User joe can only create 10 pinholes or IP source can only
> > create 10 pinholes.
> >   3 - ...
>
> >>* Its also not clear to me that there aren't security holes in the
> >>whole thing that might enable someone to learn the passwords and
> >>usernames needed to control bindings for other IP addresses.
> >
> >
> > (USM/encryption) provided by SNMPv3 is strong enough so
> that it will
> > be hard for someone to break trough and discover the user
> > name/password or try to get unrestricted access.
>

---

From: Melinda Shore <[email-masked]>
Date: Mon, 3 May 2004 11:55:22 -0400

> DHCP or another means for configuring end-points might be needed.

These decisions are made by a triumvirate of the working group, the
ADs, and the chair.  I think that right now, given the circumstances
of this working group, it's reasonable to expect a certain level of
maturity in any ancillary work we agree to take on.  My personal bias
is that there's a role for the work in some future network that may or
may not come into existence but that it's less clear that there's a role
for it today.  That's why I'm interested in seeing the issues that
Jonathan raised be answered with something fairly specific.

The conditions that have to exist for the working group to recharter
to take on a new deliverable include but aren't limited to: 1) wg 
consensus,
2) AD agreement, 3) a recognized need for the work, 4) an understanding
of what effort would be required, 5) resources to satisfy the effort,
and 6) assurance that the completed work will receive expert review.
I think we're somewhat deficient on 3 and 6.

Melinda

---

From: "Joel Tran" <[email-masked]>
Date: Mon, 3 May 2004 14:53:29 -0400

Response inline.

> allow me to direct traffic at a target by faking my source IP

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.

In the second case, since a PPP connection is used, it is easy to detect and
filter sproofing with a proper rule.

...J

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 May 2004 21:00:11 -0400

> 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.

> 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.