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.