Current Meeting Report
Jabber Logs

2.8.8 Middlebox Communication (midcom)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/24/2002

Melinda Shore <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
Scott Bradner <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe your_email_address
Description of Working Group:
As trusted third parties are increasingly being asked to make policy decisions on behalf of the various entities participating in an application's operation, a need has developed for applications to be able to communicate their needs to the devices in the network that provide transport policy enforcement. Examples of these devices include firewalls, network address translators (both within and between address families), signature management for intrusion detection systems, and multimedia buffer management. These devices are a subset of what can be referred to as 'middleboxes.'

This working group will focus its attention on communication with firewalls and network address translators (including translation between IPv6 and IPv4). Work will not preclude extensibility to other categories of middle box.

Decomposing applications requiring policy decisions by removing application logic from the middle box and instead providing a generalized communications interface provides a number of benefits, including improved performance, lower software development and maintenance costs, improved ability to support traversal of packet filters by complex protocols, easier deployment of new applications, and the ability to consolidate management functions. For example, by moving stateful inspection of protocols such as H.323 and SIP out of firewalls, it is possible to improve performance and scalability and reduce development and costs.

This working group will concern itself with an environment that consists of:

- one or more middle boxes in the data path

- an external requesting entity

- a policy entity for consultation purposes when the requesting entity is untrusted.

The requesting entity may be trusted or untrusted. In the case where it is trusted, the middle box will treat the request from the entity as authoritative. In the case where it is not trusted, the intermediate device will have to verify that it is authorized to complete the request. That authorization could come from a separate or a built in policy server.

The primary focus of the working group will be the application of this architecture to communicating requests between applications and firewalls or NATs. This will not preclude other uses, and care will be taken to ensure that the protocol is extensible.

The working group will evaluate existing IETF protocols for their applicability to this problem, using the framework and requirements documents developed during the working group's first phase as criteria for the evaluation. If a protocol is found to be suitable it will be used as the basis for the development of a middlebox communication protocol. In the unlikely case that one is not found to be suitable, the working group will undertake development of a new protocol.

Discovery of middle boxes is out of scope.

The deliverables will be

o a document evaluating existing IETF protocols for their suitability

o a document specifying a middlebox communication protocol or profile based on the results of the protocol evaluation.

This working group will only deal with firewalls and network address translators.

Ubiquitous deployment of midcom in all middleboxes could take many years. In the interim, a solution is needed that allows applications to operate in the presence of midcom-unaware middleboxes. To support this, the midcom group will develop or document a protocol or approach that allows clients to indirectly obtain address bindings from midcom- unaware middleboxes, through communications with server elements on the public side of the middlebox. The key goals for this effort are rapid delivery of a simple solution (since it is an interim solution), consistency with the midcom framework, and security. In particular, any proposed interim approaches will address (and document) the architectural and pragmatic concerns described in [UNSAF].

