BEHAVE Working Group minutes IETF 69, Chicago Friday, July 27, 2007, 9:00-11:30 minutes: Dan Wing and Philip Mathews chair: Dan Wing, dwing@cisco.com ===-= Agenda: 09:00 Agenda, milestones, and document status (Chair, 10) WGLC: draft-ietf-behave-p2p-state-03 WGLC: draft-ietf-behave-nat-icmp-04 WGLC: draft-ietf-behave-rfc3489bis-08 (-08 was submitted Friday morning) Nearing WGLC: draft-ietf-behave-multicast-08 09:10 RFC3489bis (Jonathan Rosenberg, 30) draft-ietf-behave-rfc3489bis-08 (-07 was submitted prior to the deadline; -08 was submitted Friday morning) Status: ready for WGLC 09:40 TURN (Rohan Mahy, 15) draft-ietf-behave-turn-04 09:55 NAT Behavior Discovery (Bruce Lowekamp, 15) draft-ietf-behave-nat-behavior-discovery-01 10:10 Multicast (Dan Wing, 10) draft-ietf-behave-multicast-08 10:20 Security Capabilities in CPE for IPv6 (James Woodyatt, 20) draft-ietf-v6ops-cpe-simple-security-00 Application Listener Discovery (ALD) for IPv6 draft-woodyatt-ald-01 ===-= Agenda, milestones, and document status -- chair (Dan Wing) Dan announced addition of James Woodyatt's presentation on v6 CPE security, and ALD. Since Prague, the WG consensus on the list was to remove our Application milestone. This has been done. BEHAVE TCP document is in RFC editor's queue. We will working group last call the following documents in the next week: rfc3489bis-08 (2nd time) p2p-state-3 (2nd time), and nat-icmp-04 (1st time) Dan explained that TURN was holding up publication of ICE, as ICE has a normative reference to TURN. Requesting technical comments from the working group by September 1. On September 2, a team will start integration of those comments, publish -05, and WGLC turn-05. Jonathan requested implementors provide input on TURN. This caused several reviewers to volunteer: Francois Audet, Remi Denis-Courmont, Alan Hawrlylshen, and Robert Sparks volunteered a coworker (Brian Hibbard). These are in addition to Alfred E. Heggestad and Marc Petit-Huguenin who are already technical reviewers of TURN. ===-========================================================= RFC3489bis, Jonathan Rosenberg draft-ietf-behave-rfc3489bis-08 Jonathan Presented slides, which summarized changes in -07. Jonathan had published -08 the morning of his presentation. Major changes in -07: * re-definition of a "STUN Usage". * smaller document - security considerations mostly moved to each usage - IAB considerations moved to each usage * removed shared secret request/response * simplified authentication sections into 'short term' and 'long term' * removed error codes related to implementation bugs * IANA registry created. Includes vendor first-come-first-serve * Length limits on freeform fields * "Mechanism" added: optional protocol procedures - fingerprint - backwards-compatibility RFC3489 mode - DNS - Alternate Server - Authentication Jonathan asked for show of hands of who had read -07; few raised their hands. microphone (Bruce Lowecamp?): One concern with keepalive -- it has been pulled from this document, and moved into sip-outbound. Concern is that people wanting to do keepalive will cite sip-outbound, rather than rfc3489bis. Jonathan said whatever document does keepalive would need to discuss it, similar to draft-ietf-avt-app-rtp-keepalive-00.txt Changes in -08: * Minimum RTO is now 100ms * TCP timeout starts at send of TCP SYN Jonathan declares document is ready for WGLC. ===-========================================================= TURN, Rohan Mahy draft-ietf-behave-turn-04 One normative change: SetActiveDestination, as discussed in Prague. Non-technical changes: "STUN Relay" -> "TURN", and make TURN consistent with rfc3489bis's new definition of "usage", and updated IAB considerations. One issue missing from the document: TCP-to-TCP flow control, when the TURN server is functioning as a TCP-to-TCP relay. This is complicated by TURN's ability to have multiple TCP peer connections. Lars: What scenario are you worried about? Rohan/Jonathan: That a TURN client will send data to the TURN server, but TURN server cannot relay the data to the TURN peer because the TURN peer can't accept data that fast. TURN server needs to buffer, and needs to supply backpressure to the TURN client. Needs to be documented. Lars: Yes, all TCP proxies have that issue. But we don't have a TCP proxy guidelines document. Remi: Do we have a use case for multiple TCP connections to the TURN server? Rohan: Theoretically can happen if you are forking (MSRP). Not common, but technically possible. Philip: why not multiple TCP connections, one to each peer. Rohan: because you can do only one m-line in your offer. TURN doesn't know you're doing SIP. There is one use-case, which is forking. Philip: My model for a TURN server is a BEHAVE-compliant NAT, and there are no BEHAVE-compliant NATs that have this behavior. This suggests there is a different solution to this problem, where the connection can be brought all the way back to the originating host, thus two distinct TCP connections. Should take this offline and talk about it. Remi: If we allow multiple connections to be brought back to the client, we are allowing servers, which we didn't want to allow with TURN. If you want two connections, just open two connections. Rohan: Would guidance in the document, encouraging avoidance of multiple connections, be useful? Jonathan: Can't avoid it. Rohan: Agreed, but application should try to migrate from muliple connections to single connections as soon as possible. Jonathan: Need to discuss how it works, anyway, when it happens. Gorry Fairhurst: Text from RFC3135 might be useful Rohan: Please provide technical comments on TURN by September 1. Going to add appendix describing design choices. ===-========================================================= NAT Behavior Discovery, Bruce Lowekamp draft-ietf-behave-nat-behavior-discovery-01 slides: * clarified STUN server needs two IP addresses. * removed RFC3489 backward compatability, because a RFC3489 client is most likely doing something wrong. * padding is mandatory * added additional example test to detect generic ALGs * feedback on list: - add additional reasons why hairpinning won't work - can document describe how to run tests in parallel. Document will be revised slightly, but it's not the document's job to describe how to do this quickly. - how can Linux NATs be detected. This is a slippery slope; timing issues can cause false readings. Document won't describe how to detect specific kinds of NATs. * Current draft is proposed standard. Bruce suggests this should be demoted to Experimental. It's important to have a document that explains what was broken about RFC3489, and why it was broken. Still some value in diagnosing how NATs work. comments on Experimental: Remi: The only protocol I'm aware of that does this is Teredo, which has its own mechanism, so it's not affected by this proposed change. Philip: is anyone using behavior-discovery? Bruce: if anyone needs this functionality, they're doing RFC3489. Bruce knows of 3 people using this, and what they're doing is trying to determine if they need a relay server. In some cases, where they know who they will be communicating to, this works fine. In other cases, they aren't using it appropriately. I want to strenghen the applicability statement to make this clearer. Philip: The one interesting use, which could be hurt by making this Experimental, is to diagnose problems in running ICE. p2p-sip might be hurt by this lack of diagnostics. Bruce: p2p is one possible application that could benefit from behavior-discovery -- with enough tests, you could perhaps determine if you could be a superpeer. However, such a determination would be experimental at this point. Philip: How quickly do we need to decide if this should be experimental. Jonathan: I think the change to Experimental is appropriate, and anything using this is unreliable. It's the difference between working 95% and 99.99% of the time. Magnus: There are grounds for defining this as an experiment and deciding how well this works before moving forward. "Do we have an experiment". It seems we do have one. Bruce: Today this is useful for diagnostics and instrumentation. We do not have a clear view on how this can be useful for changing application behavior. Francois Audet: This should be Informational, not Experimental. People have used techniques like this for a long time, even before STUN, to detect bad NATs. The fear is people will look at behavior-discovery and say "this is easier than ICE, let's use it", but making it Experimental won't necessarily accomplish that goal. It certainly doesn't belong in standards-track. Dan asked for hum on standards-track: a quiet, yet strong consensus to demote away from standards-track. Bruce: we'll adjust the applicability statement and bring that to the list. (continuing with slides) Adjusted 'usage' to be aligned with rfc3489bis. 'cache-timeout' is a request the client can ask of server. Originally this required a shared secret from the STUN server (this has been removed from rfc3489bis). Philip: seems odd to need authentication for diagnostic. Bruce: There is no amplification attack Henry: Most real deployments have two levels of NATs -- NAT in the home, and NAT in the ISPs. If you want to do this checking for STUN, will it work for a single layer of NAT or do you need to rely on the ISP running a STUN testing server? The tools on the market that have been published (such as on the Microsoft site) determine the nature of the NAT by talking to several servers -- typically 3. From reading the paper, I haven't seen these issues described. Bruce: These techniques can diagnose the behavior of the NATs you are behind relative to the servers you are behind. You'll get the correct answer if you are behind the right NAT and the right server. This document is more focused on the bahavior of your NAT relative to your STUN server. Henry: We have a number of RFCs and papers on NAT classifications. You need more than one IP address on the STUN server side, and more than one IP address on the inside of the network. This is also not addressed in the paper. Bruce: Behavior-discovery requires a STUN server with multiple IP addresses; it doesn't require a client with multiple IP addresses. Bruce: (continuing slides) We're going to change backwards compatability with RFC3489 and RFC3489bis, now that RFC3489bis has changed its method of being backwards compatible. ===-========================================================= Multicast, Dan Wing draft-ietf-behave-multicast-08 Has received a lot of review from outside of BEHAVE, mostly from MAGMA and MBONED. Added Toerless Eckert as co-author. Large reorganization around how you source multicast and receive multicast. One complexity was supporting multicast sources on the inside of the NAT. We haven't reached a good conclusion on what should happen with multiple SSM sources behind the same NAT which all happen to choose the same multicast group address. Once their traffic traverses the NAT, their traffic gets NATted to the same IP address and their traffic is no longer distinguishable. New text provides suggestions to applications to allow users to choose multicast group addresses. Jonathan: You'd have to extend IGMP to accept ports to do this. Dan: Or change multicast to use source port and IP address, rather than just source IP addresses. Unachievable. (continuing slides:) stronger SSM receiver requirements, to help IPTV applications. Now a SHOULD for NATs to receive non-UDP protocols. SHOULD use endpoint-independent mapping for multicast. Philip: for UDP and TCP we're using MUST. Dan: will review to make sure it's a MUST. Philip: There isn't much multicast knowledge in BEHAVE. Has this been well reviewed? Dan: I share that concern, and the last WGLC of multicast received zero comments. After that finished, I forwarded the I-D to MAGMA and MBONED. From those comments and talking with those contributors, substantial changes were made and a co-author was added. My intent is to continue involving the multicast community. Philip: My concern is the overlap of NAT and multicast expertise, with overlap knowledge of both. Dan: IESG can help us with that review, as well. Gorry: Are we worried about the case where we have more than one NAT, in parallel with a multi-homing, when sourcing multicast traffic. Dan: We have existing text for a single NAT that has multiple public interfaces. But the document does not consider what occurs if a multicast source is behind two NATs, each connected to the Internet. Magnus: This document is getting closer with better multicast review and NAT review. As an AD, I am much less worried than previously. Remi: I'm worried about SSM. Some crash with IGMPv3. With ASM it can be easier because you can use admin-scoped addresses. Perhaps have the NAT wait for IGMP from the WAN interface before sending anything upstream? James Woodyatt: Define a realm-specific multicast scope. Dan: There is a document for ASM that does exactly that, but the SSM address range doesn't overlap the ASM address range. I will pursue if we can have the NAT wait to receive an IGMP from the Internet before starting to send traffic towards the Internet. ===-========================================================= Security Capabilities in CPE for IPv6, James Woodyatt draft-ietf-v6ops-cpe-simple-security-00 Application Listener Discovery (ALD) for IPv6 draft-woodyatt-ald-01 (presenting slides) Concerned with e2e transparancy on the Internet, particularly with v6. In v6, your node may be addressable but may not be reachable. ALD tries to provide reachability through firewalls. Firewalls like to restrict access based on policy -- only 'invited' traffic is allowed, other traffic is denied. Firewall doesn't know you have bound to a socket and expect to receive packets. Existing techniques in v4: policy applied when flow starts across boundary; ALGs; manual port redirection; UPnP IGD, NAT-PMP. Same techniques exist or are needed for v6. Firewalls need to learn about transient internal listeners, listeners need to learn about firewalls that need notification, and nodes need to learn how to discover firewalls. ALD: extension to ICMP, new router advertisement option, existing sockets API sufficient for most applications, some new options for advanced requirements. An unmanaged network (no firewall) might be behind a network that is managed (with a firewall). router advertisement tells you there are firewalls and you need to tell them about ports you want open. nodes can also wait for multicasted advertisements. listener notification: node tells firewall that it's listening on a socket. James suggests this should be tied into the sockets API. There's no way to say 'only allow connections from a certain remote address' isn't communicated in ALD. This is on purpose. (question from audience: what is the IP address it's supposed to listen to? It isn't in the packet) James: the IP address of the ICMP packet itself indicates the IP address. Listener acknowledgement: firewall sends this. Elapsed time since reset tells host if firewall has rebooted. This value is also used in the multicasted advertisement packets. ICMPv6 source address implies listener address. ALD does not specify firewall policy. Firewall might honor a host's request. Adding IPsec for the communication to the firewall might be useful, but it isn't in the draft right now. Q&A slide (last slide): * Unmanaged networks behind firewalls. * Application programming interfaces. * Considerations for DHCP6. * Policy decision at firewalls. * Policy decision at multiuser listening nodes. Philip Mathews: at beginning of talk, you said you built a product that had a 6-to-4 gateway with no restrictions, and later added restrictions. I'm curious why you turned this off. James: There is a school of thought that says such filtering in the network is wrong. Unfortunately, those folks haven't been able to mount an argument against the people that say "you have to have a firewall in your product". So, management said 'turn it on'. Philip: wouldn't it be useful for IETF to discuss how to solve that problem, and where to do that filtering? James: if it resulted in an RFC, with backing by the IAB, a document that said 'network firewalls are bad' could be useful. Rather, IETF is recommending filters (he cites a v6ops document authored by Brian Carpenter). Philip: what is the incremental deployability of ALD? What is incentive to build into an application and its firewall. Workaround is to go back to what we are doing with STUN and ICE. James: I would incrementally deploy this by deploying routers and devices behind the routers that both deployed ALD. I would also try to get ALD support into *BSD variants so OS vendors would have referencable source code to add to their OSs. When routers routinely support ALD, applications that can benefit from it will start using the OS services. When we have nested firewalls, ISPs can eventually turn on ALD in their firewalls as well. Philip: Incremental deployability has been the problem in the past for doing this. James: I have thought about how to do it; I'm not sure this is the best way. Magnus Westerlund: I agree this is a problem that needs to be solved. We will never get rid of firewalls. As I look at this, it isn't that different from MIDCOM. You have some additional discovery features. James: it might be lighter weight for embedded and low-cost devices than MIDCOM Magnus: True, there are definately arguments. What we need to figure out is why haven't the things we have done working, and how we should move forward. JameS: My intent is to submit this as an individual submission as a proposed standard, and shepherd it through the IETF that way. I am not looking for a working group to be a home for this, but for support from the IETF at large. Magnus: Finding a shepherd will be hard, because it will be considered an end-run around the IETF effort. James: Yes, that is possible. Remi: I suggest IPsec might be desirable for 3G or WiMax networks, where you want to control a firewall on the other side of your access link. We may want to extend BEHAVE's charter for transport protocols to include v6. James: Relay servers, aren't that useful for v6. TCP simultaneous option and specifying the behavior of stateful firewalls would be useful for v6. You'll note that v6ops has a document (which James is editor of) that specifies CPE security. Remi: There could be a way to specify firewall behavior so that it doesn't break TCP simultaneous-open could be written. Jonathan Rosenberg: I applaud this work. It is possible this isn't too late to fix this for v6 (it is too late for v4). Making firewalls part of the system seems useful. James: ALD does that. Jonathan Rosenberg: I have some concerns with this specific proposal: multipath, selecting the right firewall, nested firewalls, incremental deployability. As Magnus said, ALD is largely like other protocols (UPnP, MIDCOM), yet only UPnP has had much success and its scope is limited in applicablity. James: I am very interested in solving problems like incremental deployability, multipath, etc. Jonathan: There is no easy answer, which is why it isn't solved on v4. The authorization part is very important. Can't push unsolvable problem away. Randall Stewart: I saw DCCP and SCTP on one of your slides. Do you support those protocols in your products? James: No, only mentioned for completeness. Randall: I encourage you to find a working group for ALD, so you get more feedback and the protocol gets improved. I believe IESG favors products of working groups rather than individual. In my experience with SCTP, it's faster to do a working group and more robust (better protocol). Drawback is that you lose change control and may have to revise your product. James: Apple's experience with Bonjour and NAT-PMP in the IETF stanards process was not favorable. (comments off-mic) Lars Eggert: If you were to bring an individual contribution to the IESG, the sponsoring AD needs to ensure it has received equivilent review to going through a working group. Individual contributions as Proposed Standard aren't faster than going through a working group. James: I'm editor of the v6ops draft, and it says that some sort of dynamic interior 'hole punching' is needed. But it doesn't reference anything, it just lists requirements. Lars: You want multiple vendors to implement the standard. Getting community consensus will make everyone agree it's the best technical solution. James: I wear two hats: one is editor of v6ops, the other is employee and need to get ALD working. As an IETF participant, ALD is an alternative to UPnP PMP which hasn't been released for v6, and IETF's other work (MIDCOM, NSIS) which I don't know if they will be deployed. As editor of v6ops's simple CPE security draft, I don't like the dangling reference. If v6ops thinks ALD is good enough to reference, I don't know how to get ALD can be brought into position to make it referencable. This is first I have heard that a WG would be faster. Jean-Francois Mule: Soon, cablemodems will have knowledge of ICMPv6 and will have filtering capabilities. There is a need to be aware of such a filtering box. There are a lot of design considerations that are not in ALD. There design considerations can be abstracted into requirements which may be beneficial to v6ops, BEHAVE, and MMUSIC, which can explain why MIDCOM hasn't been deployed and that ALD is only indicating the local transport addresses, is using ICMP, is using router discovery messages, etc. What I am after is not throwing more stones to delay your work, but rather to capture the good considerations you have when you designed ALD. This could get you some acceptance in v6ops and among folks doing IPv6 middleboxes. Ultimately you want those v6 messages to not get filtered by DSLAM, CMTS, cablemode, DSL modem. James: I take that as a suggestion to create another document around 'applicability statement'. Jean-Francois Mule: Yes; I am interested and willing to help. Magnus: IETF has some baggage in this area around middlebox control. We cannot totally ignore what we have done. We need to know how this is better, and need to have this discussion. This discussion would involve 3 areas. James: It sounds like such a separate draft is necessary. Magnus: We have work ongoing, and need this discussion in a public, open way. We can't forget chartered work, so your work can go forward on standards-track in the IETF. Philip: Are you aware of SAFE that Dan is putting together, which in some sense is a rival proposal to this? Dan Wing: SAFE: UNSAF is what STUN does, so SAFE is something better. There was a Sunday Bar BoF. SAFE has been discussed a bit on the BEHAVE mailing list. SAFE learns of on-path NATs and on-path firewalls. There does seem to be an overlap. Let's talk about this after the meeting. Philip: One of the interesting things is SAFE is trying to provide incremental deployability. Comparing ALD to SAFE might be interesting (amongst other proposals). James: I will have that in mind when I write the next draft. Philip: The interesting thing about SAFE is its built-in fallback mechanism if the NATs or firewalls involved do not support it. As you add it in, it just improves behavior. James: I had a similar goal with ALD, too. Magnus: I would place the STUN Control (SAFE) into a separate thing than ALD. STUN Control is for a broken IPv4 world. In v6, we could fix this in a structured way. Yes, we need a protocol to open and control listening ports in firewalls. The big problem is how to achieve consensus among manufacturers to implement it. Lars: It's great that you're bringing this to IETF. The proposal has a lot of interesting technical features, and adds value to NSIS, MIDCOM, and new mechanisms being proposed now. However, the document will benefit from continued IETF review; for example, you are creating a reliable retransmission mechanism on top of ICMP and the Internet area may care about this a little bit. Getting James: There is a mention of incremental backoff. There is no congestion control, though. Lars: It keeps sending, and ICMP has no such reliability. Remi: IPv6 firewalling guidelines document (which might be RFC'd) might specify filtering the ICMP message you're using. Some of the incremental deployability questions expressed seem excessive. I'm not as worried about incremental deployability. James: Please send further comments publicly or privately. *end*