Last Modifield: 05/24/2002
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|
|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|
Minutes of midcom working group at 55th IETF Meeting, Atlanta, Georgia, USA Chaired by Melinda Shore (email@example.com) Reported by Bob Penfield (firstname.lastname@example.org), edited by Melinda Shore ============= Status update ------------- pre-midcom: - 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 discussion. Semantics: - The two semantics documents have been combined into a single document. Milestones: - 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 offline). 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 - draft-ietf-midcom-semantics-00.txt ---------------------------------------- ---------------------- 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 FW/NATs. ======================================== =========================== Midcom protocol evaluation - draft-ietf-midcom-protocol-eval-05.txt ---------------------------------------- --------------------------- 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 submitted. 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 configuration. 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.