Subject: [midcom] More on new work item

From: Melinda Shore <[email-masked]>
Date: Mon, 26 Apr 2004 08:00:46 -0400

There's been no feedback on the proposed charter change, which concerns
me.  I hope that people will speak up regardless of whether they think
the proposed work item is a good idea or a bad idea.

I don't think getting the work done would be an issue - there are
always people willing to author documents.  However, getting people
to *review* documents is far more difficult, and I don't think we can
allow work to go forward if we don't have a reasonable expectation
that people with subject area expertise - in this case, the midcom
working group - are willing to take the time to provide expert review
as the document is progressed.  I don't want to make any assumptions
about what the lack of feedback means, so even a simple "yes" or "no"
on the proposed work item would be much appreciated.

Thanks,

Melinda

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Apr 2004 16:47:08 -0400

I'm not sure we should take on these work items. My concerns are mostly 
practical.

I think we agree that DHCP applicability is only in very, very limited 
topologies - only in simple stub networks where an end user client would 
normally directly talk to a nat. This would really be limited to 
consumers with home nats, or to enterprises. I think its unlikely that 
an enterprise would actually allow end clients to control the nat, due 
to the serious potential for abuse (imagine a virus infecting a PC, 
causing it to ask the middlebox to open all ports to all addresses). As 
such, I dont think this is workable in enterprise.

That leaves home NAT. However, do we think that manufacturers of such 
devices are likely to support midcom? I'd like to hear from one on this 
list. If not, this work item would be useful only in theory. Even if 
they did, how would we expect the clients to be configured with the 
security credentials needed to exercise midcom control over their nat? 
If such information is manually configured into the client, why can't 
you manually configure the IP of the home NAT as well?

Thanks,
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

---

From: "Christopher A. Martin" <[email-masked]>
Date: Mon, 26 Apr 2004 17:26:44 -0500

I totally agree with Jonathan's position on the scope of DHCP as
outlined below. 

Either way though, IMHO, MIDCOM does not appear to be useful for
anything other than a carrier deployment or in a large enterprise
deployment that controls all aspects of a MIDCOM deployment, just from a
business/security policy perspective. I say this due to the very points
brought up in Jonathans last sentence WRT configuring the NAT IP.

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Monday, April 26, 2004 3:47 PM
To: Melinda Shore
Cc: [email-masked]
Subject: Re: [midcom] More on new work item

Thanks,
Jonathan R.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 28 Apr 2004 19:58:44 -0400

Here's what I'd like to do:

Jonathan raised some good questions.  I'm not sure I agree with some
of his assumptions, but the question remains: is there an expectation
that someone would actually want to use DHCP to configure middlebox
addresses into endpoints, or is this an apparently reasonable idea that
won't be used in practice?

If we can't foresee a reasonable expectation that the work would have
real-world utility we should probably let it drop, and do so quickly.
If we do think the work is useful we should move it along as rapidly
as would be reasonable.  The main thing is that I'd like to avoid 
dinking
around with this, and I hope we can reach resolution quickly.  So, if
anybody wants to argue in favor of the applicability of the work, now's
the time.

Thanks,

Melinda

---

From: "Joel Tran" <[email-masked]>
Date: Thu, 29 Apr 2004 11:05:21 -0400

Jonathan Rosenberg, you raised a good point.

There are however some ISPs that are deploying NAT/Firewall (i.e. China,
Europe, Africa). In such case, DHCP might be useful. The ISP might do some
load balancing. Thus, DHCP method will provide a mean for the ISP to
configure dynamically third-end party devices. As for the security
information, this might be entered by the user to the third-end party device
(ex: same id/password as for the ADSL authentication).

...J

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De
> la part de Jonathan Rosenberg
> Envoyé : 26 avril, 2004 16:47
> À : Melinda Shore
> Cc : [email-masked]
> Objet : Re: [midcom] More on new work item
>
>
> > There's been no feedback on the proposed charter change, which
> > concerns me.  I hope that people will speak up regardless
> of whether
> > they think the proposed work item is a good idea or a bad idea.
> >
> > always people willing to author documents.  However,
> getting people to
> > *review* documents is far more difficult, and I don't think we can

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Apr 2004 17:53:52 -0400

> (ex: same id/password as for the ADSL authentication).

There is a serious trust issue here. Is the ISP really going to issue a 
username and password to every user of their network, entrusting them 
with permissions to use midcom to manage port bindings on their network 
wide NAT?? I certainly hope not. Thats an open invitation for 
substantial denial of service attacks.

-Jonathan R.

---

From: Joel Tran <[email-masked]>
Date: Fri, 30 Apr 2004 10:38:20 -0400

> substantial denial of service attacks.

Correct me if I'm wrong. I don't think it is an open invitation for DOS attack 
if there is a proper Access Control List/Policy Rule in the Midcom device which 
may limit the use of the port bindings for each user. 

...J

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Apr 2004 11:42:19 -0400

> may limit the use of the port bindings for each user. 

I don't think this can work easily.

How would the ACL be structured? Presumably, you'd want to say something 
like, "user joe is allowed to open up pinholes directed to his currently 
allocated IP address". There are several major problems here:

* 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

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

* 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 dont know whether the MIBs include sufficient ACLs for the above to 
work (have not looked)

IMHO, the topological issues with midcom, which we have long been aware 
of, combined with the CONTROL nature of the relationship between the 
agent and the client, really point to applicability limited to a trusted 
  device that controls a neighboring firewall or NAT, thus useful for 
carrier edge or large enterprise edge applications.

-Jonathan R.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 30 Apr 2004 13:36:15 -0400

On Friday, April 30, 2004, at 11:42 AM, Jonathan Rosenberg wrote:
> IMHO, the topological issues with midcom, which we have long been 
> aware of, combined with the CONTROL nature of the relationship between 
> the agent and the client, really point to applicability limited to a 
> trusted  device that controls a neighboring firewall or NAT, thus 
> useful for carrier edge or large enterprise edge applications.

I think incrementalism in design (not in deployment) is causing some
problems here.  Network administrators, and a growing number of people
in the industry, are increasingly aware that the current model for
mediating access isn't very effective (and that ties quite directly to
the question of what the trust bases are).  That means a couple of 
things,
including that there are now at least two models for provisioning trust:
1) profile, and 2) credentials.  In the former case a "profile" might
mean something like "is running version whatever of anti-virus software
blah".  "Credentials" is obvious and is more directly relevant to
what we're talking about.  It's a shame that the distributed firewalls
stuff never took off, because that, at least, could provide a workable
framework for talking about endpoint trust and access issues.  I think
we're being a bit short-sighted but I'm not sure I see a way to avoid
that under the circumstances.  It may be sufficient to allow industry
to drive this one and bring work to the IETF when it's already mature.

Melinda