BEHAVE meeting minutes -- IETF 72, Dublin Chair: Dan Wing, dwing@cisco.com. Minutes by Chriz Metz, Mariano O'Kon, and Dan Wing Audio (for most of the session) starts at 2:28:10 at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch3-tue-noon.mp3 (audio is cut off partially through TURN URI presentation and audio does not include DCCP or SCTP presentations) ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== FIRST SESSION, Tuesday, July 29, 15:20-17:20 Dan called the meeting to order, displayed the agenda and solicited note-taker. WG milestones and document status were deferred to the second session. http://www3.ietf.org/proceedings/08jul/slides/behave-1.ppt ========== ========== ========== ========== ========== ========== ========== TURN Update draft-ietf-behave-turn-09 presenter: Jonathan Rosenberg Slides: http://www3.ietf.org/proceedings/08jul/slides/behave-8.ppt Jonathan opened his remarks suggesting that TURN draft was suffering from "feature creep" and that it was time to move it forward ("finish is a feature") and that additional features could be placed in extension documents. Other items of note: Overviewed TURN-08 changes including Preserving vs Non-Preserving Allocations. Overviewed TURN-09 draft changes. Few people have read draft. Jonathan, Cullen, Dave Thaler and a couple of others engaged in lengthy discussion on the issue of Unauthenticated Persmission Refresh as orginally described by Cullen on the mailing list (http://www.ietf.org/mail-archive/web/behave/current/msg04176.html). Jonathan showed two pictures, one describing the attack as outlined by Cullen and another showing an attack without TURN. There was some disagreement on which attack was easier and harder and thus more likely. 4 options for addressing this problem were proposed. 15-20 people in the WG reached consensus that option 4 (Clients MUST ignore Data from unknown peers) should be supported independent of any of the remaining three options. Raised hands on the remaining options: 6 for Option 1: Do nothing. A concerned client can use TLS to avoid the problem; 0 for Option 2: Add DTLS to improve Option 1 - now UDP works securely and; 3 for Option 3: Introduce a Send request/response transaction in addition to the current Send indication. [note, during the TURN design session on Wednesday afternoon, it was determined this attack is easier than as presented in BEHAVE. At the TURN design session, Solution 3 was chosen: add request/response for Send.] "Preserving" was introducted in TURN-08 and Jonathan opined that it already can be viewed as an extension given that it has its own section. He also added that it is complex, requires raw sockets, needs further review and is not a specific function needed for TURN. The WG accepted (15-0) a proposal to extract and move to a separate document. At this point, time expired and Dan suggested an informal ad-hoc meeting should be held with other TURN-interested parties to discuss remaing TURN open issues and proposed resolutions. The summary of those discussions is on the mailing list: http://www.ietf.org/mail-archive/web/behave/current/msg04231.html ========== ========== ========== ========== ========== ========== ========== NAT for IPv6-only Hosts draft-jennings-behave-nat6-00 presenter: Cullen Jennings Slides: http://www3.ietf.org/proceedings/08jul/slides/behave-3.ppt This draft outlines various NAT behaviors and interactions when IPv6 hosts communicate with IPv4 hosts thru a NAT The first issue described by Cullen involved IP fragmentation in which there is an MTU mismatch between IPv6 and IPv4 sides. For example an IPv6 host will send packets less than 1280 bytes (say 700 bytes) with do not fragment set. The NAT upon receiving the packets might attempt to forward the packets onto an IPv4 MTU=576 link with do not fragment set resulting in dropped packets. Or the NAT might attempt to send an ICMP "packet too big" message back to the IPv6 host and for some reason, it does not reach it. There was much discussion at the mic on exactly what an IPv6 host does. Moreover there was discussion on whether it was an application problem or an IPv6 stack problem. There was some discussion on the two options: Option A: When using NAT, V6 packets which can be fragmented, are sent with fragmentation header even if smaller than 1280 Option B: Don't translate V6 "do not fragment" to V4 Breaks MTU path discovery Next there was a discussion on who or what should map an A record in the 4 to 6 case. Options discussed included DNS ALG, applications and hosts. Again more discussion on what an application is. ========== ========== ========== ========== ========== ========== ========== NAT64 draft-bagnulo-behave-nat64-00 presenter: Marcelo Bagnulo Slides: http://www3.ietf.org/proceedings/08jul/slides/behave-6.ppt Marcelo provided a brief overview of NAT64 and the typical scenario. Unlike NAT-PT NAT64 requires that the IPv6 host initiate connections. A comparison of NAT64 and NAT-PT was also provided. Marcelo then raised several design issues for discussion. The first asked what prefixes to use to map v4 addresses into v6 which the choices being Local or a Global (Well-known) address. The implications on dual stack behavior and routing were briefly discussed. There were concerns expressed at the mic about DNS modifications being harmful. There was also questions about the behavior of an IPv6 host vs dual-stack. The other design issue involved endpoint independence vs higher utilization of IPv4 addresses. ========== ========== ========== ========== ========== ========== ========== Prefix-specific and Stateless Address Mapping (IVI) for IPv4/IPv6 Coexistence and Transition draft-xli-behave-ivi-00 presenter: Xing Li Slides: http://www3.ietf.org/proceedings/08jul/slides/behave-5.pdf Professor Li presented his draft on a scheme that utlizes a new form of address mapping that facilitates IPv6-to-IPv4 interoperability. The primary driver is that new and existing IPv6 hosts will need to interoperate with IPv4 hosts. The explanation of the IVI address mapping and algorithm was presented and then four different scenarios were described. Other aspects of IVI including references were included. A comment from the mic requested results on application behavior when employing IVI and Prof. Li agreed this would be useful. ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== ========== SECOND SESSION, Tuesday, July 29, 18:50-19:50 Milestone and document status: Dan Wing (DW): Late on many deliverables. NAT ICMP draft is still in IESG processing, waiting to close a DISCUSS with Cullen. STUN test vectors is ready to WGLC. Will issue second WGLC for behavior-discovery. Will issue WGLC on DCCP document in conjunction with the DCCP WG. Jonathan Rosenberg (JR): * TURN TCP: It has no attention from the authors. Need help from folks with real implementations * TURN v6: Need to discuss in the ad-hoc session (4:10 to 5:00 on Wed) Magnus: Magnus will approve the STUN document for publication. DW: We need more attention on Path MTU Discovery document (draft-petithuguenin-behave-stun-pmtud-01.txt) JR: We talked in MMUSIC and we need it. Cross-reference it to MMUSIC? DW: I thought the AVT guys would be more interested JR: Because of the relationship with ICE, MMUSIC would be interested. DW: Dan will make MMUSIC aware of the document. ========== ========== ========== ========== ========== ========== ========== Carrier Grade NAT draft-nishitani-cgn-00 presenter: Tomohiro Nishitani (TN) TN : presented slides Marc Petit-Huguenin: port range seems very small; it needs more. Shin : Document describes the safest port range. Magnus : I don't see a problem with using any ports above 1024, especially if you have filtering for incoming traffic. Shin : We are filtering unsolicited incoming traffic. David Bowles : I have a concern with the Req-6, support of pass-through to specific hosts. It creates a pre-requisite of a private address space to the wider ISP environment, large enough to support support every single CPE in the ISP. There is validity, but I am concerned to make it a requirement. Can this be changed to MAY? Shin : We will consider this. Our concern is that a subscriber might consume all of their TCP ports using HTTP, but we still want to allow connections to specific hosts. David : The exclusion of certain destination ports (or destination IP addresses) is reasonable. I am mostly concerned with REQ-6; this makes sense with TR-069. How about putting the TR-069 ACS in front of the CGN, which allows REQ-6 to become a MAY. Shin : We will consider this modification. Remi Denis-Courmont : In v6ops we are documenting what certain NATs can do with certian protocols. This document appears to describe how a NAT works with multiple protocols. Not sure what is meant by the word 'carrier'. Shin : We just used the term 'carrier', it has no special meaning. Brian Carpenter : REQ-9a: is this a NEW failure mode (refers to sending ICMP error when no mapping is available)? DW : It is already documented in BEHAVE documents Brian : The fairness requirement implies that you know you might not be able to provide enough ports to every subscriber. I don't understand the motivation to stretch NAT even further. Will be interesting discussion in Plenary. JR : My sense of the fairness issue is that we have a finite amount of v4 IP addressess shared between a number of users. You will run into congestion as with bandwidth. You need a fairness algortihm. To my mind, this is the significant difference between 'carrier NAT' and normal NAT. Shin : How should we move this document forward. DW : We don't have a milestone for this work. We will talk with Magnus to figure out path forward for the document. ========== ========== ========== ========== ========== ========== ========== TURN URI draft-petithuguenin-behave-turn-uri-02 presenter: Marc Petit-Huguenin (MPH) MPH : This doc does not the mechanism speficied in the TURN spec. This is simply a way to map a domain name into a DNS to reply with a set of ip addresses and ports RDC : I wonder if there is a Best Practice on how to specify the transport in the URI instead of the "?" MPH : This is exactly the way that DNS URI works... JR : Do no include additional capabilities in the DNS. We didn't do it for SIP. RDC : I agree with JR, I don't see additing capabilities in the DNS NAPTR RR as a good thing JR : Why not include username/password in URI? MPH : They are deprecated (c.f. RFC2396) DW : I want to see if people are interested in this doc. Usefull? Useless? Harmful? etc. Only person that indicated interest during the straw poll was JDR. ========== ========== ========== ========== ========== ========== ========== DCCP draft-ietf-behave-dccp-01 presenter: Remi Denis-Courmont Remi presented slides. No objections were raised. Three people had read the draft. We will be doing a WGLC on the mailing list. ========== ========== ========== ========== ========== ========== ========== SCTP draft-stewart-behave-sctpnat-04 presenter: Michael Tuexen Michael presented slides. It was clarified that the verification tag does not need to be negotiated during session setup (e.g., in SDP) -- only the SCTP port, as per draft-loreto-mmusic-sctp-sdp-01.txt. Jonathan pointed out that everything should run over UDP (rather than its own protocol number), reference draft-rosenberg-internet-waist-hourglass-01.txt. Dan will ask on the mailing list if there is consensus to adopt this document as our working group document to meet the SCTP milestone.