Last Modified: 2004-02-02
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 | |
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 |
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 IETF59 --------------------------------------- Seoul, Korea, Tuesday, March 2nd, 2004, 14:15 h - 15:15 AGENDA: 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) draft-ietf-midcom-protocol-eval-06.txt draft-ietf-midcom-semantics-07.txt - 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 draft-jennings-midcom-stun-results. - 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 it). - Rohan Mahy: Had we made the change at the beginning, I could have gone either way, as it is we have a backwards compatability problem. - 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 away. - 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 behind. - 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 do. - 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 steps. - 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 address. - 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 not. - Francois Audet/Cedric Aoun: First document includes protocol and XOR, other document would be informational around the diagnostics. - NO HUM VOTE TAKEN. Was deemed not necessary, we're past that point. 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: - Draft-ietf-midcom-mib-analysis-01.txt - 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 forward. - Discussion: - Juergen Quittek: I think the there is some relationship with NAT MIB... - Mary Barnes (Chair): We didn't get a lot of reusability of the other MIB. - 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 Information) - 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, etc).... - 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 rules. - 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. Discussion: - 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 approaches. - 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 traversal. - 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. --- MEETING CONCLUDES --- |