Minutes for PCP at interim-2012-pcp-2
minutes-interim-2012-pcp-2-1

PCP interim meeting
2012-10-17 10:00-11:30

Attendees:
Dave Thaler
Alain Durand
Alper Yegin
Margaret Wasserman
Subir Das
Tina Tsou
Yoshihiro Ohba
Sam Hartman
Rafa Marin-Lopez
Ralph Droms
Reinaldo Penno
Dacheng Zhang
Stuart Cheshire

- A lot of agenda bashing. Each camp wants to go first.

- Yoshihiro Ohba describes PANA encapsulation draft.
- There are two approaches for PANA: side-by-side and encapsulation.
  - Side-by-side multiplexes PANA/PCP on the same port.
  - Encapsulation approach uses AUTH PCP opcode.

10:25
Comparison of PCP Authentication approaches
Margaret Wasserman
- Two PANA proposals.
- Proposals are more similar than they are different.
  - All proposals use EAP.
- PANA defines three entities: PANA Client, PANA Authentication Agent,
  Enforcement Point
- EP is not to be used with PCP.
Alper: PANA does not mandate liveness tests.
- Authentication and authorization can be loosely or tightly coupled. (slide 8)
Alper: Are there examples of loosely/tightly coupled? All current designs are
tightly coupled.
Sam: SSH into a router, create a hole in the firewall. The hole will extend
beyond the lifetime of the SSH session. Other example: Kerberos certificate ...
(did not understand).
Alper: Lifetime of SSH credentials cannot be shorter than the change you're
making on the firewall.
Margaret: That's not true. Even getting rid of the user does not remove the
firewall changes.
Margaret: Third party use case: make port 80 go to a web server that does not
speak PCP using third-party client. You don't want to tie the mapping lifetime
to the third-party client.
Alper: You're referring to PANA ping?
Margaret: PANA ping and server-initiated have the same effect.
Sam: (did not understand)
Margaret: The question is do we want the mapping lifetime to be tied to the
authentication lifetime?
Dave Thaler: The question is what model do we want? Tightly or loosely coupled,
or both? A protocol could support both and be negotiated per session.
Margaret: (did not understand)
Alper: What would be different for the loosely coupled model?
Margaret: Authentication would only be verified for the act of creating a
mapping. Not for keeping the keeping the mapping alive.
Alper: You would receive two separate timers from the AAA server?
Sam: Not necessarily.
Dave Thaler: PCP is an additional way of doing things. Does not change NAT
implementations.
Alper: AAA server determines lifetime?
Dave Thaler: It can be independent.
(I am missing the point of this discussion now.)
Yoshi: What happens in a loosely coupled system when auth lifetime expires?
Margaret: Authentication procedure is re-done to recreate auth credentials.
Alper: No need to maintain the keys throughout the PCP session?
Margaret: Right.
Dave Thaler: PCP session only lasts for 3 seconds or so.
Alper: PCP is used to maintain mapping state. That's what I call session state.
Margaret: PCP is used to control a firewall or a NAT.
Sam: (did not understand)
Simon: A mapping can be created explicitly (PCP) and then refreshed implicitly
(by traffic) indefinitly.
Alper: How do we know if a client is authorized to modify another client's
mapping?
Sam: Server policy.
Sam: (did not understand)
Yoshi: Any approach can support loosely or tightly coupled model.
(general agreement)
Margaret: We have to specify the coupling model in the document.
(general agreement)

Slide 9: Re-Authentication
- Can authentication be done spontaneously or does it need to wait for a new
  mapping request?
- Unsolicited is necessary in the tightly-coupled model.
Ralph: Is there anything in PCP that is not driven by the client?
Margaret: See next slide.

Slide 10: Operational Model
- PCP is request/response driven by the client with one-way notifications from
  server to client.
Ralph: That makes client implementation much easier.
Margaret: It also supports going to sleep. With implicit refresh, you need to
send keepalives regularly. With PCP you can create longer lifetimes and go to
sleep for much longer. That's one of the big points of PCP and we don't want to
change that with auth.
Alper: PANA doesn't require that.
Margaret: It needs to be documented.
Alper: I thought you were referring to PANA ping.
Sam: There is a problem with it being policy: the client implementation needs to
support all options.
Alper: But the PCP client *has* to stay alive all the time to refresh the
mapping.
(general disagreement)
Sam: How can I make a PCP client and PANA client that are not running all the
time? For example a script that terminates after the request is done.
Dave: Margaret summarized two examples where PCP client is no longer available:
third-party case, and when you're going to sleep (e.g. laptop).

Slide 11: PCP-Specific Model
- Has no "liveness test", no unsolicited messages that require a response.
- Loosely coupled.

Slide 12: PANA Model
- Requires server-initiated reauthentication.
- Optionally to support liveness detection.
- Tightly coupled.
Alper: Retransmissions are driven by EAP. Not PANA's choice.
Sam: No. You can design an EAP lower-layer where retransmissions are done by the
client.
Rafa Marin-Lopez: (did not understand)
Sam: You can remove the reliability in EAP if we choose. Say PCP or PANA is
reponsible for retransmits.
Rafa: You need retransmission.
Sam: Yes but it can be done at either layer: EAP or elsewhere.
Margaret: If we move it to the PCP layer, we can choose to do only
client-initiated retransmission. Retransmissions don't need to be
server-generated.
Alper: You are reinventing ... (did not understand)
Margaret: Send a description of how PANA can do only client-initiated
retransmissions.
Alper: Will do.  <==== ACTION ITEM
Margaret: We should focus on how we would use PANA instead of starting by
encapsulation vs demux.
Dave Thaler: I will setup the issue tracker to help frame the discussion until
Atlanta.  <========== ACTION ITEM
Ralph: Agree on deciding first on whether to use PANA or not.

11:35
END OF MEETING