BEHAVE Working Group minutes IETF 68, Prague Thursday, March 22, 2007, 13:00-15:00 minutes by Eric Rescorla, ekr@networkresonance.com chair Dan Wing, dwing@cisco.com ----- Since last time met: - published NAT-UDP (RFC 4787) - slipped dates on rfc3489bis, turn, multicast - added p2p-state, behavior-discovery - behave-tcp-05 with IESG - p2p-state WGLCEd - will be revised and resubmitted draft-ford-behave-app-05 ======================== EKR and Phil Matthews: "why do we need this?". Isn't this "how do you design ICE?" This document is unnecessary. JDR: would be good to do a taxonomy of traversal mechanisms (ICE-style, rendezvous, etc.) EKR, JDR, PM: What would be useful is a document about how to adapt ICE to non offer-answer protocols. Francois Audet: Seems like we need a different document. How to use ICE. Dan Wing: Yes. JDR: What we need is something that breaks down protocols into archetypes and shows how to do NAT traversal for each type. With ICE representing the hardest case. FA: Two issues (1) what do we do with this document--a lot of people would be happy if we didn't adopt it (2) need a volunteer for this proposed document. JDR: I have text for this somewere if we had a volunteer. PM: ICE, STUN, etc. are all examples of UNSAF. Do we want to talk about other approaches and why UNSAF is good. JDR had a document like this (IAB doc). Other WGs have this issue and might use guidance. JDR: The other day in P2PSIP, the HIP guys had a NAT traversal document. Couldn't tell what they were saying, but first thing seemed to be detect NAT type per RFC 3489. DW: Nobody is volunteering. PM: Considering it.... draft-ietf-behave-rfc3489bis-05 (JDR) ===================================== JDR didn't do much. -06 is not that different from -05. Lots of comments. Let's do a deadline (2 wks) and otherwise we will add someone to help out JDR. EKR: Why not pick someone now. Rohan Mahy: It's disruptive. JDR: Lots of comments. Do we have a volunteer? PM: I'm considering it. JDR: That's not right now... DW: Let's keep it at 2 wks... JDR: Issue, locked on SHA-1. What about hash agility (issue is from EKR). Proposal is to adopt an agility plan. If SHA-1 gets broken we're going to have to define a new extension, MESSAGE-INTEGRITY2... Run in parallel. PM: why not change it now? Is there existing deployment. Kai Vehneman: we do short term credentials. JDR: people use MESSAGE-INTEGRITY for ICE. Long discussion about design for MESSAGE-INTEGRITY and whether there should be a field in it for which hash it is. Seems to be mostly EKR, Rohan talking past each other. MESSAGE-INTEGRITY2 will contain a field for what hash algorithm it contains. JDR: If you're going to do STUN over TCP and whenever you're multiplexing STUN with something else, you need to design a shim framing protocol. This doesn't change anything but it's a new requirement. Bruce Lowekamp: Backward compatibility with source address and changed address. We just ignore those? JDR: Yes. 3489bis says you must ignore them. draft-ietf-behave-turn-03 (Rohan Mahy) ====================================== - Changes in TURN major issues e-mail - Structural reorg of the document. - Cleaned up error messages - Added capacity quota error EKR: What is the semantic of accepting a request with a given bandwidth claim? RM: It only means you have bandwidth on your local interfaces. EKR: That seems not very useful but OK. Kevin Johns: It would be nice to have a permission created if one isn't there for a SetActiveDestination. RM: That's what it says. PM: Why can't you reset the same active destination? RM: Rohan, it's reliable. EKR: This algorithm is fine, but the time should be MSL, not 5 seconds. RM: It's a probabilistic issue. EKR: This number should be either MSL or zero. Lars Eggert: This isn't reliability. You need a 3-way handshake. DW: What about reordering? RM: The two requests are in lockstep. JDR: Zero is sometimes OK. The natural case is forking, where it's OK. RM: We talked about removing SetActiveDestination. JDR: One could add a micro-shim encapsulation to let you demux. You would always encapsulate. One could always give up SetActiveDestination. RM: General feeling was that you should get MTU commitment once you did SetActiveDestination. PM: What happens if your response gets lost. You try again and then get an "already set" error. RM: No, the server perceives this as a retransmit. DW: You can estimate RTT to TURN server Magnus Westerland: What about using the OK timer as an estimator for this timer? EKR: Well, we don't do that for TCP TIME_WAIT. RM: TIME_WAIT is different. EKR: No it's not. DW: What about UDP-to-TCP bridging. EKR: The ordering is clear there b/c TCP is reliable. draft-ietf-behave-nat-behavior-discovery-05 (Bruce Lowekamp) ============================================================ Bunch of small changes (see slides) FA: Second bullet [OTHER-ADDRESS, etc.] isn't accurate. You could have two servers rather than one server with a single IP address. JDR: This is an implementation choice. I'm not sure what this is. Let me start a rant. JDR: I fear this is yet another way to make behavior discovery a mandatory part of STUN. I don't want every STUN server to be a behavior discovery server. FA: This is useful.... JDR (plus clarifications from EKR): I worry people will do behavior discovery instead of ICE. The problem is that this draft lets you do some behavior discovery without having two IPs. This whole draft should require having two IPs. BL: Are you saying that no drafts have optional things. JDR: But this is a case we know is bad. BL: But lots of stuff here is useful without dual IPs. For instance source address. PM: But not reliable. ... JDR: What happens when you're doing discovery and this fails. BL: Well, we say you can't advertise STUN discovery unless you have two interfaces. JDR: This ties into the next thing where you're going to require 3489bis servers to do behavior discovery. PM: Clarifying. No p2psip documents use this stuff, but some people think there might be a way to take advantage of it. I don't see it but can't rule it out. FA: Need to clarify what happens if you are doing behavior discovry and one of these requests fails b/c only one IP. BL: You get a 420. JDR: The way I thought this would work was that you had a separate port for behavior discovery. We're making incremental steps towards bringing b-d back into STUN. RM: Should we have some dummy attribute that causes an error if you try to do b-d on a non b-d server. BL: Whole point to break backward compatibility? RM: Solve padding issue. JDR: non-goal to have 3489 to b-d compatibility. RM: What if it works? JDR: It won't. Anyway, the SRV record disambiguates it by port. BL: I don't trust people not to use the same port. RM: Backcompat inherently exists. DW: Maybe this slide needs to go to the list.... RM: Propose we don't provide any normative backcompat language in this doc. BL: Should we remove non-XOR attributes. RM: Should be mentioned in IANA and point to deprecated documents. RM: If you have both SOURCE-ADDRESS and XOR-SOURCE-ADDRESS you can determine if you're behind an address-munging NAT. BL/PM: MAPPED-ADDRESS is fine, but need to explain. JDR: You need to say "always return MAPPED-ADDRESS and XOR-MAPPED-ADDRESS" draft-ietf-behave-nat-icmp-03 (Dan Wing) ======================================== DW: Presented slide deck EKR: There seem to be a lot of issues here... Are the authors here? Extended discussion of is this document is useful and how should we proceed? Would be nice to have editors that attended. PM: Remote participation is OK. EKR: Firewalls block a lot. MW: PMTU discovery needs ICMP. EKR: It seems like it's already kind of broken. LE: Should we make it worse? Greg Lebovitz: People typically block almost all ICMP. We see more ICMP attacks. If it's not absolutely critical we don't allow it. LE: You should be able to make it work with a stateful inspection firewally. GL: There would need to be some kind of gateway to map the TCP/UDP connection to the ICMP... LE: It's TCP, not application. GL: I remember this now... You need to look in the ICMP datagram to see which flow it is. I think we fixed this to look in the payload, but it's probably an option. DW: A PAT would need to. GL: All NATs/PATs have access control now.