PCP Session 1, Thursday 2 August 2012, 1510-1710 Chairs: Alain Durand, Dave Thaler Notes: Paul Selkirk, Stuart Cheshire Audio: http://www.ietf.org/audio/ietf84/ietf84-regencya-20120802-1510-pm2.mp3 1510-1520 Chairs update (Chairs, 10) Docs currently completing WGLC: draft-ietf-pcp-dhcp draft-ietf-pcp-upnp-igd-internetworking ------------------------------------------------------------------------------ 1520-1530 Last IESG Discuss on pcp-base Document: draft-ietf-pcp-base (Dan Wing, 10) Robert Sparks DISCUSS on retransmission Added text documenting an inevitable race condition where server may send response to client, and then later the server changes state. Documenting existing behavior of a corner case, Robert is cool with it. Stuart: worried that we're agonizing over things that should never happen, but not willing to spend more time on this Pete Resnick DISCUSS on communicating state loss to client: 1. Use broadcast as well as multicast for rapid recovery? Conclusion: Broadcast is not necessary. Multicast is fine. 2. Wants rapid recovery to be mandatory Francis Dupont: What about hardware that can never fail? Operators are required by law to keep logs of every access and never lose them, so that means the hardware can never fail. Why should it have to announce something that can never happen? Pete: Are you talking about a device that can never lose state? Francis Dupont: Yes Pete: Then text can be conditional: PCP Server must *either* guarantee to never lose state, *or* send rapid recovery messages. Alain: so this is a conditional MUST Kerry Linn: Can rapid recovery message be forged? Dan Wing: Yes. The document already addresses this issue. Tirumaleswar Reddy: PCP servers that never lose state shouldn't have to implement rapid recovery. ------------------------------------------------------------------------------ 1530-1545 WGLC results: UPnP-IGN Interworking Function Document: draft-ietf-pcp-upnp-igd-interworking-01 (Jaqueline Queiroz, 15) Dave Thaler: re long or infinite lifetime, new text is what I was looking for Francis Dupont: does IGD support multiple external addresses? Dave Thaler: my reading is that the IGD spec is agnostic There will be another WGLC in a week or two, need at least 3 additional reviewers. Paul, Xiaohong, and Tirumaleswar Reddy volunteered to review updated doc. ------------------------------------------------------------------------------ 1545-1555 Provisioning Message Authentication Key for PCP using PANA Document: draft-ohba-pcp-pana-00 (Yoshihiro Ohba, 10) Margaret Wasserman: Thanks for writing this proposal. There's nothing in the PANA key exchange that says this is for PCP authentication rather than network access authentication; will this operate correctly? How would the PANA server know whether the client is asking for network access or for PCP access? Yoshihiro Ohba: I didn't think about that. Either PANA or PCP should be able to deal with it. Margaret Wasserman: How is the PANA session bound to the PCP session? Yoshihiro Ohba: It is described in the document Margaret Wasserman: The PCP client and PANA client may need to communicate more information. The PANA client needs to talk to the right PANA server for the selected PCP server. Ohba: PCP client gets the server address from the PANA client Subir: assumption that PANA server and PCP server are co-located Tirumaleswar Reddy: If client is already using username and password, can it still use the same username and password? STUN already has an authentication mechanism; can PCP use the same mechanism? If the client is using username and password for STUN, then it would want to use the same username and password for PCP. ------------------------------------------------------------------------------ 1555-1615 Comparison of PCP Authentication approaches (Margaret Wasserman, 20) Document: draft-ietf-pcp-authentication-00 Francis Dupont: How does this compare to just running PCP over DTLS? Margaret Wasserman: There is currently no draft written to specify how it would work. You can't "just run" anything over DTLS. It's not that simple. Alper: Does PCP auth comply with EAP lower-layer requirements of RFC 3748? Has it been analyzed? Margaret: Don't know Alper: Are PCP and EAP state machines compatible to work together? Has that been analyzed? Margaret Wasserman: There is no PCP state machine. Subir Das: PANA is defined as lower layer for EAP. Should every protocol define its own lower layer for EAP? In-band mechanism uses most of PANA-like features. Stuart: hearing two conflated questions: 1) should we reuse existing technology (yes); 2) should we use separate ports (no, that's fragile). Could we literally tunnel PANA messages inside PCP options, to avoid the fragility of listening on and using two separate ports? Margaret Wasserman: The problem is that information in the PANA header duplicates (and may not be consistent with) information in the PCP header. Yoshihiro Ohba: Work for putting EAP inside packets has already been done. It's called PANA. It took a long time to get PANA/EAP synchronization right. Margaret: if the PANA SA goes away, there's no defined way to notify PCP; not sure why this is a problem with in-band, but not separate Dan Wing: successfully multiplexed STUN and EAP on one port Subir Das: Agree that its desirable to use a single port. Alain Durand called for show of hands: For single port: 23 For two separate ports: 0 Alain Durand called for show of hands: PCP-specific messages (PCP-specific encoding of authentication information): 5 Tunneled PANA (embed PANA data within PCP options): 6/7 Side-by-side (multiplex raw PANA packets and PCP packets over same port): 5/6 Don't care: 15 Alain Durand called for show of hands: PCP-specific encoding of authentication information: 5 Some kind of PANA encapsulation: 10 or 11 Dan Wing: request an interim meeting to discuss solutions, once they've been fleshed out a little ------------------------------------------------------------------------------ 1615-1625 PCP Support for Nested NAT Environments Document: draft-penno-pcp-nested-nat-02 (Reinaldo Penno, 10) Stuart Cheshire: If there's an intervening PCP-unaware NAT, the user has to manually configure the inbound mapping on that NAT, and put the correct address in the Client's IP Address field. The source address sanity check is there to ensure the client is competent and detect failing cases. Relaxing the check won't make those failing cases work. Francis: Detecting the problem is better than doing nothing Reinaldo: relaxing the address check lets us handle this in one round trip rather than two Simon: return perceived address in ADDRESS_MISMATCH (unspecified in base-26) Julia Renouard: still have to make a mapping in the intervening NAT. For security reasons, relaxing the base protocol would be a nonstarter ------------------------------------------------------------------------------ 1625-1640 Using PCP to coordinate port-set allocation between the CGN and Home Gateway (Qiong, 15) Document: draft-tsou-pcp-natcoord-07 Alain Durand (as individual): This is not required for lightweight 4over6. Only DHCP is a "MUST" for lightweight 4over6, not PCP. Qiong: China Telecom doesn't have dhcpv4 servers Alain: maybe we don't want to solve the problem of port set extension Don't need extra mechanism to request multiple ports. A client can just make 50 separate PCP requests. Alain: multiple concentrators in lightweight cases for failover, so you have to send request to each concentrator, may get different answers Qiong: need to re-read the failover draft ------------------------------------------------------------------------------ 1640-1655 Analysis of PCP in Mobile Networks (Gang Chen, 15) Document: draft-chen-pcp-mobile-deployment-01 Reinaldo Penno: If the PCP server is not the default router, how do you ensure that the PCP server you discovery is in the data path? Gang: default router is either PCP server or PCP proxy Dan Wing: if we replace "PCP" with "TCP", we get the same complaints; don't delay transmissions to sync with radio link timers Stuart Cheshire: agree with Dan, first transmission is triggered by something the user wants, but renewal is more leisurely Dave Thaler: what is the state of stateless DHCPv6 in cellular networks? Subir Das: If there's no DHCP server how is the DNS resolver address configured? Gang: Using existing 3GPP PCO (Protocol Configuration Options) ------------------------------------------------------------------------------ PCP Session 2, Friday 3 August 2012, 1120-1220 Chairs: Alain Durand, Dave Thaler Notes: Paul Selkirk, Stuart Cheshire Audio: http://www.ietf.org/audio/ietf84/ietf84-regencyb-20120803-1120-am1.mp3 1120-1125 Chairs welcome (Chairs, 5) ------------------------------------------------------------------------------ 1125-1140 WGLC results: DHCP for PCP (Jaqueline Queiroz, 15) Document: draft-ietf-pcp-dhcp-02 Discussion about whether to use plain strings or RFC1035-encoded FQDNs even for things that aren't FQDNs, like IP literals. Stuart: need a better way to encode this, or another draft that says that a "name" that ends in a number is an IP literal Dave: ICANN says there will be no numeric TLDs Don Eastlake: not aware of the RFC that restricts TLDs Dave: referenced in the recent IAB statement [http://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-statement-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook/ points to specified text in RFC1123 section 2.1] Dave: drop the trailing dot if it's an IP literal, or in all cases? Stuart: don't use RFC1035 encoding for non-FQDN Alain: don't simply remove the dot, because names that end in a dot and not in a dot mean different things Dave: agree with Stuart, don't use RFC1035-encoding Stuart: DHCP domain option is a string literal, good enough for dhcwg Consensus: just use plain strings like the existing DHCP "domain" option, no RFC1035-encoding for any names Discussion point 2: name resolution on server side, send IP address? Consensus on DHC WG mailing list: no change ------------------------------------------------------------------------------ 1140-1150 PCP Server Discovery (Tiru Reddy, 10) Document: draft-reddy-pcp-server-discovery-00 Dave: why not use DHCP discovery mechanism? Tiru: it's equivalent Alain Durand: interesting to look at multihomed case, but the scope you've chosen is not large enough - don't want one solution for multihoming to the Internet, and another solution for multihoming to different networks. Expand scope to cover things like VPNs and walled gardens. Suggest working with Reinaldo on ZONE proposal. Stuart: Why are you inventing another service discovery protocol? "just use multicast" is an over-simplification - there may be dozens of firewalls, but you're only interested in firewalls on the data path Tiru: there will be different scopes, but undefined Stuart: leaving the question unanswered doesn't help the implementer or the user Dave Thaler: Agree we should focus on one solution instead of multiple ways to do the same thing. For discovery we should choose either DHCP or something else. For the multi-homing question, should the WG really try to solve that problem? Alain Durand called for a show of hands Alain: is there interest in solving the multihoming case? Support working on solving multi-homing case: 10 Oppose working on solving multi-homing case: 0 Chairs directs author of DHCP document to move multihoming to a separate document. Dave: fix base spec to not require single-homing Dave: DHCP option has been through one WGLC, got 4 reviewers, want to get to at least 5 by the next iteration Paul & Stuart volunteer ------------------------------------------------------------------------------ 1150-1200 Behavior of BitTorrent service in PCP-enabled (Xiaohong Deng, 10) networks with Address Sharing Document: draft-boucadair-pcp-bittorrent-00 Dave: My reading of this is that BitTorent works better with PCP and appropriate configuration. Are there any gaps in PCP? Xiaohong: No. Dave Thaler: So summary is that PCP does successfully meet the needs of BitTorrent? Xiaohong: Yes ------------------------------------------------------------------------------ 1200-1210 Using PCP to Trigger Dynamic DNS Updates (Xiaohong Deng, 10) Document: draft-deng-pcp-ddns-01 Simon: how do DDNS servers store port redirections? Xiohong: modify DDNS server to support port mapping Stuart Cheshire: This sounds a lot like how Apple's Back to My Mac (BTMM) Service works, which Apple did in 2004. There's a pretty good description of it in RFC 6281. Back to My Mac uses SRV records. Dave Thaler: For clarification, this is an operational document rather than defining a new protocol. Dan Wing: This draft conflates what the DDNS server is doing with a port relay function. Would like the doc to talk about those separately.