Minutes for PCP at IETF-interim-2010-pcp-1
minutes-interim-2010-pcp-1-00

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