[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



inline.

Joel Tran wrote:

-----Message d'origine-----
De : Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Envoyé : 30 avril, 2004 11:42
À : Joel Tran
Cc : 'Melinda Shore'; midcom@ietf.org
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
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