MIDCOM Meeting Minutes, 50th IETF Chair: Melinda Shore Minutes: Ted Hardie March 22, 2001 Agenda: Agenda Bashing Update on Working Group Status Discussion of Framework Draft Discussion of Requirements Draft AOB Agree on next steps. Resulting Action Items: Both sets of document authors will present new versions of their drafts on the most aggressive schedule they can support. Those documents will eliminate references to the functions inside the middlebox and focus on the use of the midcom protocol. Members of the mailing list will send scenarios (use cases) for midcom to the authors of the framework document, who will incorporate appropriate scenarios into their document. Christian Huitema has volunteered to compose scenarios for the document. No resolution was reached on the inconsistent usage of definitions between the drafts; working members should propose specific text for the definition to the mailing list, which will need to resolve the inconsistencies. An interim meeting has been proposed in conjunction with the SIP summit in Richardson, TX. The SIP meeting is May 1 & May 2nd, 2001. The chair and ADs will discuss the scheduling of an interim meeting. The interim meeting will be focused on eliminating any remaining confusion on models, and attendees will be expected to volunteer to produce text for working group documents based on the results. The Chair reminded the working group that early review and objection was critical to meeting the time lines of the working group and urged working group members to make objections known as early as possible. Meeting Recap: The Chair began the meeting by saying that most important aim for the morning was to work through the drafts and eliminate any conflicts between them. She then began reviewing the status of the drafts. The deadline for both in the current milestones is August 2001, but the Chair hopes quicker progress can be made within the working group, in order to incorporate potential delay time at the IESG review stage. The Chair then stated that the group needs to resolve some definitions, both for the clarity of its own discussions and in order to assist the IETF as a whole. Among the terms which need clear definitions are: middlebox, proxy, Application Layer Gateway, and the various participants in a Midcom protocol exchange. Pyda Srisuresh then presented the framework draft. The main goal for the draft is to create an architecture for middleboxes needing to externalize application intelligence. That framework should guide the development of the midcom protocol, with especial guidance for the security necessary when connecting midcom agents to middlebox. The architecture is restricted to firewalls and NATs, in accordance with the group's charter, and it does not discuss discovery. The architecture presumes that there is a single midcom protocol interface, no matter what middlebox function or functions are in the midbox (i.e., the same interface for firewalls and nats). The current draft creates a taxonomy, however, for the midcom agents, dividing in-path midcom agents and out-of path midcom agents. A great deal of discussion from the floor challenged the distinction as written. Christian Huitema asked that "enterprise boundary" be eliminated from the description, as the use of "enterprise" might carry the wrong implication to some readers; he suggested "domain" as a possible replacement. It was suggested that a reference to Brian Carpenters Middlebox taxonomy document would be useful in clarifying the difference between in path and out-of path systems. Others felt that the basic distinction was flawed, as the functions were the same whether there were multiple boxes implementing those functions or note. The draft author asked for further review of the draft and asked for proposed language from those raising objections. The chair indicated that further examples would be useful, especially for out-of-path middlebox agents as the only example available appeared to be the decomposed NAT, where the ALG functions are diverted to external software processing boxes. A question on the floor asked for clarification between the middleboxes treated in this draft and those examined in OPES; the Chair responded that this is the transport layer, where OPES is application layer. Michael Condry suggested that further language in the draft to clarify which middle boxes are at issue would be useful. The author agreed to add such language. Christian Huitema pointed out that SIP proxies are in path for SIP messages, but out of path for media stream; he said that this seems to create confusion in the application of the in-path midcom agents. Author agreed to clarify that the signaling message path is meant in the existing distinction. Christian asked whether outsourced agents for some of these middleboxes would affect the architecture. In particular, he noted you lose implicit knowledge of the path if you have something like a sip proxy which may need to talk to firewalls in multiple exit points. Chair noted that the discovery of which firewall is salient is out of scope. Christian agreed that this was fine, but that there was a design implication that the signaling cannot assume anything about whether its messages will take the same path as the packet flows. Author agreed that this was a design implication.. After further discussion of the distinctions among packet flows, the AD asked to remember that we were not here to define the characteristics of a middle box, but to design a communication system to cope with them. Elements of the middlebox operation (like packet diversion) are out of scope except as related to midcom protocol signaling. Christian then indicated his belief that the confusion around some of these issues derived from the draft's never making clear the fundamental requirement of midcom, that we need a mechanism for allowing a client to open a tcp_listen in the presence of a NAT or a firewall. The group then moved on to a discussion of the requirements draft, presented by Richard Swale. He first noted that the document as developed in parallel with the framework, so there have been some cases in which the two have diverged in terminology and architecture. Discussion of the draft began with questions around the use of specific terms, such as "application client" and "application server", but moved quickly to a question of whether the draft serves the purpose of a requirements document at all. In particular, it was agreed that the document needs a set of scenarios or uses cases. The AD (Scott Bradner) noted that the draft contains descriptions of the middlebox functions which are valuable, but not appropriate for this draft. He asked that this draft focus more specifically on communication *to* the middlebox rather than the function within it. It was proposed that the current requirements draft be abandoned and the requirements should be redrafted with the caveat that the requirements draft should use only terms that are in the framework document, with a strong focus on service scenarios. The focus on scenarios was strongly supported, but it was not clear that the draft needed to be scrapped. After a suggestion from the floor that work on the requirements be suspended until the framework is completed, it was agreed that the working needed to work on both in parallel to achieve its milestones. The Chair asked both sets of document authors to eliminate text in their drafts that describes middlebox functioning unless that function is explicitly related to the processing of midcom messages. The Chair then asked that as part of their re-write, both sets of document author expand their security sections and examine the current text, as she believes it not correct. Eliot then asserted that flow direction is creating a problem in our understanding of these. He put forward an example derived from peer to peer communication (Gnutella). Some device with a fully public IP address A, initiates a communication with a device B, which is behind a firewall. How does device B get a publically addressable IP/PORT in order to be addressed by A? Scott Bradner asserted that a FQDN from a two faced DNS is the external binding, so that the original message goes to the client's inside address, at which point it requests an outside address. After a complain from the floor that none of the scenarios were written down in the drafts. Christian volunteered to writes scenarios. He then went back to Eliot's case, noting the case of a home network where an external port is mapped to an internal service; he wants a common way to do that mapping as it is currently being done in a proprietary way, using a very weak security model (inside/outside). He believes we need scenarios and an inventory of existing mechanisms (in use in home gateways, socks, etc.). Chair rules the second out of scope. Agreement among volunteer, chair, and AD on scenarios as use cases for the protocol, not of the middleboxes. Question from the floor about binding to ports; answer was that since it is not related to midcom function, it is a not issue. In a discussion about whether "inbound and outbound" do not have to be separate, the Chair noted that you might have a midcom policy on a per interface basis. After a further discussion of how complex the interface mappings might be, the Chair indicated that in this problem domain (firewalls and nats), that the inside/outside dual interface is a reasonable description. You might not want to see it not in interface terms, but in terms of source and destination address. Andrew noted that this might not be sufficient if the charter is to deal with what is actually out there, because there are firewalls that have multiple interfaces and there are NATs that care deeply about who session direction as well as interface direction. The Chair then concluded the meeting by reviewing the action items, noted above.