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

> -----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
>
>
>
>
> Joel Tran wrote:
>
>
> >>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.
> >
> >
> > 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.
>
> 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:

Yes I ment something like this. Something like the 1st Tuple of the Midcom
entry has to be the IP adresse of the client/IP address from where the
message is originating.

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

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

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

In my understanding (from the mailing list), Midcom MIB document is not
finished yet. Probably we will have to wait to see if the MIB will have
sufficient ACLs.

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

In general, I do agree with you. However, in this case I was only trying to
find a solution in order to provide a full peer to peer solution (not only
for SIP where a server can be the trusted control certer) for various kind
of topology.

...J

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