Subject: RE: [midcom] Framework draft review

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 18 Jun 2001 10:25:59 -0500

Here're some feedback from myself & Mary Barnes on the Framework draft.
Please find our comments within the delimiters, such as [SS] and [/SS]. 

Regards,
Sanjoy

=======================
1. Introduction 
----------------

3rd sentence: Network Address Translator service, on the other hand,
provides routing transparency across address realms (within IPv4 routing
network or across V4 and V6 routing realms). Application Level gateways
(ALGs) are used in conjunction with NAT to provide end-to-end transparency
for many of the applications. 

[MB] I think this has already been discussed before, but transparency is not
a term here for either of these sentences.  I would suggest rewording these
2 sentences as:

The address mapping of Network Address Translation (within IPv4 routing
network or across V4 and V6 routing realms), however, is independent from
the end application. An Application Level Gateway (ALG) used in conjunction
with NAT can remove the knowledge of NATs for applications for which NATs
are problematic. [/MB]

2.5. Proxy

   A proxy is an intermediate relay agent between clients and servers 
   of an application, relaying application messages between the two. 
   Proxies use special protocol mechanisms to communicate with proxy 
   clients and relay client data to servers and vice versa. 

[SS] The proxies described here are application layer proxies. There're
other types of proxies which relays the transport stream (Transport layer
proxies), such as an RTP proxy, without higher layer application awareness.
These two types should perhaps be distinguished. The reason is that while
application layer proxies can be a type of Midcom agent, the transport layer
proxies can be a type of Middle-Box (and I think that Midcom is a general
framework with the eventual goal of addressing all kinds of Middleboxes).
Proxies which are application-unaware but need application-specific
intelligence are also Middle-boxes. [/SS]

2.8. MIDCOM Agents

   MIDCOM agents are entities performing ALG function, ...

[SS] Why only ALG's? Application layer proxies (since you've distinguished
between ALG's & proxies) can also be Midcom agents, as you've provided some
examples in the next paragraph. [/SS]

   The protocol will allow MIDCOM agents to signal
   the middleboxes to let complex applications using dynamic port 
   based sessions through them (i.e., middleboxes) seamlessly.

