2.7.24 Middlebox Communication BOF (midcom)

Current Meeting Report

Notes from the MIDCOM BoF at the 49th IETF, 14th December 2000

Chair: Melinda Shore <mshore@cisco.com>
Reported by: Richard Swale <richard.swale@bt.com>


Agenda bashing and comments from the Area Director(s)/IAB
Charter and deliverables review, discussion
Related work in NAT working group
Architecture and requirements
Wrap-up and way forward



Opening remarks

Melinda set the context for the BoF and set down the principles for people to follow during the meeting - chiefly that there should be an exclusion of NAT bashing and other rhetoric. The goals for the BoF were to resolve charter issues, agree deliverables and schedule and begin work.

Agenda bashing and comments from the AD/IAB

No objections or comments were made to the proposed agenda.

Scott Bradner apologised for the changes in direction perceived from the previous Foglamps BoF at the 47th IETF. Since this time, it has become apparent that there are two scenarios that need to be considered by the group, one scenario involving a trusted and authorised agent interacting with a firewall/NAT, with the other scenario relating to the case where the end device takes more of its own responsibility and does not always have a trust relationship with the firewall/NAT. The requirement to consider the needs of both scenarios was therefore added to the charter. The scope was broadened beyond just VoIP to also consider the more generic problem. In short, the proposed working group will have to handle the trusted and un-trusted cases and make the problem more generic. Discovery of the middlebox was determined to be outside of the scope of the work of this working group and will be considered elsewhere.

Scott clarified that he saw the main focus would be two fold; to establish a solution to the "Punch this hole.", as in the first scenario, and "Here I am. I'm this application and punch this hole.", as in the second scenario.

Charter and deliverables review, discussion

Christian Huietima commented that the Application Identity and the User Identity were essential items and that this should not be tied to any particular application. Phil Mart observed that there was the need to also set limits on the scope of the authorisation/request.

The nature of the requests being supported by the protocol were discussed. This issue was raised on the list. The discussion concluded that the nature of the protocol should not preclude end-end applications such as end-end security.

The relationship between MIDCOM and other groups such as COPS working on policy was noted and it was agreed that reuse should be taken as a given.

Jonathan Rosenberg questioned the case of incoming VoIP calls as being a very real and specific problem that needs to be addressed. It was clarified that the MIDCOM box should be able to receive an incoming VoIP call and would then query an external policy entity to determine what should happen next.

Scott Bradner commented that he would like to see the group focus on a solution that was extensible into the future but that was not trying to be the general solution to everything on day one. i.e. Do something very specific but don't make it so specific that it can't be extended.

It was noted that there was a wide range of terminology being used by people for much the same thing. This was not helping the group make progress. Clarification of terminology was therefore a key point that needed to be addressed in the deliverables.

It had been suggested that the group should consider communications with entities in the transport layer, including firewalls, NATs etc. It was the consensus of the group that this should be so.

It had been suggested that the group should consider the need to make the solution extensible. It was the consensus of the group that this should be so.

Jiri Kuthan made the following three points that:

1. there should be a abstraction into specified layering (separation of application and network),
2. there should be extensibility of the solution in the context that there is the possibility of adding new support for new applications,
3. the extensible framework should be able to address the needs of firewalls and NATs.

These aims seemed to be in agreement with the group.

Brian Carpenter noted that there should be a focus on reuse of existing protocols where possible. Melinda noted that this point was within the charter text. Scott Bradner noted that the milestones agreed with the IESG specifically drove towards taking the work to the point of defining the concepts and requirements rather than developing a protocol at this stage.

Graham Travers noted that as worded, the charter would imply that if the group identified that additional fields were required in existing protocol it would have to re-charter. This did not seem to be a sensible approach and it was acknowledged that such simple steps should be addressed in the charter.

Further discussion reiterated the points made above. It was felt that the charter needs to be more explicit about deliverables, reuse of protocols etc.. Melinda said that the charter would be updated in line with the discussions and consensus points agreed and put back out on the list.

Related work in NAT working group

NAT API presentation; Pyda Srisuresh presented the work of the NAT Working Group. The NAT API draft looked at the problem from the point of view of the application interacting with the NAT device. There are a number of scenarios; a direct (transparent) connection between two clients through a NAT and indirect connection such as through a proxy. These models have differences in whether the client is aware of the NAT or not. There were questions around the registration sequences and also the need to support applications that need to have IP addressing information in sessions setup scenarios a prori.

Architecture and requirements

draft-fisk-midcom-session-00 presentation; the presentation considered the cases of communications with un-trusted end-points. There was the assertion that there was a trend towards clients being aware of middleboxes (http proxies etc.) and requesting functionality from these boxes. Christian Huitema noted that the requirements for the protocol postulated in the presentation were possibly met by SIP. However it was also noted that the requirements of the protocol were in fact more suited to RSVP than SIP as SIP may not pass along the path of the media streams etc.

draft-kuthan-midcom-framework-00; the draft contains a set of requirements and highlights the need to be able to decouple ALG from packet processing. The problem statement is that embedded ALG's are sub-optimal and this can be improved with the decomposition into a separated ALG and controlled device. The question was posed whether the working group should be working on the protocol between the ALG and the controlled device. It was agreed in the discussion that the working group should focus on packet filtering and not content inspection and that this should be noted in the working group charter.

draft-tiphon-foglamps-01; the draft presents a set of requirements and highlights the needs to open pin-holes and the context in which this would be required. The relationship between the controller and controlled entity was examined and it was determined that there needed to be a client-server model rather than simple master-slave as this enables the packet processing element to refuse requests. This basic architecture is as agreed on the list. It was seen that it is important to get the trust relationships correct. Scott Bradner noted that this did not seem to handle the un-trusted case and Paul acknowledged that he had omitted these flows from the presentation although they were supported. Christian Huitema thought the proposal was linking the call set up with the middlebox, this was not the case.

The following issues were raised. Does the middlebox need to reside within the data path? How is it addressed by the client? Does the middlebox need to communicate with other middleboxes? Scott Bradner noted that the framework needs to address the clarification of these issues.

Melinda noted that there were really three deliverable areas; Requirements, framework and applicability statement. Scott stated that the framework and applicability documents could be combined - there were no objections or counter proposals to doing this which were taken as agreement. Following the path of the AAA group in terms of identifying a candidate set of protocols was agreed as the way forward.

Wrap-up and way forward

There were no objections to the formation of a working group.

It was proposed that there could be a drafting session before the next IETF meeting, but it was agreed that there should be an attempt to make progress on the email list first before setting a meeting.

A separate group will be set up to consider the discovery part of the problem space and this has been specifically ruled out of scope for MIDCOM.

This other group will be announced on the main IETF list.


Middlebox Communication Framework and Requirements
Packet Forwarding Engine Control
Framework for interfacing with NAT