Subject: RE: [midcom] Framework draft review

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 5 Jul 2001 10:53:46 -0700 (PDT)

--- Sanjoy Sen <[email-masked]> wrote:
> 
> 
> 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
> 

Thanks. Sorry about the delay in responding.

> =======================
> 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]
> 

I believe, I addressed this in a different thread with Brian Carpenter
and Scott Brim. Thanks.

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

You are right. Some proxies can be application unaware. 
But, all Proxy clients (i.e., applications using proxy servers)
are aware of proxies. 

In any case, the description in the document is not restricted to
application specific proxies, as you claim.

> 
> 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]
> 
These are protocol Requirements. Not addressed here.
 
>    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]
>

I belive, the text as it exists, reads fine. Registration here specifically
refers to registration of MIDCOM agents.
 
>    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]
>

Sure. I will fix the text to reflect this. Thanks.

>    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]
> 
The document will be revised to remove discussion on OOP agents.

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

I will remove both these paragraphs from the document and 
simply add a section titled "Timers on Middlebox considered useful"
in the Operational Considerations section.

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

That may very well be the case.
(i.e., apriori connection between MB and MA).

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

> 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?  
> 
It is Ma.

> 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] 
>
In order for the early media messages to reach the caller, it should
be OK to open UDP sessions from any port of the callee to caller.
 
> 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

Please see my comments above about creating a new section 
titled "Timers on Middlebox considered useful".
 
> 	- MB send logs of unauthorized access & unsolicitated alarms to the
> MA

This sounds like generic middlebox managment/monitoring requirement.
Not sure, this is MA specific. 

In any case, I believe, mention of "periodic notification of various
forms of data  such as statistics update" would cover any specific
cases that may be required by an MA.

> [/SS] 
> Regards,
> Sanjoy Sen

Thanks.

cheers,
suresh

=====

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

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

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 6 Jul 2001 12:09:09 -0400

> I believe, I addressed this in a different thread with Brian Carpenter

Actually we didn't reach agreement.  I dropped it because I felt that it
wasn't productive to pursue it when we had much bigger issues to deal
with, like requirements.