[SS] There are additional protocol requirements which may need to be
addressed here (or perhaps in the Requirements draft), such as the
following. The protocol should allow exchange of state synchronization
information (such as resource availability, state of the binding in case
NAT's, health-checks etc) between the Midcom Agent & the Middle-box. The
protocol should also allow modification of state in the Middle-box during
runtime. The protocol should be able to specify direction of the connection
through the Middle-box. [/SS]

   Connection setup must be preceded by registration of the
   MIDCOM agent with either the middlebox or the Policy Server.

[SS] There might be situations where this registration process is initiated
by the Middle-box itself. So, isn't it better to phrase the above sentence
as "Connection set-up must be preceded by a registration phase between the
Midcom agent and either the Middle-box or the Policy server". This also
concurrs more with the text in the Protocol Requirements DRAFT. [/SS]

   Alternately, a MIDCOM session termination may be triggered by
   one of (a) agent going out of service and not being available
   for further MIDCOM operations, ....

[SS] It would also be triggered by the Middle-box going out of service.
[/SS]

   During connection establishment, an agent would identify
   itself as either In-Path or Out-Of-Path(OOP) to the middlebox.

[SS] This should be during Registration phase, right? 
Is support of OOP Midcom agent (& the associated "diversion" function in the
Middle-box), mandatory under the framework or is it optional? This should be
mentioned too. [/SS]

   Profile of a MIDCOM agent includes agent authorization policy (i.e, 
   session tuples for which the agent is authorized to act as ALG), ...

[SS] Please define Session Tuple. If its the Session id <Src./Dest. IP
address/port, protocol>, then in many cases, the MA doesn't know about it
until the session is being initiated (e.g., SIP session). It may not be
possible for the MA to have this information during the time of
registration. [/SS]

4. MIDCOM Protocol

[MB] Initially, I was in agreement with Eric Fleishman's comments that the
last 2 paragraphs of Section 4 are misplaced as they describe functionality
of the Middlebox (stateful vs. stateless) rather than the protocol itself.
However, in re-reading, I think that the concept is also protocol related
(i.e. which messages effect a change in the Protocol state machine).
Perhaps, there needs to be a paragraph in Section 3 such as:

   Some middlebox services are stateless. However, there are many that
   are stateful and maintain per-connection state in the system.
   Firewall service may be implemented as a stateless list of ACLs.
   Many firewall implementations, however, are stateful. NAT
   service, on the other hand, is inherently stateful. As such, 
   support of the MIDCOM protocol will require a middlebox to be
   stateful. Refer to Section 4.0 for further detail.     

And a paragraph in Section 4 (replacing the current last 2 paragraphs) that
reads something like:

   The MIDCOM protocol may require a middlebox to be
   stateful. For the case of a middlebox implementing firewall
   service, with the advent of MIDCOM protocol, the middlebox is
   required to allocate dynamic resources, such as pin-holes,
   upon request from agents. Explicit release of dynamically
   allocated resources happens when the application session is 
   ended or when a Midcom agent requests the middlebox to release
   the resource. However, the middlebox must be able to recover the
   dynamically allocated resources at some point in time even if 
   the agent that was responsible for the dynamic allocation is not
   alive. Typically, this is done by tracking the state of each
   dynamically allocated pin-hole with some type of a timer. 
   This exemplifies that even the firewall function will need to
   maintain per-connection state, as a requirement to support the
   MIDCOM protocol. 

[/MB]

   The technique described above is necessary for the pre-registration of
MIDCOM agents with the 
   Middlebox. However, it is possible to retain the provisioning on
middlebox unchanged, by 
   requiring MIDCOM agents to initiate the connection to middlebox. In such
a case, the
   agent should initiate the connection prior to the start of the
   application. ...

[SS] I assume that you're talking about Registration connection here. How
does the Midcom agent know when to initiate this connection? Again, going
back to the SIP example, the agent can only initiate the connection on
receipt of a SIP INVITE message. It makes sense to me for apriori
registration between the MB & MA, & MA be ready for connection set-up
whenever required. The registration is refreshed periodically. [/SS]

[SS] Typo in the third line of last para of page 20 - "... media stream,
When used"  [/SS]

Section 7.3 - Middlebox implementing NAPT & Firewall call flows: 

   |                 |                      |              |
   |                 |++Permit RTP1 & RTCP1 |              |
   |                 |  sessions External to|              |
   |                 |  middlebox, namely   |              |
   |                 |  Ma to Ea:Eport1,    |              |
   |                 |  Ma to Ea:Eport1+1   |              |
   |                 |  sessions ++++++++++>|              |
   |                 |<+Ma to Ea:Eport1,    |              |
   |                 |  Ma to Ea:Eport1+1     |              |
   |                 |  sessions OKed ++++++|              

[SS] Should this be Ma or is it Pa?  

For certain types of NAPT, you won't be able to complete the binding &
update the NAPT table until you know the port address of the callee, which
is not part of the SDP in INVITE. In many cases, the SDP of the callee
(containing the port) is carried in the provisional response 180/183, and
Early Media follows the provisional response. The MA should be able to
complete the NAPT binding based on the SDP of the callee in the response
message, to allow early media. [/SS] 

9.3. Asynchronous notification to MIDCOM agents

   Asynchronous notification by the middlebox to a MIDCOM agent
   can be useful for events such as Session creation, Session 
   termination, MIDCOM protocol failure, Middlebox function 
   failure or any other significant event. Independently, ICMP
   error codes can also be useful to notify transport layer
   failures to the agents. ...

[SS] We should perhaps also include the following:
	- Exchange state synchronization information (described earlier)
	- Periodic health check message exchange
	- MB send logs of unauthorized access & unsolicitated alarms to the
MA
[/SS] 

Regards,
Sanjoy Sen

---

From: "Sanjoy Sen" <[email-masked]>
Date: Sun, 24 Jun 2001 12:38:02 -0500

Had posted this to the mailing list about a week back. Not sure whether it
reached the authors as I didn't get any response from them. 
 
Rgds,
Sanjoy

Subject: RE: [midcom] Framework draft review

Regards, 
Sanjoy 

======================= 
1. Introduction 
---------------- 

2.5. Proxy 

2.8. MIDCOM Agents 

4. MIDCOM Protocol 

[/MB] 

   |                 |                      |              | 

Regards, 
Sanjoy Sen