2.7.5 Middlebox Communication (midcom)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-02

Melinda Shore <mshore@cisco.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: midcom@ietf.org
To Subscribe: midcom-request@ietf.org
In Body: subscribe your_email_address
Archive: www.ietf.org/mail-archive/working-groups/midcom/current/maillist.html
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
Done  Submission of STUN document for standards-track publication
Done  Submission of pre-midcom document describing protocol for NAT traversal using relay for standards-track publication
Done  Submission of document evaluating existing IETF protocols against midcom framework and requirements for an Informational RFC.
Done  An analysis of the existing mibs and initial list of mibs (or portions of mibs) that need to be developed submitted to WG
Aug 03  Semantics document submitted to IESG for publication as informational RFC
Nov 03  Initial mibs ID submitted
Feb 04  Mib documents submitted to IESG
  • - draft-ietf-midcom-protocol-eval-06.txt
  • - draft-ietf-midcom-semantics-07.txt
  • - draft-ietf-midcom-mib-analysis-01.txt
  • Request For Comments:
    RFC3304 I Middlebox Communications (MIDCOM) Protocol Requirements
    RFC3303 I Middlebox Communication Architecture and framework
    RFC3489 PS STUN - Simple Traversal of UDP Through Network Address Translators

    Current Meeting Report

    Minutes of the midcom session at IETF59
    Seoul, Korea, Tuesday, March 2nd, 2004, 14:15 h - 15:15
    Agenda bashing/note-taker/blue sheets
    - Administrivia:
      - Agenda accepted as proposed. Rohan Mahy / Brian Stucker taking notes.
      - Mary Barnes acting chair in absence of Melinda Shore.
    AGENDA ITEM: Status update - Mary Barnes (Chair)
       - MIDCOM protocol evaluation: updated references, now blocking on 
    publication of NAT MIB.
       - MIDCOM semantics: IESG review.
    AGENDA ITEM: STUN futures - Jonathan Rosenberg
       - Jonathan Rosenberg: Cullen did an analysis of NATs and found that
                     STUN may not apply correctly to the reality of what NATs 
    are actually out there doing.
       - Time to revise STUN?
           - NAT detection algorithm is brittle
                - The NAT detection algorithm doesn't fully describe 
    implemented NATs. We've now found lots of non-standard behavior, much of it 
    documented in 
                - Remove from STUN
                - Produce diagnostics document on ideas for using STUN.
           - Introduce XOR-based protection of mapped address
           - Discussion:    
                - Jonathan Rosenberg: Trying to do a generic ALG, which is a bad 
    idea. In order to protect us from ALGs, garble the IP addresses 
    embedded in the message such that they will be ignored by the ALG 
    (hopefully they won't try to figure out what we're doing and get around 
                - Rohan Mahy: Had we made the change at the beginning, I could 
    have gone either way, as it is we have a backwards compatability 
                - Jonathan Rosenberg: Would need to add a new tag 
    (NEW_CHANGED_ADDRESS) to deal with this problem (basically ignore the old 
    addresses, and not the new one), if both are present, look at old 
    addresses. Not many NATs with this problem and they are tending to go 
                - Rohan Mahy: Let sleeping dogs lie, and try to get rid of the 
    small number of broken NATs. Not opposed to this work.
                - Jonathan Rosenberg: Worried about future revisions of 
    hardware starting to behave badly. Client sends a STUN request, and the 
    response includes both a new XORed address and the old one so it's 
    backwards compatible (icky that the data is duplicated but oh well).
                - Francois Audet: There's parts of this that are extremely 
    useful, so I don't think we want to remove everything from the 
    diagnostic side of things. 
                - Jonathan Rosenberg: This is more of an ICE discussion, where 
    the only way that you know you're not on a NAT is to test.
                - Francois Audet: I still think we need to revise the 
    diagnostic to know that they're accurate, and not ditch it entirely.
                - Jonathan Rosenberg: They'll always not be current because 
    NATs will change their behavior in the future and we'll always be 
                - Francois Audet: I don't buy that, the type of really nasty 
    things we're seeing is getting rarer.
                - Jonathan Rosenberg: The technique for figuring out that a 
    STUN allocated address is correct is brittle/random because of 
    misclassified NATs in which case you think you don't need a relay when you 
                - Francois Audet: You may discover that there's no NAT at all. 
    That information is useful, so let's not ditch it.
                - Jonathan Rosenberg: That's handy, but you may still be wrong in 
    the STUN assessment.
                - Francois Audet: It allows you to figure out in an 
    enterprise environment that there's no NAT, so we can eliminate extra 
                - Jonathan Rosenberg: If they're behind a symmetric NAT, with 
    ICE, you still won't need a relay.
                - Francois Audet: The entity that knows the two 
    endpoints, may be able to figure out from access to the diagnostic 
    information may allow you to know both ends are not behind a NAT. We 
    should qualify what it tells us.
                - Jonathan Rosenberg: I don't want to continue solutions that 
    require me to keep having to revise this STUN draft all the time. You may 
    think you're not behind a NAT but you are (both sides use the same IP 
    address space).
                - Unknown speaker at microphone: You don't separate them, you 
    keep it up to date as much as you can.
                - Jonathan Rosenberg: Still need STUN because you MAY get an 
    address you can use, where ICE will prove you have an address you can use. 
    Most implementations of STUN is to do the diagnostics, and then 
    allocate the address. Splitting the document apart makes it clear that this 
    is not what STUN is about.
                - Rohan Mahy: Several of the sort of broken cases have to do 
    with multiple devices behind the same NAT. You can really detect those 
    without having two IP address on the same device. That said, I would be 
    happy to have that documented somewhere even if it used a single IP 
                - Jonathan Rosenberg: Scope needs to be very clearly defined as 
    to what it doesn't do and what it does.
                - Mary Barnes (Chair): So what you're proposing is to split the 
    two into a diagnostics and allocation draft.
                - Rohan Mahy: Will take on the diagnostics draft, may 
    delegate to Cullen if he wants to do it.
                - Jon Peterson (Area Director): The charter is getting thin, 
    we're winding down.
             - HUM VOTE ON SPLITTING THE DOCUMENT (not a WG item): 
                - Rohan Mahy: Clairifying question, document is updated to say 
    these sections are non-normative.
                - Jonathan Rosenberg: I can't do anything about the RFC. The new 
    one will replace the old one with a missing chunk of text.
                - Rohan Mahy: You can use updates RFC.
                - Jonathan Rosenberg: Problem is that we don't want to 
    include the diagnostics.
                - Eric Burger: Melinda preferred it's a WG or not.
                - Jon Peterson: Let's ask if anyone objects to this plan or 
                - Francois Audet/Cedric Aoun: First document includes 
    protocol and XOR, other document would be informational around the 
             - NO HUM VOTE TAKEN. Was deemed not necessary, we're past that 
    AGENDA ITEM: What do we do with 
    draft-ietf-midcom-mib-analysis-01.txt? (Mary Barnes)
      - We had two MIBs, now we have one.
      - WG MIB analysis document updated prior to IETF-58 to reflect the 
    current status (2 MIBs) and additional detailed analysis of the 
    applicability of the MIDCOM semantics to the NAT mib:
      - Progress since IETF-58:
        -NATMIB under IESG review
        -FW config split from IPSEC policy config MIB
        -Single MIB document
      - Proposal: do some clean up, and combine the two as one document going 
      - Discussion:
        - Juergen Quittek: I think the there is some relationship with NAT 
        - Mary Barnes (Chair): We didn't get a lot of reusability of the other 
        - Result of brief discussion: No objections.
    AGENDA ITEM: MIB document 
    draft-ietf-midcom-mib-00.txt (Juergen Quittek)
      - What we did was to take the three individual MIBs and integrate them 
    into one big MIB.
      - The general approach was to start from the MIDCOM semantics.
        - Tried to map the semantics to a MIB module.
        - Added:
           - Means for firewall configuration
           - Resource usage information
           - Statistics
        - Structured into tables
           - The major means provided by SMI (Structure of Management 
        - MIB Module Overview:
           - Session Tbale, Rule table, group table, capabilities table (IP 
    interface configuration) filed uder implementing MIDCOM semantics.
       - Summary of the basics:
         - A MIDCOM entry needs to insert it's own entry in the session table 
    before opening a session. Without this entry, MIDCOM agent cannot act on 
    policy rules.
         - Rule table has one entry for each policy rule. Indexed by session 
    owner, groupindex, rule index. Objects in entry cover all parameters of PER 
    and PRR transactions. Explains that if a NAT is involved, what the 
    interface is. Added a max idle time to describe how long the NAT session 
    will be left idle before closing. Added rule storage time to allow rules to 
    expire out of the table (they're left in there, but inactive after expiry 
    for a period of time).
         - Group table: one entry per policy rule group, just a shortcut for the 
    rule table.
         - Notifications: Informing the MIDCOM agnet about state changes at the 
    middlebox. Session termination, policy rule event (lifetime change, 
         - Interface Config table: provides middlebox capability 
    information per IP interface (IP version, wildcarding support, 
    firewall, NAT).
         - Firewall config table: config of the enforcement of policy rules 
    into firewalls.
            - Group ID and priority of FW rules derived from MIDCOM policy 
            - Should be read-only for MIDCOM agents.
            - Would be writable for middlebox admin.
         - Resource Table: links MIDCOM policy rules in the rules table to 
    resources in the NAT MIB.
         - MIDCOM statistics: session statistics: rejected, current, total 
    sessions. Policy rule stats, etc..
       - Open Issues:
          - Security considerations not complete!
          - Firewall config and resource usage indication is  generic 
    (waiting for input form firewall community,  eager to hear back). Don't 
    know if this is  representative of what's out there. Need to have  
    firewall community to speak up, currently generic.
          - Explain use of USM and its relation to  
    midcomSessionOwner and clarify that the MIDCOM agent  
    authenticates, not the SNMP manager. How SNMP  security is exploited will be 
    improved in next version.
          - Is MaxIdleTime an input parameter to PRR? Question  was raised by 
    Suresh, not present, so it's left open.
      - Questions:
         - Rohan Mahy: What was the overall.. what was the reaction from the 
    firewall community, are they interested?
         - Juergen Quittek: yes. Suvesh is from the NAT community. Do you mean 
    the manufacturers or standards?
         - Rohan Mahy: Manufacturers.
         - Cedric Aoun: In which context is this thing targeted for, 
    management or monitoring, perhaps they're not clear on what this is for?
         - Jurgen Quittek: People with NATs want something like this, but 
    perhaps not a MIDCOM MIB. Couldn't tell.
         - Mary Barnes (Chair): Please take a look at this, even if you're not a 
    MIB expert. Look at the data model. If you wanted to implement it could you 
    do what you need to do for MIDCOM.
    AGENDA ITEM: Way forward (Mary Barnes)
      - Completing the MIB will complete the MIDCOM charter at this time. We 
    need people to look at it, might want to wait for next rev before the 
    review due to security considerations. (Dave Harrington volunteers)
      - I will contact folks to read it on the long plane ride back. 
    Probably will be finished up in May.
      - Mary Barnes: Any other business?       
      - Rohan Mahy: I think there are a number of folks that are 
    interested in non-MIB MIDCOM like protocols. I was planning something in 
    after talking with a couple of folks. Procedurally, should I bother or not? 
    Are others interested?
      - Jurgen Quittek: Maybe how many have seen the SIMCO draft (complete 
    implementation of the MIDCOM semantics), so maybe we're interested.
      - Jon Peterson (Area Director): Procedurally speaking, charter and 
    criteria were extraordinarily well documented. Probably does not fit. 
    However, at such time the IESG has reviewed the the MIDCOM MIB, then we can 
    look at alternative approaches. I don't think we should put an 
    alternative approach at this time.
      - Eric Burger: Exactly when is this cut-off be able to happen.
      - Mary Barnes (Chair): Propose that you must contribute to the MIB 
    before you can contribute to an alternative.
      - Jon Peterson (Area Director): Wishes he could authorize that 
    proposal. RFC editor has to have published the MIB before an 
    alternative could become a WG document. Individual contributions could 
    proceed in parallel, but RFC editor isn't going to want to see two things at 
    the same time.
      - Jurgen Quittek: We'll submit something next week (SIMCO).
      - Jon Peterson (Area Director): It's not that I can't stop you, even if I 
    wanted to. Not appropriate to charter non-MIB approaches, however after MIB 
    is approved, may be reasonable to request individual publication of other 
      - Mary Barnes (Chair): Final plea, please look at this document.
      - Jonathan Rosenberg: While on subject of controvertial 
    activities, can someone send references to ITU-T activities for NAT/FW 
      - Eric Burger: As well, ETSI is looking at this for H.248.
      - Roni Even: It may be that they end with BCP document, but may also be 
    that it specifies solutions around H.323, H.245 signalling that SIP 
    doesn't have. New question in SG.16, still very early.


    STUN Futures