Current Meeting Report
Slides


2.8.7 Middlebox Communication (midcom)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/24/2002

Chair(s):
Melinda Shore <mshore@cisco.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
A. Mankin <mankin@isi.edu>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
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
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
Internet-Drafts:
  • - draft-ietf-midcom-framework-07.txt
  • - draft-ietf-midcom-requirements-05.txt
  • - draft-ietf-midcom-stun-01.txt
  • - draft-ietf-midcom-protocol-eval-02.txt
    • No Request For Comments

    Current Meeting Report

     Minutes of midcom working group at 54th IETF Meeting,
    Yokohama, Japan

    Chaired by Melinda Shore (mshore@cisco.com
    Reported by Spencer Dawkins (sdawkins@cynetanetworks.com), edited by Melinda Shore

    Status update:

    * Framework and requirements documents are still in RFC editor's queue
    * STUN is in last call - please look at it, so we don't have another showstopper.
    * SPAN design team is stalled with a serious security issue, and the design team may be shut down. We are late with SPAN and very late with STUN.
    * Two semantics documents need to be reduced to one.

    MIDCOM Protocol Evaluation: Issues and Plans (Mary Barnes)

    Five protocols have been evaluated (SNMP, RSIP, MEGACO, DIAMETER, COPS) since last meeting. Evaluation document has been cycled three times since last meeting. COPS-PR (as opposed to COPS) is required to meet two requirements. There is a glaring mismatch between MIDCOM framework and COPS model. MEGACO has a similar problem with implied directionality. With SNMP, SNMPv3 is required to meet security requirements.

    There are still opportunities to improve the document (read: "glaring errors") - review it on the plane on the way home, OK?

    We're about two weeks late, on the current forecast (to IESG in September).

    MIDCOM Semantics (Tom Taylor)

    We currently have two semantics drafts as candidates for working group document. The two documents differ primarily because one makes simplifying assumptions.

    Takeover -- is having one agent operate on rules established by another agent really required? What granularity is required? Should there be a formal handoff procedure?

    Melinda pointed out that there is no requirement for a handoff procedure in the requirements document.

    The group agreed that there is a need to allow one agent to operate on rules established by another agent. Granularity could be per user (identity) as well as per rule or per session. We need a handle in order to do handoff. We had quasi-consensus a year ago on takeover a year ago, based on the idea that ACLs would be used as required.

    Is a deterministic outcome required? Perhaps only in the eyes of the administrator (agents can't know this).

    Rules survive to the end of their lifetime.

    Is there a requirement to move rules from one group to another? Christian pointed out that when you create a rule, you place an arbitrary identifier on it, and the group is the collection of rules with the same identifier.

    Is a group timeout required? There was agreement that it is not.

    Would you ever map an odd port to an even one, or vice versa? The decision was that there is no need.

    Is DENY actually needed? There was consensus with some dissent that DENY is not needed. A DENY would be needed if midcom were to be used to support device configuration or if it were to be used for intrusion detection/response. It was strongly felt that it would unnecessarily complicate rule processing and that it isn't needed for normal midcom operation, and so the decision was not to include a DENY rule.

    Is AND required for multiple filters? The group agreed that we don't need multiple filter conditions.

    What query capabilities are required? Audit for takeover? Wildcarded query filters? Scope issues? Martin said if you have a point-to-point protocol, you can get the status of your rule, but this doesn't work if we have handoff. Cedric replied that this is already handled in the proposal. Martin asked but if we have hundreds of rules, is that what we want returned? Tom asked that if we want this, we need to specify it in the concrete protocol we select.

    Wildcards and Ranges -- is there any need to support address ranges, port ranges, open-ended pinholes? Jim's RSIP experience says 'yes' to all three questions. Elliot Lear asked whether the document specify wildcards? Melinda thinks this is implicit in the requirements. Elliot said we get into trouble with wildcards and DENYs -- if we have one, we shouldn't have the other.

    Grace Period and Pre-Notification. This matches DIAMETER's capability. Jim said that RSIP has problems without this. The issue is with agent restarts and recovery, when rules time out during recovery.

    Atomicity -- are multiple rules applied as a transaction required, to avoid deadlock, etc.? Is there a need to enforce bi-directional mappings? Melinda said that we decided this is a sequence.

    What about applications like VoIP where we need to be stateful? Tom said this is an application issue, not a middlebox issue, as he recalls the framework document. Jonathan asked what to do if the sender is also NATted and you can't hear them suddenly. Jim said that they've seen this issue in tneir operational experience with RSIP as well. If your rules are too selective, you're swamped trying to keep up with rule changes. One of their customers has an application where there are several servers outside the middlebox, and they're bouncing the call from inside the middlebox around. They really need an 'accept from anybody' to have a prayer of keeping up. said that these need to be separate sessions that need to be grouped together -- that simplifies things.

    Reconvening after the break, Jiri asked if we really insist on reusing an IETF protocol? Melinda replied that we have a clear mandate from IESG to do so, unless we can prove that no existing protocol works. If you feel strongly, please talk to the ADs.

    STUN Update (Jonathan Rosenberg)

    There's a -01 revision that went in just before the cut-off, reflecting comments from WG last call on security. We're not using CMS any more. We need integrity of requests to deal with security problems, and CMS won't help with that. It also won't work with Secur-ID and Kerberos. The new solution is to use server-side authentication in TLS, plus a one-time password, used for HMAC SHA-1 protection of STUN requests.

    This still doesn't solve the security problem described during working group last call which allows an attacker to launch a denial-of-service attach and spoof the source address, which isn't covered by HMAC because of NATs. There is no way in the known universe to resolve this in a NAT world, and it affects any NAT-friendly protocol that'ssupposed to be secure.

    We're hoping that the scope of this problem is limited. The attacker has to be on the path from server to the target. Basically you can DoS on the same LAN, and hijack a 100-megabit stream that the target should be receiving. There's another attack, to receive all packets, that also works.

    Christian said the only way to solve this problem is by using end-to-end encryption. Jonathan answered that there are heuristics to detect this attack, but not reliably.

    Eric Rescorla said that we're already vulnerable to people on the same LAN anyway. Christian replied if you are actually receiving the packets, you can just drop them. If you're just a listener, the target still gets them. Eric said that cryptographic signing doesn't protect the important piece of information and asked about removing the HMAC and use a random challenge? Jonathan answered that if you remove the HMAC it's even easier to carry out the attack with a greater scope of exposure. The HMAC-capable attack is a hard timing problem. Christian proposed no security, because security wasn't helping anyway.

    Security considerations section is much thicker now -- support for TLS is mandated, but Kerberos or SecurID can be used instead. The only open issue is whether this security mechanism is worthwhile.

    Jiri asked about symmetric NATs. Jonathan said that he ran STUN through the NAT at my house. Christian said symmetric NATs are a relatively small subset of the market. Cullen said that he's seen about 30 versions of NATs, including S/W release numbers.

    Melinda said that we have one week left in last call and asked for comments ASAP.

    SPAN Update (Melinda Shore)

    SPAN works across symmetric NATs and complements STUN. It provides an external Relay with TCP listeners and support for UDP. The focus is on simplicity. The design team missed May 02 milestone and is failing to make progress.

    We also have a security problem with accepting incoming connection requests that may violate firewall policy. We are enabling listeners behind a firewall -- not just allowing hosts inside the firewall to make outgoing connections, but also allowing them to provide services to people outside the firewall. Jonathan said that STUN is more restrictive than TURN. Christian answered that STUN allows you to receive UDP packets from people you've sent packets to -- and this is still OK. SPAN enables a random sender outside the firewall.

    Cullen asked if people see the need to allow TCP relays? The answer was yes. He then asked how critical it is to keep from increasing bandwidth utilization. Jonathan asked if we aren't looking at tunnelling UDP over TCP, are we? Dave Oran said as long as the client knows this is happening, the client can adjust. And this should be compressible under existing ROHC schemes, if not, this is a problem. We can add keep-alive traffic -- we might want to consider this.

    Steve Bellovin is not thrilled with the concept of allowing TCP connections between firewalls. Firewalls are there for a reason, don't subvert them just because we can do so technically.

    Wrap Up

    Please look at STUN during last call, and the protocol evaluation document before last call.


    Slides

    MIDCOM Semantics
    MIDCOM Protocol Evaluation
    SPAN Simple Protocol for Augmenting NATs
    STUN Update