Last Modified: 2004-06-17
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].
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 | |
Done | Semantics document submitted to IESG for publication as informational RFC | |
Done | Initial mibs ID submitted | |
Jun 04 | Mib documents submitted to IESG |
RFC | Status | Title |
---|---|---|
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 |
Minutes of the midcom session at IETF60
--------------------------------------- San Diego, California, USA, Thursday August 5 2004, 15:30-17:30 midcom minutes 4 August 2004 Eric Burger, scribe AGENDA ITEM: Document Status Protocol evaluation is in RFC Editor's queue. The semantics document has been accepted by the IESG and will shortly enter the RFC Editor's queue. AGENDA ITEM: Midcom MIB - Juergen Quittek The document is draft-ietf-midcom-mib-02 Issue #1: MIB Structure Changes Have a semantics table + add on tables One thought: merge Firewall Configuration table and Capabilities table. Should we remove Session Table? . Session table is a hack to implement session model in SNMP, which has no concept of session. . Two existing MIBs can do what Session Table does (Target MIB and/or Notification MIB) General consensus from floor to remove Session Table Issue #2: How to integrate MIDCOM MIB into Firewall Configuraiton . All MIDCOM rules have same precedence . MIDCOM rules only have "allow" rules, overlapping rules result in opening of all requested ports, which satisfies all clients . Firewall people do not see world this way, but can live with it Q: So if I have rule, "open for source address *" and "open for source address foo", is there any conflict? A: No: both clients' requests satisfied Consistent behavior with IPSP MIB Issue #3: Notification Subscription Lots of hacks to make Session Table work, like BITS object Resolution: Target MIB / Notification MIB just works Issue #4: Idempotency Losing SNMP message means policies can remain active longer than requested lifetime. Currently using remaining lifetime to support failover (surviving controller sees how much time is left). But SNMP stack semantics imposes problems, based on long timeouts for retransmissions. Need to store total lifetime. So, should we store total lifetime at client and server? No preference from room. Also have other Idempoency problems with Session Table, but they would go away if use Notification MIB. Issue #5: MaxIdleTime For default value, should we use native NAT value (presumably provisioned at NAT) or impose one? If we use native NAT value, we will need a way for the midcom client to determine value of timer Tom T: Midcom has adequate provision for limiting lifetime of sessions. Thus MaxIdleTime is a nuisance for implementers and client applications Bob P: Wants to have MaxIdleTime, and have the default be native NAT value. "midcom is a guest of the NAT." Clients will expect NAT to behave like NAT in "default" situations. Suresh: Agrees with Bob Melinda: Applications tend to only set value in special cases Vote: Use box native MaxIdleTime: 4 No MaxIdleTime: 2 Do not care: everyone Will take to the list. Issue #6: MaxIdleTime for PRR Should we have MaxIdleTime for Policy Reserve Rule? Suresh: This is important because PRR allocates bindings Melinda: Why is it important to have parameter in addition to normal lifetime parameter? Suresh: Because it is a property Bob: Can have multiple PRR/PER updates, e.g., do PRR with minimum set, then set MaxLifeTime later Vote: Mandatory to be in PRR: 0 Optional to be in PRR: 3 Not in PRR: 3 Will take to the list. Issue #7: Naming Conflict MIDCOM: "internal/inside" & "external/outside" NAT: "privateSource/privateDestination" & "publicSource/publicDestination" Melinda: NAT MIB will be published first. Its terminology wins. Jon P: Does not really matter what we call objects Other issues: Any use for midcomRuleNatService? No discussion Missing midcomInsideInterface and midcomOutsideInterface. No discussion RuleLifetime & RuleMaxIdletim: What happens if different rules for policy rules use the same resource? Suresh: Several clients send policy requests that map to overlapping resources. Do we take maximum of MaxIdleTimes? If so, the clients will not know what the actual value is. Thus we need some reporting. August is holiday season. Thus next revision will be in September. Because of that, August is a good time to review the documents. Plea from Melinda to review the documents in August! |