17:40 Note takers, agenda, existing milestones (Chairs, 10) First face to face meeting of the PCP working group Covered by note well Currently no working group items Other drafts with 'pcp' in the name, that we're not talking about today Milestone status Had a virtual interim meeting 10/7 Want to do this monthly between now and Prague Christian: insist on hitting milestone for adoption of base draft Alain: better to get something soon than to get something perfect ================ 17:50 Goals and Desires for PCP (Stuart Cheshire, 15) One protocol or two? Just for big NATs? or replacement for UPnP/NAT-PMP A lot of users are still directly connected to the network We should design one protocol to meet the needs of all use cases NAT or firewall port openings? Control operations may be the same But vulnerabilities and risks may be the opposite Is letting inbound traffic reach a host a good thing or a bad thing? Simplicity Postel paraphrasing St. Exupery Packet isomorphism All operations use the same packet format Request semantics Request/renewal/recover/retrans mean the same thing Reply from the NAT is the same for new/renewed mapping Reply semantics Request/renewal/recover/retrans mean the same thing Reply from the NAT is confirmation or error Unified mapping table Static/dynamic/managed port mappings in the same table Multiple ways of indexing the table ICE equivalence Apps like Skype use ICE and STUN to get through NATs today PCP should work as reliably as dynamic port mappings If we put restrictions on PCP, developers will continue using ICE Marcus: ICE has other uses Wolfgang Beck: Why not UPnP-IGD? Stuart: See NAT-PMP appendix - no lifetime, no collision management Dave: Designed for another use case - managing static port mappings Stuart: Intended for a human user Wolfgang: Why not midcom? Dave: Document somewhere as FAQ (WG wiki page?) Margaret: don't rule out firewall case ================ 18:05 PCP Base Protocol (Dan Wing, 30) draft-wing-pcp-base-01 UDP request/response protocol Same packet layout for request/response Optional extension mechanism Open issues (to be covered) Other open issues ICMP Implicit or explicit pinhole opening Suggest implicit Lars: implicit Simon: another vote for implicit, because that's how NAT64 does it Firewall Support for more than one peer? if so, how many? Andrew McGregor: One remote peer or set of peers, but should allow server connection Dan: That's not a firewall Andrew: Open up to a prefix Francis: We need one-or-any to map UPnP Margaret: Need to enumerate, but not 'any' Dan: Limit in spec, or implementation detail Dave: Agree with Andrew, would like to open a server port. This is still a firewall, because it firewalls all other ports. Lars: Agree with Dave and Andrew, maybe with Margaret; PCP should be able to talk to either NAT or firewall Alain: we don't have a lot of time to spend on this PCP lifetime Expire at end of lifetime Keep alive if active outbound traffic Keep alive if active bidirectional traffic Alain: Value of lifetime is not to have to do app-layer keepalive argument for #1 (expire even if active) Stuart: if you accept that all mappings are the same, this is simple active traffic on a dynamic port mapping automatically renews mappings Dave: that's a property of the NAT, not a property of PCP Lars: benefits come from long lifetimes Dave: and ability to discover lifetime Lars: may expire but not must Alain: this is implementation dependent Stuart: firewall and NAT answers may be different Tina Tsou: need mechanism for PCP server to know who all its clients are, so it can e.g. notify them of status Stuart: NAT gateway does know the list of clients, don't know why server might want to contact them Francis: in favor of #1 Multi-homing Make sure protocol is designed so we can add it later Margaret: document currently says this is out of scope third choice - in scope to allow two gw to open pinholes for the same app 'defer' could mean 'dont care' rather not define a protocol that can't find two servers Alain: Is this something that we need in the base spec, or something that can go in an extension later? Stuart: To the extent that you can find the path a TCP SYN takes, you can figure out which PCP server to request from Requesting multiple ports RTP only? likes even/odd ports Proposed - IE called EVEN_PLUS_ONE Alain: asked how important this is Current apps can use other than even/odd PCP server discovery: DHCP option IANA-registered IP anycast address default router Tina: What about nested NATs (NAT444) Dan: Can use multiple mechanisms, e.g. default router in the home, DHCP for LSN Stuart: Haven't implemented, but should work, we think we know how to do it Dave: #1 (default routers), and 3 (DHCP) can find multiple PCP speakers Margaret: Consider 'and' not 'or' Dan: Important for incremental deployment Dave: Draft currently has all 3 mechanisms, WG needs to decide what to work on ================ 18:35 Chair Perspective on Contentious Open Issues (Alain Durand, 20) Those were the non-contentious issues, now the contentious ones. Dave: that was the 'meat' part of the meeting, this is the 'fresh meat' part 1. Epoch Small NAT vs big NAT - stateless vs stateful Useful, but do we want to keep it in the main protocol header, or as IE? Andrew: Even if you think server has stable storage, it may not. No reason to turn this mechanism off, why not make it a must? Stuart: Counter-argument (that I don't buy) is that putting a timestamp in the packet is hard 2. Transaction ID We already have a 48-bit transaction ID (internal addr + port) Proposed to reject Francis: argument is wrong in the case of DS-lite Stuart: What would ICE do? Outbound TCP SYN somehow manages to make a port mapping without a transaction ID Margaret: There's no answer to an outbound SYN haven't talked about flow control, flood restart until we talk about that, don't know if we need transaction ID Stuart: Simplicity in reporting a port mapping exists, without regard to how a mapping was created 3. mandatory Bit, or some other semantic Generic global mandatory semantic only useful for UPnP-IGD case UPnP-IGD can work without it, but puts load on server Francis: some people on list believe this is not useful Stuart: NAT-PMP has been around for 5 years without mandatory bit apps can't assume they can get the port they want apps that are written that way are broken abandon the idea of well-known ports modeled on DHCp - request a port, but may get something else Alain: This is something we can do in the UPnP relay, but find a better name Stuart: If we put this in the spec, people will use it Dave: Putting it in IE allows us to deprecate it later ================ 18:55 Security Model (Paul Selkirk, 15) Mailing list thread "PCP Security Model" PCP Security Considerations Stuart Cheshire: You talked about the "Duelling Xboxes scenario", and said that "Dad" has to be the authority figure to resolve disputes. This scenario doesn't make sense, because what happens is very simple: Both Xboxes ask for mappings, and both Xboxes get mappings -- for *different* external ports. The only way they would be duelling is if they both had software written to deliberately put a fraudulent IP address in the packet, and it's hard to see why Microsoft would do that. In normal operation they put their correct source IP addresses in the packet, and those source IP addresses are different because they have different IP addresses, so they can't interfere with each other's mappings. Andrew McGreggor: The Duelling Xboxes scenario is a good argument against the Mandatory bit. Wolfgang Beck: Is spoofing responses a threat we should be concerned about? Paul Selkirk: Any kind of spoofing is bad. Wolfgang Beck: If we're worried about spoofed responses, a transaction ID could help determine which responses are true and which are spoofs. Dan Wing: If we use well-known anycast address, and ISP runs no PCP server (or no NAT at all), the request packet can make it out into the Internet at large, outside the control of the ISP. This increases the vulnerability to spoofing. Dave Thaler: This is part of the discussion of different PCP server discovery mechanisms. ================ 19:10 Subscriber Identification (Jiang Dong, 15) draft-cui-pcp-subscriber-identification-00 If ingress filtering is weak (prefix based, not host based), attacker can spoof requests Proposed Authen IE 1. routability test based on random number or hash of addr, port 2. user name and password 3. digital signature Proposed - secure channel Dave: Question to WG... Is this a problem we need to solve in the PCP protocol itself, or in the transport under PCP? Alain: When we send a TCP SYN, we don't do any of that; If we want security, we use IPsec Roberta: Username/password is not a good solution in DS-lite Margaret: We want security in the protocol. Just being able to reach the server is not sufficient. Want to do security at a more granular level, based on authentication. Andrew: Strongly recommend not doing a security solution in the protocol; use transport-level security if needed Stuart: We won't get this done quickly My skype client works in the hotel without a user name and password Lars: The quicker and simpler option is to secure the channel. Attacks are not horrible, no catastrophic failure Margaret: Cutting corners in creating the working group Cutting corners in creating the protocol If ICE is good enough, keep doing ICE until we can get it right Dave: Rough consensus to concentrate on securing the channel vs. adding security to the protocol ================ Chair's question: adopt draft-wing-pcp-base is a reasonable starting point? 25 in favor, 0 against ================ 19:25 IE usage for extensibility (Christian Jacquenet, 15) draft-wing-pcp-base-01 section 5.3 Why should PCP be extensible? Base should be simple We don't understand all the use cases Extensibility mechanisms New opcodes Informational elements 1. How to notify the client that an ie is not supported by the server? implicit or explicit Dan: Implicit Margaret: Is there a way to convey what to do if server doesn't understand an IE? Dave: Bits in the IE header 2. Allow server to send unsolicited IE to the client? Dave: You don't know if the client is going to support it, so it may be extra useless bits on the wire Margaret: Specification impact - you have to specify what the client should do if it doesn't understand Dave: This is around around adding data to a reply that's already going out, not to sending an unsolicited reply Dave: If you follow Stuart's simplicity principle, is there a valid use case for this? Andrew: Firewall has a QoS policy and wants to tell you what it is Dan: "694". WG doesn't understand. Dan: See? No point to giving a response that won't be understood. 3. mandatory-to-be-honored Dave: If I understand the opcode, I understand how to act on it Alain: There are multiple cases that can't be handled by one bit ================ Will schedule WebEx interim meeting approximately second week of December.