Subject: Re: [midcom] Reminder: wg last call

From: Daniel Fonseca <[email-masked]>
Date: Tue, 9 Sep 2003 07:50:02 -0700 (PDT)

Dear WG members,

	I am in the final semester of Computer Science, and
the subject of my undergraduate qualifying project
will be the kind of service this WG is attempting to
offer, with more focus on midcom itself.
	I have read the midcom RFCs and drafts written so
far, the mailing list messages, and part of the UPnP
documentation, but I have found very little more about
that kind of firewall/NAT/"middlebox" configuration on
the internet. There are a few presentations and
proprietary solutions, yet none of them discuss the
subject nearly as deep, or suggest a solution with the
required robustness and/or flexibility.
	If you know any other source of information regarding
this subject, either papers, web sites, presentations
or documentation of any sort, I would appreciate it if
you would send it to me.
	I have prepared my own set of comments on the latest
revision of the semantics, they are copied below.
Although most are type/grammar misspellings, maybe it
can be of some use to you.

Thanks in advance,

Daniel Fonseca
[email-masked]

-------------------------
-------------------------

Page 3, "... and the (4) reply and notification
messages send from the middlebox to the agent ...".
Should be "messages sent from the middlebox", right?

Page 7, "Convenience transaction simplify MIDCOM
sessions ...".
Should be "transactions".

Page 10, "... configuration of authorization at the
middelbox is ...".
Should be "middlebox".

Page 10, "- internal IP address wildcard support
          - external IP address wildcard support"
(I believe this has been mentioned recently in the
list)
It is very common for middlebox-ish devices to have
more than two interfaces. How is midcom going to
handle that? Shouldn't there be an interface-id? This
involves many other sections in the text.

Page 11, section 2.1.8: "A mandatory request
transaction must be offered to each of the
authenticated agents."
I think this paragraph gets confusing when it
approaches the difference between mandatory-optional
and (un)authorized transactions. Maybe not all
mandatory transactions should be offered to all
agents, and each agent could be offered only the
transactions it is authorized to perform. Is that off
scope?

Page 12, "All transaction are transmitted within this
MIDCOM session."
Should be "All transactions are ...", or even "Every
transaction must be ...".

Page 16, Figure 2.
Forgive me if I have skipped or forgotten something,
but with the info up to this point in the text, I had
no clue how "mc=0" relates to a successful middlebox
challenge. The idea is understood, but why is mc
supposed to be 0, not "OK" or "success"?

Page 18, "Each policy rule is member of exactly one
policy rule group."
Although this seems to be a deliberate decision, but I
would like to know why a rule can't be on more than
one group, for it could be helpful. Ease of
implementation?

Page 20, "... address tuple A0 specifies a
communication endpoint of a devices within ..."
Should be either "of all devices", "of a device", or
even "of devices".

Page 21, "For the transport protcols TCP and UDP ..."
Should be "protocols".

Page 21, "The MIDCOM semantics defined in this
document define the handling of IPv4 and IPv6 as
network protocols.  For the transport protcols TCP and
UDP over either IPv4 or IPv6 are supported."
I believe readability would improve if it were
rephrased as "The MIDCOM semantics defined in this
document define the handling of IPv4 and IPv6 as
network protocols, and of TCP and UDP (over IPv4 or
IPv6) as transport protocols."

Page 21, "The value of the transport protocol
parameter can have one of the following values: 'TCP',
'UDP', 'ANY'."
The value can have a value? Just for clarification,
this could be rephrased as "The value of the transport
protocol parameter can be either 'TCP', 'UDP' or
'ANY'."

Page 22, the last paragraph of section 2.3.6.
That's a verbose description of what a port range
means. Assuming the reader is familiar with the
normative reference documents, I think that entire
paragraph is unnecessary.

Page 23, "- mode: the requested NAT mode of the
middlebox. Allowed values are 'traditional' or
'twice'."
How about changing the name of this paramenter to
"service", or something more flexible than "mode". I
think that would maintain current meaning, and allow
other types of services (maybe firewall could have its
own service).

Page 25, "The middelbox always reserves ..."
Should be "middlebox".

Page 28, "This transactions can be used ..."
Should be "This transaction".

Page 32, "A failure reply implies that the lifetime of
the policy rule remains unchanged.  A success reply is
generated by the middlebox, if the lifetime of the
policy rule was changed in any way."
I know this should hardly ever happen, but the case of
a RLC attempting to set the new lifetime to the exact
current lifetime value was not covered. That should be
a success, right? How about rephrasing the first
sentence above to "A failure reply implies that the
new lifetime was not accepted, and the policy rule
remains unchanged." ?

Page 34, "- port range: the number of consecutive
ports numbers, see Section 2.3.5."
Should be "consecutive port numbers".

Page 43, "This multiple fine-grained transactions must
further met the atomicity requirement stated in
section 2.1.3."
Should be "These multiple fine-grained transactions
must further meet the atomicity ..."

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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

