BEHAVE Minutes -- IETF 71, Philadelphia, March 13, 2008 (updated 3-Apr-2008) Reported by Dean Willis and Dan Wing audio archive: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf71/ietf71-ch5-thur-noon-behave.mp3 =-========== Chaired by Dan Wing Slides presented Agenda modified to re-order Bruce Lowekamp's Behavior-Discovery Note Well presented Status of WG reviewed by chair. Asked WG to review draft-bagnulo-v6ops-6man-nat64-pb-statement-01 =-========== Topic: RFC 3489bis Jonathan Rosenberg Slides Presented Open Issue: IPSec/HIP/STUN demultiplexing The HIP WG asked if BEHAVE could change the STUN header to make the demux between ESP and STUN easier. Jonathan proposed to allow applications to add additional framing around a STUN message if required/desired to make their demultiplexing easier. Remi suggested using the existing STUN magic cookie, which would only occasionally demux wrong; the Fingerprint could be used to ensure correct demux. Issue: Binding problem -- Cullen stated that the node would also have to use the additional framing in their STUN messages to gather candidates, since both must be sent/received on the same transport address and there is no way to guarantee that candidate gathering messages happen before connectivity check messages Miika Komu: reports that HIP specific STUN messages would be sent only to a specific reserved PORT number. Philip reports that HIP as considered using a HIP packet for binding discovery instead of STUN as part of HIP/UDP encapsulation; if this path is taken, HIP doesn't need a special STUN server. As the HIP group decides how HIP is encapsulated over UDP, this will become more clear. Philip asks if we are worried about other uses of ESP. Answer (Jonathan) yes. For example, we have drafts using ICE to negotiate an IPSEC tunnel, so this will re-occur frequently. Remi suggests that you could use two "connected UDP sockets" to differentiate, or use time discrimination. Jonathan Lennox and Cullen pointed out this wouldn't work well if you did not yet know the remote IP address. Jonathan points out this could potentially cause ICE to fail. Jonathan pointed out we are discussing a difficulty-to-implement issue, rather than an on-the-wire-protocol issue. Philip suggests that we don't have the right people -- we need to get the IPSec coders or security AD. Hannes will send contacts to Jonathan, chair, and AD. SubTopic: Major changes since rfc3489bis-13 Change 1: Pacing Interval. Lars noted that it is critical to make default behavior conservative, even though ICE's pacing makes it more aggressive. Change 2: SASLPrep for username and passwords. Canonicalization for UTF-8. There is another Discuss that SASLPrep should be removed. Change 3: Maximum message size in absence of PMTU -- reduced from 1500 to 576, with an exception for Behavior-Discovery or if MTU can be discovered. This will mostly not be an issue, except for TURN. Subtopic: Cullen Discuss 1: Server Close connections Agreed to add words about periodic sending of data. Remi notes that the timer should be some large multiple of seconds. Noted that TCP Keepalive can meet this requirement. So if the server turns off SO_KEEPALIVE, it may need to implement something else. Adam notes that no other TCP protocol seems to talk about this. Why do we need to? JDR replies that here the server has no prior knowledge, so it needs something. Subtopic: Cullen Discuss2: Nextnonce Do we need it? JDR proposes to leave it out at this time. EKR concurs with proposal, as it easy to add later. Cullen notes that lack of next-nonce may impact overlapped transactions. EKR asked if we can have two overlapping transactions with different nonces; answer: yes. Subtopic: Cullen Discuss3: IANA Rules What should the registration rules for attribute and methods be? IANA has asked that we move away from pure FCFS to Designated Expert. Conclusion: we adopt a policy of one namespace with Designated Expert review. Subtopic Cullen Discuss4: Determine Server Type Philip thinks we should look at that section and see what happens if an XOR-MAPPED address is returned. It may mean that we have to define those codepoints in 3489bis for codepoint discovery. ACTION: Conclusion: update spec to say client has to ignore reserved attributes in the response, and deprecate forking. Subtopic: Cullen Discuss5: MTU Example: Protocol might die if a long username results in fragmentation. This argues for using a transport protocol capable of handling the data size. EKR suggests that we can deal with this by having the sender fail if its packet is too big. ACTION: Cullen resolved to remove Discuss. Subtopic: Cullen Discuss6: Stringprep Proposed to note that this is an implementation issue in the spec. This might be an non-starter for embedded systems. The password might also be pushed already string-prepped, or not. EKR proposes that we keep this in the spec; many will ignore it. ACTION: The room agreed with this proposal. Subtopic: Cullen Discuss7: Demux Proposed that we document the limitation. WG agrees and suggests documenting in ICE. Subtopic Newman Comment1: Separate Port Objects to using separate port for TLS-variants. Proposed that we ignore this comment. Remi notes that only servers would need starttls. Action: Resolved: accept proposal, ignore comment. =-========== Topic: Nat Behavior Discovery Bruce Lowekamp Slide presented Reviewed changes since last version. Resolved that we not wait until STUN clears IESG review, and we should WGLC Behavior Discovery now. =-========== Topic: STUN Philip Matthews Slides presented Subtopic IP Header Bits Issue: ICMP Relay. How does this work? Philip: Fuzzy, but try to steal from behave ICMP Question: Is the compliant supposed to discover this? Do we think people will ask for "fully-compliant" and then fall back if unavailable? Answer: yes, this is critical for relaying arbitrary data Remi notes that RFC 4380 (Teredo) specifies NOT setting the DF bit in certain cases. ACTION: Philip needs to read this. Cullen wonders if we can get application-style PMTU discover on partly-compliant relays. Philip thinks we can get "working size". Cullen suggests a per-packet flag in the send request that says "Please set DF when forwarding". This is needed for TCP-to-UDP as well. ACTION: Cullen is requested to send this to the list, as are people who think it is NOT a good idea. Rohan notes that he likes Cullen's proposal, because he really needs TCP case. Subtopic: ALTERNATE-SERVER Proposed that we remove ALTERNATE-SERVER from STUN for now, and reconsider later if needed. Cullen and Jonathan argue in favor of keeping regional redirection. BruceL suggests that we need big caveats and cautions around ALTERNATE-SERVER mechanism. Motivation here is mostly anycast -- return an IP address and port that is anycast. Question: How does this work in TLS? What cert do you use? EKR answers that you test against the same name as the first request. ACTION: Poll: Do we have consensus on keeping this feature? Yes. However, design needs to go back to design team. SubTopic: BANDWIDTH Issue: BANDWIDTH Parameters Magnus does not recommend RFC 3890, as this provides too rough of a hint. Issue: Retry needed to step from controlled-load request to best effort Issue: If client does NOT request a BANDWIDTH parameter but the server wants to use one, what happens? Lars notes that "BANDWIDTH" is not something you can depend on, as what is needed is a hop-by-hop resolution. So either this is horribly underspecified, or it is useless. It should therefore be deleted. Cullen thinks this is not about real bandwidth -- it is about limiting the forwarding rate on each node. This has nothing to do with the network's actual bandwidth. Magnus proposes calling this "Maximum Forwarding Rate". Poll: Do we want to delete this whole thing, or do something in this area? Do something JDR proposes splitting off to a separate doc. Adam notes his implementors do not know what to do with this. Action: back to design team =-========== Topic: TURN-TCP Rohan Mahy slides presented SubTopic: Blocking/Fair Sharing Question: Why are we muxing traffic on one TURN connection? Ans: Forking:? Remi asks: Why not make it one allocation shared across multiple sockets ? JDR adds another issue: this b\needs to be designed for more general purpose than just SIP. Also, if we ran TCP over UDP, it would apparently all be ok. No conclusion =-========== not presented (no time): DCCP Remi Denis-Courmont