PCP THU 1510-1710 ============= Welcome, Agenda bashing (5, Chairs) Francis Dupont: Adopt DS-Lite document as WG document? Dave Thaler: Will post question on mailing list WGLC Results (30) draft-ietf-pcp-base (Dan Wing) Paul Selkirk: The restrictions about delete-all should only apply to the simple threat model, not the advanced threat model Dan Wing: We don't have the text for advanced threat model written yet Paul Selkirk: But the document still describes delete-all, and then says it doesn't work Dave Thaler: Document can reference what's allowed under advanced threat model, without specifying how advanced threat model will work Paul Selkirk: Disallowing delete-all is a loss of functionality compared to NAT-PMP Stuart Cheshire: But we decided that functionality was not a good idea Margaret Wasserman: Document should limit making educated guesses about what advanced threat model allows before we know how advanced threat model works. Dave Thaler: Document should explicitly state this explicitly, e.g. "If simple threat model, then nonce must match; advanced threat model is yet to be defined" draft-ietf-pcp-upnp-igd-internetworking Paul Selkirk: I have some minor editorial nits with this document, but overall it is complete, and has no wacky ideas. draft-ietf-pcp-dhcp (Mohamed Boucadair) Stuart: Why name rather than IP address? Ralph: Use RFC 1035 encoding for forward compatibility with changes to DNS, e.g. internationalization. Dave: RFC 1035 restricts us to DNS names. Strings are not DNS names, pass string to name resolver, not specifically DNS resolver. Stuart: We should make a decision, should not accept non-fully qualified domain names (including trailing '.'). Stuart Cheshire: Should fit in with existing DHC conventions Mohamed Boucadair: This issue is closed; this WG and DHC have already approved this Ralph Droms: Really? DHC discussed this only this morning. Stuart Cheshire: Whatever it says, the document needs to be unambiguous Pete Resnick: Is what the DHCP server hands out protocol, or is it presentation layer that gets translated into protocol? If it's protocol, define it tightly. If it's presentation layer, you have to deal with all kinds of translation issues. Dave: It's protocol. Stuart: If we require the client to validate the name, we have to say how, but it's okay to remove the restriction in the first place. Stuart: Happy to defer to DHC WG about how to convey multiple strings. (e.g. single option with null separators or space separators.) Dan: Embedded nulls make me nervous, because poorly-written clients pass strings to things like strcpy(). Ralph: Multiple options or multiple sub-options are the norm in DHCP (including v6). Dave Thaler: In DHCPv4, multiple options are concatenated, so even with multiple options a separator or length prefix is still necessary Med to consult with Ted Lemon. If no objection, adopt Stuart's proposal for length byte followed by string, optionally followed by more counted strings? Optimizing NAT and Firewall Keepalives Using PCP (10, Markus Isomaki) draft-reddy-pcp-optimize-keepalives Keepalive Incentive Issues (10, Dave Thaler) (draft-ietf-pcp-base, draft-reddy-pcp-optimize-keepalives) Dave: Should we recommend that middleboxes give longer mapping timeout as a result of using PCP than for connections without PCP? If so, in which doc? If not, what's the point of mentioning it in the spec? Gang: Reducing keepalives beneficial not only to power, but to reducing congestion on the air interface. Stuart: Usefulness of timeout detection algorithms is unproven. You're assuming the lifetime of two different mappings is the same. You're assuming there's a stable lifetime in the first place. PEER gives the client a defined, committed lifetime, so this gives you more reliability. Markus: Timeout detection algorithms are known to fail. This may make them more reliable. Reinaldo: This could give us a way to detect not just the first middlebox, but other on-path middleboxes as well. Simon: We don't have any operational experience with this, so making a recommendation may be premature. Dave: There are documents in the IESG that are requiring use of PCP for power saving. Q1: Should there be a statement in some document? Strong hum in favor, none opposed. Q2: Should this statement be in pcp-base? Strong hum in favor, none opposed. Ask on list for objections. Using PCP to control NAT and Firewalls in Multihoming (10, Tiru Reddy) draft-patil-pcp-multihoming-00 PCP Server Selection (10, Mohamed Boucadair) draft-boucadair-pcp-server-selection Tiru Reddy: Propose merging the two documents Dave: draft-boucadair-pcp-server-selection is a new non-WG document, but all the text is from a prior version of the dhcp document, which was accepted as a WG document, so the assumption is that this will be accepted as a WG document. Dave: We could choose to combine these two documents, or say that server selection stands on its own, and the multihoming draft just covers use cases. Prashanth: In favor of merging documents. Will call on list for objection to adopting as WG document. Retrieving the Capabilities of a PCP-controlled Device draft-boucadair-pcp-capability (10, Tiru Reddy) Dave Thaler: Yes, this is a valid problem. Clients may need to tailor behavior depending on whether server is NAT or Firewall Margaret Wasserman: Question is not as simple as "NAT or Firewall?" Things are not strictly NATs or firewalls, and the lines can be blurred so much that you can't give a meaningful answer. Very seldom in favor of any capability-discovery mechanism because they cause unnecessary failures. Stuart Cheshire: Problem is interesting, but we need to get some operational experience before we can say what is the right answer Dan Wing: Agree that capability discovery is fragile. Taxonomy of NAT vs. Firewall is too simplistic. Learn NAT64 PREFIX64s using PCP (10, Mohamed Boucadair) draft-boucadair-pcp-nat64-prefix64-option Dave Thaler: BEHAVE WG has a heuristic for this, which may not work in all cases Dan Wing: Should we ask BEHAVE WG to reference this solution? Dan Wing: Have you done a comparison of the BEHAVE heuristic compared to the PCP message? Mohamed Boucadair: Haven't done a detailed comparison with heuristic. People agree PCP is better Dave Thaler: If DHCP and PCP answers differ, then trust the PCP server -- it ought to know Tiru Reddy: PCP version also gives you the lifetime Dave Thaler: Call for adoption: strong hums in favor, none against. Analysis of PCP in Mobile Networks draft-chen-pcp-mobile-deployment (10, Mohamed Boucadair) Margaret Wasserman: Why would we run PCP differently in mobile networks? What makes mobile networks different? Mohamed Boucadair: It's guidance for network operators Reinaldo: Server discovery may be different, may not be your default gateway. Gang Chen: Mobile networks are different Margaret Wasserman: What makes PCP server discovery different Stuart Cheshire: 3GPP does not use DHCPv4, so it's not that "mobile" is different, it's that we have to define how to do PCP server discovery on 3GPP Stuart Cheshire: Apple Airport will act on any PCP request it sees, regardless of destination addr/port. So the solution may be anycast. Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation draft-tsou-pcp-natcoord-08 (10, Simon Perreault) Alain Durand: Is this for PEER or only MAP? Simon Perreault: Only MAP Alain: I don't buy the no-DHCP argument. Also, is this idempotent? Simon: If you retransmit the same request with the same nonce, you get the same port set. If you transmit a new request with a new nonce, you get a different port set. Dave: Is this only for NAT44, or can it be extended to NAT64? Simon: This works the same for NAT44, NAT64, NAT66, etc. Call on list for adoption. Dave: Thanks to Alain for his service. === END === FRI 1120-1330 (note new end time) ================================= Welcome, Agenda bashing (5, Chairs) PCP Authentication Open Issues (60) draft-ietf-pcp-authentication (Margaret Wasserman) draft-ohba-pcp-pana (Yoshihiro Ohba) draft-ohba-pcp-pana-encap Margaret Wasserman: Alper said that using PANA gives you a simpler PCP implementation. In reality there are no PANA servers on most networks today, so there's more code to be written, supported, and deployed. Alan Dekok: I agree with Margaret. I've done EAP over multiple protocols, and it's not hard. PANA is rather a lot more work. Alper's statement that RADIUS forces server-initiated re-authentication is incorrect. Alper: COA RFC permits server-initiated re-authentication San Hartman: Yes, COA RFC permits server-initiated messages, but the footnote explains that it's for EAP error reporting, not for re-authentication. There is no way for a RADIUS server to force server-initiated re-authentication. Joe Salowey: EAP authentication can derive keying material. Are we making use of the MSK when using EAP directly? San Hartman: Yes, every packet is integrity-protected. Alper: When using PANA the keys will be exported for PCP to use. At the end of PANA authentication, PANA does a key confirmation. Joe Salowey: As long as messages are integrity-protected, that's good. San Hartman: Would like to hear from PCP implementers about what they want. I believe re-authentication is harmful and unnecessary. We should choose whatever retransmission mechanism is easier for PCP implementers. My opinion is that EAP over PCP is by a large margin, easier to specify, implement, and deploy. Existing PANA implementations are not suitable for use as libraries. There's a lot of work to be done to trim out the parts of PANA that PCP doesn't need. The IETF has lots of experience defining EAP over lower layers. Stuart Cheshire: Strongly agree with everything Sam said. As an implementer, I prefer the minimal approach of using EAP directly. Margaret Wasserman: We don't need to push re-authentication down to the client Sam: Re-auth is harmful because it requires the client to be awake. Hannes Tschofenig: Would like to hear from people that have actually implemented PANA. Re-authentication is not mandatory. There's no harm in having to implement protocol features that are never actually used. Hannes Tschofenig: People should actually implement what they're proposing. Yoshihiro Ohba: PANA is adopted by ETSI M2M. One of the open-source PANA implementations is based on a library, so it's available. Alper Yegin: The server has to send unsolicited messages to the client, so it has to be able to force the client to re-authenticate so that the server can send a message to it. Alper Yegin: PANA is adopted by Zigbee IP. Zigbee IP implementation is plenty small. Alan Dekok: Doing EAP over anything is pretty simple. PANA is, pretty much by definition, more work to implement. Simon Perreault: Authentication of announcements MUST be supported Alistair Woodman: Fixed line operators use RADIUS, mobile operators use DIAMETER. PCP authentication has to work with both. San Hartman: All three proposals do work with both. Yoshihiro Ohba: Carrying EAP over a lower layer is not easy. It needs a transport protocol with a sequence number. Tina Tsou: Would also like to hear from operators about what they want. Alper Yegin: I agree with Yoshihiro Ohba. Carrying EAP over a lower layer is not easy. DHCP tried to carry EAP over DHCP and failed miserably. Stuart Cheshire: Are you saying that DHCP ended up deciding it would have been better to use PANA? Alper Yegin: I didn't say that. Dave Thaler: Show of hands Issue #60: Loosely vs tightly coupled 21 Loosely coupled 0 Tightly coupled Issue #61: Server-Originated Re-Authentication Dave Thaler: Should protocol support server-initiated re-authentication? 10 Yes 5 No Sam to post straw-man solution Issue #62: Retransmissions Answer is not as important as whether we're doing PANA or not. Dave Thaler: Show of hands 12 EAP Direct 6 EAP-in-PANA Dave Thaler: Show of hands (implementers only) 3 EAP Direct 3 EAP-in-PANA Alper Yegin: Why ask what implementers think? PCP Description Option (10, Jaqueline Queiroz) draft-boucadair-pcp-description-option Tiru: This is important work. Reinaldo: This is useful for debugging/testing. Will discuss with AD, because it will require re-chartering. Then call for adoption on the list. Reserving N and N+1 Ports with PCP: Preserving Parity & Contiguity draft-boucadair-pcp-rtp-rtcp (10, Jaqueline Queiroz) Stuart Cheshire: This seems wrong for PCP to take on additional responsibility for the sake of a single legacy protocol Dan Wing: We should ask the SIP WG what they think. Stuart Cheshire: NAT-PMP and IGD don't do this today, so how "essential" can it be? How do even/odd SIP devices work today? Why is it "essential" that PCP give them something new, which they currently manage without? PCP NAT64 Experiments (15, Jaqueline Queiroz) draft-boucadair-pcp-nat64-experiments Jaqueline Queiroz: Do we need to cite RFC 6250? Dave Thaler: As author of 6250, I think no. Radius Extensions for PCP (10, Roberta Maglione) draft-maglione-pcp-radius-ext Paul Selkirk: Have you thought about how you'll represent a list of names in the RADIUS message? Roberta Maglione: It will match how the PCP DHCP option works Using PCP to Update Dynamic DNS draft-deng-pcp-ddns (10, Cathy Zhou) Paul: This is very marginally related to this WG. Stuart: This is important work, that Apple have been working on for a while. Would like more people aware of this, but not PCP-specific. Dave: Suggest socializing this in dnsop. -- END -- Stuart Cheshire