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

["Joel Tran" <joel.tran at USherbrooke.ca>]

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



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