PCP Session 1, Monday 26 March 2012 Chairs: Dave Thaler, Ralph Droms (substitute) 1510-1520 Chairs update, including v6ops thread (Chairs, 10) 6204bis (v6ops) has an open issue re PCP Q1. Is requirement for PCP client okay? v4-only or dual-stack? Q2. Should PCP server be required in CPE? Just for configuring local state? Francis: No reason to put a SHOULD to the PCP client, and not another protocol that can do the same thing. Dave: current defaults from v6ops: Q1=yes, dual stack; Q2=no Stuart: Apple base station has local (CPE-based) apps Dave: another example is web-based CPE configuration Margaret: we can't make requirements for ALL CPE equipment. "SHOULD" doesn't help me; a PCP client is useless without anything to configure Tom Taylor: server function on the CPE needs PCP, not the CPE per se Simon: any CPE router has the ability to run a local server, so the text as written is sufficient Pete Resnick: we got into this mess because CPEs were too stupid to realize that they might have private addresses on both sides. Not clear on why it's SHOULD not MUST. Assuming proxy on the CPE. Also servers will probably be running on the CPE, so need PCP anyway. Dave: no strong consensus in either direction 1520-1600 Base spec (Dan Wing, 40) Document: draft-ietf-pcp-base-24 IESG review resulted in 6 DISCUSSes, many about lack of Transaction ID. Stuart added section 6 "Protocol Design Note". Dave: We discussed this at a previous meeting, and declared rough consensus. Pete: Stuart has almost convinced me that we don't need transaction ID, but we still need changes in the document. IMAP has non-specific responses; clients and servers are both badly written, so clients poll mercilessly. Give implementation advice to set expectations about client and server behavior. Stuart: This is raising the bar about reliability. Pete is asking for mandatory server notifications to avoid stupid polling. Dave: Any objections to making unicast mapping updates mandatory, with at least one retransmission. Iljitch: PCP will never be 100% reliable, so be prepared to deal. DISCUSS: port numbers (Ralph Droms) Should unicast unsolicited ANNOUNCE be sent to 5351 or the source port from currently-active mappings? Francis: use fixed port 5350 (same as multicast ANNOUNCE port) Stuart: There may be multiple clients on one host, which can't share a unicast listening port. Therefore, the last option is the only one that will work. Francis: suggest a new PCP opcode to register an ANNOUNCE listening port DISCUSS: remove THIRD_PARTY (Stephen Farrell) Separate document, discussing mandatory-to-implement security mechanism. Implementations are using THIRD_PARTY for web portals (originally designed for UPnP-IGD IWF). Dan: A separate document would say all the same things. Dave: If this is in a later document, it could take a normative reference to a non-simple security model, because that would be a working group document at that point. Dave: Sense of the working group is that we'd would rather leave in, but will remove it if it's the only way to clear the DISCUSS. Dave: Would like to get DISCUSSes cleared this week, and get -25 published ASAP. Francis: At least one place where the document is ambiguous about which zero address to use. Suggest to replace "zero" with "undefined". 1600-1610 DHCP for PCP (Mohamed Boucadair, 10) Document: draft-ietf-pcp-dhcp-02 Authors believe they've resolved all comments received, next step is WGLC. Dave will consult with Alain. Ralph: cross-post last-call to dhc working group ============================================================================= PCP Session 2, Tuesday 27 March 2012 Chairs: Dave Thaler, Ralph Droms (substitute) 1300-1305 Chairs welcome (Chairs, 5) Slides: http://www.ietf.org/proceedings/83/slides/slides-83-pcp-8.pdf >>PCP Base cont. 1. DS-Lite security considerations to be moved to DS-Lite PCP document? 2. THIRD_PARTY option and related security considerations to be moved to new THIRD_PARTY PCP document? Mohamed & Francis both stated that the THIRD_PARTY option is useful. Dave Thaler: We're not proposing getting rid of the THIRD_PARTY option just moving it to a document of its own, with appropriate security discussions. Stuart: It was valuable that we considered the third-party option to see if there are any implications on the base spec, so no problem moving third-party to another document. Med: Not happy to move third-party out of base spec, and to make mandatory authentication. Margaret: third-party document would have to make a normative reference to a security document, which we don't have. Francis: To delete all mappings for a subscriber requires third-party, until we have GET/NEXT to query the server Margaret: But that would be dangerous without authentication. Stuart: This illustrates that we don't have consensus on the THIRD_PARTY option. Third-party is optional to implement, so it's already not a required part of the base spec. Margeret: We can either do something about Steve Farell's DISCUSS, or we can wait forever to publish the base spec. Dave Thaler: Should we move THIRD_PARTY to separate document? 12 hands for moving to new doc 2 hands for retaining in base spec Declare strong consensus, confirm on the list. 3. Nonce/Transaction ID Sam Hartman has pointed out security hole -- unlike STUN, client is vulnerable to off-path attacks. Can be fixed by adding client-specified per-mapping nonce, and then client only accepts notifications where the per-mapping nonce matches. Dan Wing: This attack is only possible if attacker is able to inject packets with spoofed source address matching the PCP server. Don't see the value of protecting against server spoofing without protecting against client spoofing Stuart: I support this solution. Francis: This doesn't protect against bad clients consuming all the server's mappings Margaret: This protects against off-path attacks, but on-path attacks where the client spoofs replies are still possible, so it's no worse than what we have now with STUN. Dave: anyone strongly object to adding a nonce? No, confirm on list. 1305-1320 PCP Authentication Mechanism (Margaret Wasserman, 15) Document: draft-wasserman-pcp-authentication-02 Continue with current EAP-based approach, or switch to PANA? Alper: This is not an EAP vs PANA discussion. Better and more flexible to separate key management from PCP; not a good idea to bundle things. We've seen this before in other WGs. Francis: I believe this is a deployment problem. I have no good idea of what is an enterprise NAT. In cases where PCP needs auth, you already have network access, so don't need all of PANA. Margaret: PANA isn't available on major desktop OS, neither is PCP, but EAP is. Med: Don't see the need for authentication for PCP where we don't need it for normal traffic (implicit mappings). Dave: Without having resolved the question of inline vs PANA, should we adopt this as a working group document? 12 hands in support 3 hands against Alper Yegin: We need to decide whether to do key management within PCP, or externally. 1320-1330 PCP Proxy (Dan Wing, 10) Document: draft-bpw-pcp-proxy-01 Slides: http://www.ietf.org/proceedings/83/slides/slides-83-pcp-4.pdf Please read the draft, provide input on the list. Dave: Of those who have read it, broad consensus that this is a good starting point for a working group document. If you haven't read it, read it, post on the list about the open issue. Francis: There are two problems which are not here. It is really to make it stateless. So this is a good property which puts some constraint of PCP itself. It is only a problem if you want to put the proxy on a box without enough memory. If you cross enough NATs you identify nobody. You have another problem which is totally silly. You can do everything within the client. The other way is to have smart proxies. They are not compatible. 1330-1340 UPnP-IGD Interworking Function (Mohamed Boucadair, 10) Document: draft-ietf-pcp-upnp-igd-interworking-01 Slides: http://www.ietf.org/proceedings/83/slides/slides-83-pcp-1.pdf Any objections to starting a WG Last Call on this? Francis objected that the issue of an IGD client that asks for a lifetime longer than the PCP server is willing to grant can never be solved, and therefore the entire work item is futile. Dave: This is an issue, but not an open issue. Dave: will confer with Alain about whether to start WG Last Call. 1340-1400 DS-lite Open Issues (Paul Selkirk, 20) Document: draft-dupont-pcp-dslite-01 Paul Selkirk: Do we need to pick one, or can we allow both Dan Wing: We need to make a decision and pick one Francis Dupont: Security should be implemented in the B4, not the AFTR Simon Perrault: We need to specify the on-the-wire protocol, and it should be outside-the-tunnel. Margaret Wasserman: weird to specify this at all. A server listens on a port and receives requests. Why do we need to mandate what address family it is allowed to listen on? Francis Dupont: We need to specify the on-the-wire protocol, and it should be outside-the-tunnel. PCP DS-Lite mode being discussed in v6ops working group for 6204bis. WG suggestion is that v6ops should remove PCP DS-Lite mode from their requirements. 1400-1420 PCP Extensions (Mohamed Boucadair, 20) Document: draft-boucadair-pcp-rtp-rtcp-03 Slides: http://www.ietf.org/proceedings/83/slides/slides-83-pcp-2.pdf Francis Dupont: Does delete remove one port or two? To clarify, this allocation is for a pair of ports, but renewal and deletion should be per port. Dave Thaler (to WG): Is this a problem worth solving, and is this document a good starting point? Bill Versteeg: This is a hack to support a hack. Why bother doing this at all? If we do it, why limit it to two ports? Better to define an extension to allocate a range of ports, where n=2 in this case? Rebecca: How is this different to port set allocation? Dan Wing: I support Bill's comment. Should support generic number of ports. General trend in RTP is away from this hack, but we may need to support it for legacy. Simon Perrault: Port Pair option is useful, but this is intentionally simple, and solves a real need we have now. Limit it to exactly two ports, not an arbitrary number. Dave: call for hums; don't hear a large energy level 1420-1435 PCP Extensions (Mohamed Boucadair, 20) Document: draft-boucadair-pcp-extensions-02 Slides: http://www.ietf.org/proceedings/83/slides/slides-83-pcp-3.pdf Ralph Droms: Has the WG previously discussed all these options? Dave Thaler: Not yet. We have been focusing on the base spec. There are 4 or 5 independent options to ask the WG about here. Margaret: I don't think we should break this into separate documents now. But start a threaded discussion on the list, to individually consider each option. 1435-1445 Using PCP To Coordinate Between the CGN (Cathy Zhou, 10) and Home Gateway Via Port Allocation Document: draft-tsou-pcp-natcoord-05 Slides: http://www.ietf.org/proceedings/83/slides/slides-83-pcp-5.pdf Francis: Is there a good reason to use PCP to manage port sets, rather than DHCP? Cathy Zhou: PCP is very flexible. It's designed for port management, so we extend it to do port set management. Francis Dupont: Why not use DHCP? Cathy Zhou: Some operators may not have a DHCP server. Pete Resnick: When would you not request all ports? Cathy Zhou: When each CPE only gets a fraction of available ports Dave: Take it to the list. 1445-1450 PCP Server Discovery with IPv4 traffic (Prashanth Patil, 10) offload for Proxy Mobile IPv6 Document: draft-rpcw-pcp-pmipv6-serv-discovery-00 Dave: Nobody's read this yet, try to drum up interest on the list. 1450-1455 Cases Study- PCP Deployment in Mobile Network (Gang Chen, 10) Document: draft-chen-pcp-mobile-deployment-00 No comments from the room. Dave: Request comments on the list. 1455-1505 Using PCP to Find an External Address (Fred Baker, 10) in an NPTv6 Network Document: draft-baker-pcp-nptv6-search-00 Iljitsch van Beijnum: What is the multicast scope? Fred Baker: The administrator configures that. Iljitsch van Beijnum: That doesnt sound very zero-configuration. Fred Baker: Default to administrative scope. Iljitsch van Beijnum: What does administrative scope mean in practice? Fred Baker: It is determined by the administrator.