Subject: RE: [midcom] Protocol Requirements Bullet List v2.0

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 2 Apr 2001 02:51:49 -0400

> -----Original Message-----
> From: Shai Mohaban [mailto:[email-masked]]
> Sent: Friday, March 30, 2001 5:08 PM
> To: Andrew Molitor; [email-masked]
> Subject: RE: [midcom] Protocol Requirements Bullet List v2.0
> 
> - Besides packet/flow dropping and network address 
> translation few examples
> of other MidBox primitives include transcoding, encryption 
> and IPv4-IPv6
> translations. I am sure there are many others.

Definitely. However, we need to focus on NAT and firewall. Anything else is
covered by the "protocol should be extensible to other middlebox functions"
requirement.

> - According to section 3.4 the default behavior of the MidBox 
> is not to let
> packets pass through it. I think this default behavior should be
> configurable (and policy driven) as the requirement may be 
> different for
> different applications. E.g. in case of a QoS MidBox I think 
> this will not
> be the default behavior.

There are monsters lurking in this requirement. Big, scary, monsters.

They have to do with the very important requirement, IMHO, that multiple
midcom controllers (aka clients, agents, whatever. Client is simplest for
me) be able to make use of the same middlebox. If you want to ever have load
balancing across proxies, this is an absolute requirement. Once you do this,
you run into the interesting problem of resolving overlapping or conflicting
requests.

It so happens, that if the default operation of the firewall is "deny", and
the only firewall operation possible is "open", then there are no conflicts,
in fact. You can construct a global set of rules for the firewall which meet
the requests made by all midcom clients. However, as soon as the default
operation is no longer "deny", but rather, "pass everything", this means you
need midcom operations like "disallow packets from A to B". Now, you can no
longer construct a set of rules for the firewall which meet requests made by
all midcom clients. This leads you to prioritization, confict management,
rule merging, and all kinds of assorted headaches that we may not want to
have.

I believe that the task before us is quite formidable even in its simplest
formulation. Clear evidence of this is that, even after nearly a year of
discussion, we are still not in agreement on framework and terminology. So,
to finish this side of 2010, I would propose we keep things simple. Lets
first solve the problem of default-deny firewalls, and nats, and thats it.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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