PCP Working Group Interim Meeting, 8 March 2011

Dan Wing
Dave Thaler
Alain Durand
Francis Dupont
Gang Chen
James Huang
Mohamed Boucadair
Paul Selkirk
Stuart Cheshire
Tina Tsou

Dan: review changes from -05 to -06

Re this change (from A.1):
o tightened up text (which was inaccurate) about how long general
PCP processing is to delay when receiving an error and if it
should honor OpCode-specific error lifetime. Useful for MAP
errors which have an error lifetime. (This all feels awkward to
have only some errors with a lifetime.)

Stuart: Why do some errors have lifetimes and some don't?
Dave: Send the question back out to the mailing list to move lifetime from opcode headers back to the common header, so that even non-opcode errors can have lifetime.

Dave: Are there any open issues that aren't on the tracker?

Stuart: Will want to add an issue about NAT-PMP interop; will want to migrate existing code to PCP, possibly on the same port as NAT-PMP.
Alain: Please send thoughts before we issue -07 on Monday (IETF deadline).

Gang: What is the lifetime of a specific connection vs the mapping lifetime? Can we allow a remote peer to know the mapping lifetime?
Stuart: No need for per-flow state for incoming connections on MAP mappings.

#16: PCP lifetime expiration with active traffic
Dave: Anyone on call think that the NAT should not refresh a mapping as long as traffic is flowing through it?
Francis: Implementation dependent
Stuart: Any time we say "implementation dependent", clients can't know what to expect.
Stuart: PEER is an optional performance improvement, in absence of which old behavior reverts (active mappings are kept open).
[Paul while reviewing notes: PCP didn't create these mappings, so can't delete them on lifetime expiry. It falls back to the NAT to expire these mappings according to its own mechanisms.]
Stuart: Given that you can't get inbound connections by sending TCP SYN, and need to explicitly request a mapping, you need to explicitly renew it. Therefore MAP mappings should expire if not renewed.
Francis: I agree with Stuart for the second time.

#13: DS-lite interaction
Alain: Will ping Reinaldo to send analysis tonight or tomorrow.

#25: Nested NAT support
Alain: Anything in here that will affect the base spec?
Dan: Covered by a separate document.

#26: Firewall detection
Stuart: Firewall detection is hard.
Dan: This is to inform the user that a firewall is filtering packets.
Alain: What can the client do with this knowledge?
Stuart: Nervous about code that tries too hard to detect failures, or even injects artificial failures. Just try the operation, and it will succeed or fail on its own.
Dave: Any objection to closing this as something we're not going to do?
Dan: Will move this to another document, maybe /dev/null.

#32: Interference between 2 clients on same host
Francis: The idea is to have free-form application ID, so you can recognize your mapping if you have two clients on the same devicel
Stuart: Why is the internal port not sufficient to disambiguate?
Dave: The source port of the PCP client is not the same as the source port of the mapping.
Stuart: Hasn't been a problem in 5 years of nat-pmp experience; and a free-form string can be forged.
Dave: Would it be sufficient if the server were to keep track of the source port of the client requestor?
Stuart: App-ID doesn't add anything except extra failure vectors.
Paul: Take this to the list, get a clear problem statement.
Alain: With a time limit for resolution this week, defaulting to re-closing as wontfix.

Francis: Make a statement somewhere that IWF should be stateless.
Dave: There's a separate UPnP-IWF doc, still being worked on, there is time to make changes there.
Stuart: UPnP is not stateless, so UPnP IWF can't be stateless.

#38: state maintenance: create a general failure model, discussing
how to recover from failures
Francis: Client crash-recovery needs GET/GET-NEXT operations to recover mappings.
Stuart: Is this general or UPnP-specific?
Stuart: On reboot, client makes mapping requests, which look like renewals to the server.
Alain: This is the case where the PCP relay crashes.
Stuart: That's what epoch=0 is for, to inform clients.
Dave: But a relay has no way to inform internal clients, so this will heal slowly.
Francis: This is a security problem.
Stuart: Disagree.
Dave: Someone please summarize for the list.
Alain: This seems like an optimization, not a requirement; would like to push this into a separate document.
Francis: Document exists [draft-boucadair-pcp-failure].

#39: mechanism to store disambiguating information at aggregation points
Dave: Seems to be the same issues as #38
Alain: Reclassify this as not base, but recovery.

#19: Handling of unrecognized IEs in request
Dan: Solved with UNPROCESSED response-only option.
Dave: Confirm consensus, close ticket.

#30: GetExternalIP capability?
Scenario: stateless NAT with no active mappings for the client
Dave: Host should request a mapping if it wants to find external address.
Alain: Discuss in IWF document(s).
Stuart: NAT-PMP apps now do two concurrent requests: get-address and get-port; IWF can sit on get-address request until get-port completes.
This is one place where PCP does a better job than NAT-PMP.
Dave: Change ticket component to IWF.

Returning to discussion about lifetime (side effect of #16) Dave to Francis: Are there any error codes that should not have an associated lifetime?
Francis: Anything about a packet that is broken (MALFORMED_REQUEST); the packet will still be broken 30 seconds or 30 minutes later.
Also, by definition, UNSUPP_VERSION means only the first byte of the packet is parsed.
Dave: If you don't know the value, fill in lifetime 0 or MAXINT.
Stuart: In the common case, most messages (success or failure) have a natural lifetime, and only the rare and anomolous cases don't have a natural lifetime.
Francis: Move lifetime to an option for certain errors.
Paul: Error lifetime is a hint to the client; if there are errors for which lifetime doesn't make sense, client will ignore the hint.
Stuart: Not having lifetime in common header potentially saves 4 bytes; having lifetime in common header simplifies parsing.
Dave: Keep ticket open.
Alain: minimum error lifetime=1
Dave: 0=undefined, maxint=never
Stuart: Server has to give its best guess, "never" isn't acceptable.
Dave: 0=never, server has to pick other value if it doesn't know
Francis: Specify that lifetime is unsigned.

Dave: We're out of time, and there are 3 minor issues we didn't talk about, but which I think we can close by Monday. Everyone please review the following tickets:
#31: Query-capability support?
#34: notify NAT WAN address changed
#36: error on renewal for interworking function _______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp