PCP Working Group Interim Meeting, 16 December 2010 dan wing mohamed boucadair cathy zhou dave thaler francis dupont james paul selkirk simon perreault tina tsou tom taylor yiu lee stuart cheshire benson schliesser jacni qin alain durand lars eggert suzanne woolf dean cheng note taker: paul selkirk agenda bashing #8 pcp discovery methods contention around 3 (iana address) consensus around 1 (configured), 2 (dhcp), 4 (default router) in that order stuart: talking to a pcp server that's not on the path isn't useful in the real world. if you can configure it, you can misconfigure it. dan: with iana address, we can get pcp deployed much faster, without upgrading the entire in-path infrastructure disadvantage of iana - can only discover one stuart: would be more convinced of the advantages of discovering more than one server if i could be sure that my traffic goes to the right nat gateway dan: iana addr lets us get pcp deployed in the simple single-homed case while we work on the more complicated cases nat/pcp is multiple hops away, and default router doesn't understand pcp e.g. nat64 our choice of discovery methods will constrain how we support the nested nat scenario dan: switch 3 and 4 call for consensus on revised order (1 2 4 3) - no objections call for francis or someone to summarize of the problems of multiple default gateways - declare it out of scope? multi-homed server needs to open ports on each gateway/nat, to allow incoming connections from all dave: discovery is orthogonal to the protocol operations support all possible discovery mechanisms, concentrate on the protocol #15 open icmp as side effect behave doesn't offer clear guidance dave: figure out what deployed nats already do pcp wg should defer question to behave #10 firewall support - open a pinhole (to run a server) with no filtering - use pcp to extend lifetime/avoid keepalives, filtering okay what types of filtering should pcp work with? EIF/ADF/APDF consensus to keep the current language in the draft tina: don't need additional opcodes for firewall #17 using pcp to reduce application-level keepalives connect-then-lifetime (use pcp to control an existing nat mapping) alain: lifetime-then-connect is for long-lived connections stuart: where pcp isn't supported, there may be long timeouts for pcp to fail mic: app doesn't know which connections are long-lived or not simon: it's so easy for app developers to get it wrong that we shouldn't recommend it med: leave it to app developer to make the right choice alain: if we have to support connect-then-lifetime, it has an implementation impact on the nat (port pools) francis: support for client side, not server side dan: with connect-then-lifetime, the client can at least query the mapping lifetime, even if the pcp server refuses to extend it. lifetime-then-connect provides a strong hint to the nat alain: connect-then-lifetime requires pcp server to know about all nat mappings #9/16 are pcp-created mappings different from tcp-created ones? stuart's simplicity principles say no alain: pcp server could be in charge of a subset of port space tight coupling makes server implementation more complex francis: real-world nats are not eim/eif dave: that's not said or implied by this slide tina: don't do both pcp and dynamic mapping extension dave: if you know that application packets are keeping the connection alive, then you don't need to use pcp to extend lifetime alain: complexity is outweighed by benefits of rapid deployment connect-then-lifetime, lifetime-then-connect would then act exactly the same dan will update draft to reflect this principle #19 handling unrecognized options do we need to indicate which option was unrecognized? consensus seems to be yes dan will figure out how to encode it #24 pcp mappings same public address as dynamic related to #9/16, so yes #11 flow control mechanism one outstanding request at a time, vs one request per second francis: none of the above, not necessary to constrain client; esp a disaster for upnp-igd iwf just put a rate limiter on the server proposal: for remote addr/port specified, same as tcp syn (no flow control) for acting as a server: bounded by max # of ports not rate dan: worry about avalanche restart problem? this is not specific to pcp, servers will respond at the rate they can stuart: no rate limiting or flow control in nat-pmp implementation, despite what spec may say consensus: remove flow control language #12 icmp error handling and pcp server unreachability proposal: if a pcp server becomes unreachable, try another one (if known) alain: applies within a list from the same source, not fallback to a different discovery mechanism proposal: unreachability determined by timeout, not icmp ie. ignore icmp, or use it as a hint to re-probe sooner no objections #7 round trip time computation proposal: steal mechanism from dns (rfc 1536) retry timer fixed 4 seconds no objections #5 channel security mechanism 1. mandatory or optional 2. encryption or authentication 3. mutual or one-way auth 4. dtls, ipsec, or something else alain: clearly optional francis: optional, no encryption, mutual auth dan: when i send a tcp syn, i don't know what might be on path (nat, firewall, etc); even if i know, i don't know what the filtering characteristics are dave: two scenarios that are different from tcp syn: - open EIF hole - open pinhole for another device dan: sending tcp syn may open an EIF hole, depending on nat/firewall dan: recent research on off-path tcp reset attacks defer further discussion #21 epoch=0 amplification attack mitigation? - channel security - bcp 38 ingress filtering tina: change "immediately" to random delay stuart: this spreads the same attack over a longer period stuart: the bulk of the load on a nat gateway is the nat-and-forward operation, not the mapping setup dave: control plane and data plane are different stuart: trivial mapping lookup may be in hardware as well, but not a big load on the cpu even if done in software proposal: cover ingress filtering in security considerations, but don't worry about mitigating via pcp protocol behavior itself dan: remove "immediately", leave it up to implementation when to request mappings