---

From: Jürgen Quittek <[email-masked]>
Date: Thu, 11 Sep 2003 14:38:37 +0200

Daniel,

Thank you very much for all your comments.

Most of them are very helpful and we will apply them.
Please see detailed replies inline.

> can be of some use to you.

Right. Fixed.

> Should be "transactions".

Fixed.

> Page 10, "... configuration of authorization at the

Fixed.

> involves many other sections in the text.

In the MIDCOM information model there is just an internal
(protected, private, ...) network and and external (public?)
network. How many interfaces of a middlebox are connected to
which of these two networks is not of interest to applications
requesting the box to just ENABLE communication between two
specified end points. Which interfaces are involved in serving
such a request needs to be identified by the middlebox internally.

> transactions it is authorized to perform. Is that off

You are right. This is confusing. We will re-phrase this
paragraph in a - hopefully- much clearer way when editing
the next version.

> transaction must be ...".

Fixed.

> supposed to be 0, not "OK" or "success"?

Well, the intention was to say "mc=empty".
Another point where re-phrasing is required
for the next version.

> one group, for it could be helpful. Ease of

Not just of the implementation. Also of the specification.
If you want to have multiple membership, you need additional
transactions or extended existing transactions configuring
this and probably also changing a policy rule's membership.
Is there a trong requirement that justifies such an increase
in complexity?

> Should be either "of all devices", "of a device", or

"a device" is correct. Fixed.

> Page 21, "For the transport protcols TCP and UDP ..."

Fixed.

> document define the handling of IPv4 and IPv6 as

We should replace "define" by "specifies".

> IPv6) as transport protocols."

Yes, thank you.

> protocol parameter can be either 'TCP', 'UDP' or

Fixed.

> paragraph is unnecessary.

Can you give a good normative reference defining "port range"?

> other types of services (maybe firewall could have its

Agreed.

> Page 25, "The middelbox always reserves ..."

Fixed.

> Should be "This transaction".

Fixed.

> new lifetime was not accepted, and the policy rule

Good catch! Fixed.

> Should be "consecutive port numbers".

Fixed.

> must further meet the atomicity ..."

Fixed.

No, I don't.

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 15 Sep 2003 08:06:58 -0700 (PDT)

> Please see detailed replies inline.
<... stuff deleted>

> such a request needs to be identified by the middlebox internally.

Juergen - If you have several interfaces on the private realm and a interface
on the public relam, you might choose to have NAT/FW configured on just the
public interface. No problem with that. It is OK to use an information model a
describe a theory of operation. But, the model cannot be imposed as is on the
middleboxes. A middlebox may be attached to several overlapping private
networks. A middlebox may also have several public interfaces (combination of
V4 and v6). For these reasons, a middlebox must be configurable on a
per-interface basis.

<.. stuff deleted>

=====

---

From: Jürgen Quittek <[email-masked]>
Date: Tue, 16 Sep 2003 12:19:52 +0200

Pyda,

--On 15.09.2003 8:06 Uhr -0700 Pyda Srisuresh <[email-masked]> wrote:

>
> --- J¸rgen_Quittek <[email-masked]> wrote:
>> Daniel,
>>
> middleboxes.

I do not see any reason why not. The information contained in the model is
sufficient to clearly specify the required configuration.

> A middlebox may be attached to several overlapping private

I would agree completely if we were talking about a middlebox management MIB
module. But we are not.

The goal of the MIDCOM protocol is not managing middleboxes.

The goal is allowing agents to request the middlebox to enable
communication between specified end points.

What is the correct middlebox configuration that enables the specified
stream of packets has to be determined by the middlebox, not by the agent!

Imagine a combined box integrating firewall and NAT. It would be a tough
job for the agent to find out
  - which interfaces are passed by the specified packets
  - which interfaces are served by the firewall
  - how firewall and NAT interact
    (maybe the FW is passed twice, once before and once after
     address translation. Then you need to configure two firewall
     rules per direction)

Also it is a tough job configuring a firewall correctly in case
of overlapping rules. Prioritization (or just ordering) of rules
is very important.

All this is not a job of - say - a SIP server or a video conferencing
server that wants to request middleboxes to enable communication across it.

Still the information sent from such a server to a middlebox as defined
in the current version of the semantics document should be completely
sufficient for the middlebox to determine which interfaces to use, which
firewall rule priority is required, and how many firewall entries are
necessary for correctly configuring an integrated NAT/FW.

Thus I think the current model is sufficient and can be applied by
the middlebox correctly. The complexity of transforming the requests
to low level middlebox configuration is a burden of the middlebox.
But this is fine. If the middlebox is a very small and simple device,
also the transformation is very simple. If the middlebox is complex,
then also the complexity of the transformation is higher. This scaleable
approach is much better than requesting every MIDCOM agent to be able
to manage any kind of complex middleboxes.

Cheers,

    Juergen