Minutes of midcom working group at 55th IETF Meeting, Atlanta, Georgia, USA Chaired by Melinda Shore (mshore@cisco.com) Reported by Bob Penfield (bpenfield@acmepacket.com), 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.