Goals and Milestones:
Done  submit Internet-Drafts of framework, architecture and interfaces documents to IESG for publication as Informational RFCs
APR 02  Submission of STUN document for standards-track publication
MAY 02  Submission of pre-midcom document describing protocol for NAT traversal using relay for standards-track publication
AUG 02  Submission of document evaluating existing IETF protocols against midcom framework and requirements for an Informational RFC.
DEC 02  Submission of midcom protocol for standards-track publication
  • - draft-ietf-midcom-framework-07.txt
  • - draft-ietf-midcom-requirements-05.txt
  • - draft-ietf-midcom-stun-01.txt
  • - draft-ietf-midcom-protocol-eval-03.txt
  • No Request For Comments

    Current Meeting Report

    Minutes of midcom working group at 55th IETF Meeting,
    Atlanta, Georgia, USA
    Chaired by Melinda Shore (
    Reported by Bob Penfield (, edited by Melinda 
    Status update
    - The STUN document has come back from the IESG with some issues that 
    require a Working Group decision (see STUN section below)
    - SPAN has been cancelled due to lack of interest and activity on the list 
    and due to intractable security problems.
    Protocol evaluation:
    - The protocol evaluation document came back from the IESG.  The most 
    significant issue was there desire for more detail in the SNMP 
     - The two semantics documents have been combined into a single 
    - The original milestone was to complete a protocol document by 
    December which obviously will not be achieved. We do need to "choose" one of 
    the candidate protocols as a based in the next month.
    - There was a discussion on whether the STUN document would have to go thru 
    WGLC again. A couple of people felt that the changes required were not 
    significant enough to warrant a new WGLC.
    STUN - draft-ietf-midcom-stun-03.txt
    Jonathan Rosenberg went over the STUN issues raised by the IESG.  Most of 
    them are clarifications including text to point out the known 
    limitations when both sides of a communication are behind the same NAT:
    The issues requiring resolution are:
    1) Response Codes - the IESG felt that the response codes should conform to 
    other IETF protocols (e.g. SIP, HTTP, etc).  The proposed resolution is to 
    define 4xx & 5xx class responses an behavior consistent with the other 
    protocols. 1xx are to be avoided, 3xx do not apply. Currently, the error 
    response and success response are 2 different messages so an error 
    response would never contain a 2xx response code. One person was a little 
    uncomfortable with not having 2xx response code (they will discuss 
    2) Unknown Attributes. The spec says that unknown attributes should just be 
    discarded. This is broken. Proposal is to send back an error response 
    (with code like 420) and a list of unrecognized attributes.
    3) Flags Extension. What happens when there are more than 32 flags? The 
    proposal is to use the length in the TLV to indicate how many flags are 
    present. There was some discussion about making the flags field shorter 
    since we have committed to not extend the protocol, and whether 
    implementers would ignore the length field.
    4) No IANA procedures. Even if you are not going to allow extensions you 
    need to say that. There is already some extensibility built in.  It was 
    proposed that a standards track RFC be required to extend it.  Some felt it 
    should require a new version of the protocol, but that was too extreme for 
    many people.
    5) Reflector Attack vulnerability with the RESPONSE_ADDRESS 
    attribute.  Proposal is too include a REFLECTED-FROM attribute to 
    identify who sent the original request. This would be from the TLS 
    connection that established the username and password. Some felt this was 
    too complicated with little benefit.  It was suggested that the STUN 
    packets need to be easily identifiable so that routers could discard them. 
    This issue requires further discussion on the mailing list.
    6) Client Certificates are considered harmful. The spec currently says they 
    MAY be used. Proposal is to change to "MUST NOT use".
    7) No recommendations for stateless generation of 
    username/password. Steve Bellovin has recommended an algorithm. The 
    Proposal is to include the algorithm as non-normative text as an example of 
    how one could do this.
    8) Remove IPv6 Support. Since this is a short-term protocol to work 
    around problem of IPv4 NATs, the IESG does not want IPv6 support. The 
    proposal was to remove the v6 family. Some felt the address family should be 
    removed altogether because people could hack in IPv6 support.
    9) Discard Flag is broken. Was used to prime the NAT with suicide 
    packets.  It does not work because you need the response to know the 
    packet got thru.  Proposal is to remove the discard flag.
    Some of these issues require further list discussion, but they need to be 
    resolved quickly so that the spec can proceed.
    Midcom protocol semantics - 
    Martin Stiemerling presented the Semantics document issues.
    - There is now one combined semantics document.
    - There is one transaction set for Firewall and NAT.
    - Works on first-come, first-served basis.
    - Goal is to keep the semantics simple & stupid.
    - Why PRR? Need to do the binding to complete the 5-tuple in order for 
    agent to pass on signaling message. Should return values reflect the 
    presence of twice-NAT?
    - Should the group establishment transaction be removed?
    - Wildcarding needs list discussion
    - Return Values: Should full 5-tuple be included in response so that 
    FW/NAT function is transparent to the agent?
    - Should PER be split into two requests?
    - Message Queuing. Transactions need to be atomic and operate on first come 
    first served basis.
    - Capabilities exchange: is list in spec complete?
    - Encryption Method - It was pointed out that the encryption method and 
    keying needs to be decoupled. Issue needs list discussion.
    It was reported that the NSIS WG had discussed using CASP and TIST to talk to 
    Midcom protocol evaluation - 
    Mary Barnes presented status of the protocol evaluation document.
    The document case back from the IESG. The main issue is that they wanted a 
    revamp of the SNMP discussion to include more detail and background of how it 
    meets the requirements.
    A new version (-06) will be posted which include the SNMP changes, and 
    other miscellaneous updates. It will also reflect the WG decision that RSIP 
    is not appropriate.
    Feedback is needed by November 29th so that a revised version can be 
    It was asked if the document should recommend a protocol, but the 
    protocol selection process (see below) will "choose" one.
    It was also asked if there could be a weighting of the 
    requirements, but it was felt that that would be too subjective.
    Midcom protocol selection/process
    The proposed process for selecting a protocol would be to eliminate any 
    unsuitable candidates (as we have done with RSIP), and then to choose from 
    the remaining candidates. Would like to eliminate at least one more.
    Other considerations:
      - would we expect to see the candidate protocol already present in the 
    device (middlebox and/or agent).
      - what is the level of standardization of the candidate protocol
      - other intangibles
    It was suggested that the directionality problems and awkwardness of 
    session establishment procedures in COPS make it unsuitable.
    The chair pointed out that we need to make progress. People need to read the 
    documents and participate.
    Not choosing any protocol is also an option (better none than one that is 
    never used).
    Some people felt we should have the option of developing a protocol.  To do 
    that, we must demonstrate that all the candidates are unsuitable.
    It was pointed out that of all the candidates, the one which is most 
    likely to be there already is SNMP, and that we should just propose that 
    SNMP be the selected protocol.
    Others pointed out that SNMPv3 not widely used and it is a big leap from 
    SNMPv2 to v3. It was also pointed out that SNMP is not used very much for 
    There were a number of suggestions for things that could be done in the 
    eval document for providing more information to make a decision from.  This 
    included describing how each protocol would be used in a midcom 
    environment. However, it was pointed out that there has been fair 
    opportunity to do that and that it would only delay the process.
    The COPS supporters felt that if you look at protocol reuse, COPS 
    already has the policy rule exchange needed for midcom.
    It was suggested that the bar was set too high in not allowing us to 
    consider writing a new protocol. This too though might have the same 
    problem in selecting from a set of existing proprietary protocols.
    The commenter listed a number of devices which already support SNMPv3.
    Discussion to be continued on the mailing list.


    MIDCOM Protocol Semantics