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

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