[pcp] PCP MoM (FRIDAY, November 9, 2012)

["Reinaldo Penno (repenno)" <[e-mail]>]

FRI 1120-1330 (note new end time) =================================

Welcome, Agenda bashing                               (5, Chairs)

PCP Authentication Open Issues                        (60)
    draft-ietf-pcp-authentication                     (Margaret Wasserman)
    draft-ohba-pcp-pana                               (Yoshihiro Ohba)
    draft-ohba-pcp-pana-encap

Margaret Wasserman: Alper said that using PANA gives you a simpler PCP
implementation. In reality there are no PANA servers on most networks
today, so
there's more code to be written, supported, and deployed.

Alan Dekok: I agree with Margaret. I've done EAP over multiple protocols,
and
it's not hard. PANA is rather a lot more work.  Alper's statement that
RADIUS
forces server-initiated re-authentication is incorrect.

Alper: COA RFC permits server-initiated re-authentication

San Hartman: Yes, COA RFC permits server-initiated messages, but the
footnote
explains that it's for EAP error reporting, not for re-authentication.
There is
no way for a RADIUS server to force server-initiated re-authentication.

Joe Salowey: EAP authentication can derive keying material. Are we making
use of
the MSK when using EAP directly?

San Hartman: Yes, every packet is integrity-protected.

Alper: When using PANA the keys will be exported for PCP to use. At the
end of
PANA authentication, PANA does a key confirmation.

Joe Salowey: As long as messages are integrity-protected, that's good.

San Hartman: Would like to hear from PCP implementers about what they
want. I
believe re-authentication is harmful and unnecessary. We should choose
whatever
retransmission mechanism is easier for PCP implementers. My opinion is
that EAP
over PCP is by a large margin, easier to specify, implement, and deploy.
Existing PANA implementations are not suitable for use as libraries.
There's a
lot of work to be done to trim out the parts of PANA that PCP doesn't
need. The
IETF has lots of experience defining EAP over lower layers.

Stuart Cheshire: Strongly agree with everything Sam said. As an
implementer, I
prefer the minimal approach of using EAP directly.

Margaret Wasserman: We don't need to push re-authentication down to the
client

Sam: Re-auth is harmful because it requires the client to be awake.

Hannes Tschofenig: Would like to hear from people that have actually
implemented
PANA. Re-authentication is not mandatory. There's no harm in having to
implement
protocol features that are never actually used.

Hannes Tschofenig: People should actually implement what they're proposing.

Yoshihiro Ohba: PANA is adopted by ETSI M2M. One of the open-source PANA
implementations is based on a library, so it's available.

Alper Yegin: The server has to send unsolicited messages to the client, so
it
has to be able to force the client to re-authenticate so that the server
can
send a message to it.

Alper Yegin: PANA is adopted by Zigbee IP. Zigbee IP implementation is
plenty
small.

Alan Dekok: Doing EAP over anything is pretty simple. PANA is, pretty much
by
definition, more work to implement.

Simon Perreault: Authentication of announcements MUST be supported

Alistair Woodman: Fixed line operators use RADIUS, mobile operators use
DIAMETER. PCP authentication has to work with both.

San Hartman: All three proposals do work with both.

Yoshihiro Ohba: Carrying EAP over a lower layer is not easy. It needs a
transport protocol with a sequence number.

Tina Tsou: Would also like to hear from operators about what they want.

Alper Yegin: I agree with Yoshihiro Ohba. Carrying EAP over a lower layer
is not
easy. DHCP tried to carry EAP over DHCP and failed miserably.

Stuart Cheshire: Are you saying that DHCP ended up deciding it would have
been
better to use PANA?

Alper Yegin: I didn't say that.

Dave Thaler: Show of hands

Issue #60: Loosely vs tightly coupled 21 Loosely coupled 0 Tightly coupled

Issue #61: Server-Originated Re-Authentication Dave Thaler: Should protocol
support server-initiated re-authentication?  10 Yes 5 No Sam to post
straw-man
solution

Issue #62: Retransmissions Answer is not as important as whether we're
doing
PANA or not.

Dave Thaler: Show of hands 12 EAP Direct 6 EAP-in-PANA

Dave Thaler: Show of hands (implementers only) 3 EAP Direct 3 EAP-in-PANA

Alper Yegin: Why ask what implementers think?


PCP Description Option                                (10, Jaqueline
Queiroz)
    draft-boucadair-pcp-description-option


Tiru: This is important work.

Reinaldo: This is useful for debugging/testing.

Will discuss with AD, because it will require re-chartering.  Then call for
adoption on the list.

Reserving N and N+1 Ports with PCP: Preserving Parity & Contiguity
draft-boucadair-pcp-rtp-rtcp                          (10, Jaqueline
Queiroz)

Stuart Cheshire: This seems wrong for PCP to take on additional
responsibility
for the sake of a single legacy protocol

Dan Wing: We should ask the SIP WG what they think.

Stuart Cheshire: NAT-PMP and IGD don't do this today, so how "essential"
can it
be? How do even/odd SIP devices work today? Why is it "essential" that PCP
give
them something new, which they currently manage without?


PCP NAT64 Experiments                                 (15, Jaqueline
Queiroz)
    draft-boucadair-pcp-nat64-experiments

Jaqueline Queiroz: Do we need to cite RFC 6250?

Dave Thaler: As author of 6250, I think no.


Radius Extensions for PCP                             (10, Roberta
Maglione)
    draft-maglione-pcp-radius-ext

Paul Selkirk: Have you thought about how you'll represent a list of names
in the
RADIUS message?

Roberta Maglione: It will match how the PCP DHCP option works


Using PCP to Update Dynamic DNS draft-deng-pcp-ddns
(10, Cathy Zhou)

Paul: This is very marginally related to this WG.  Stuart: This is
important
work, that Apple have been working on for a while. Would like more people
aware
of this, but not PCP-specific.  Dave: Suggest socializing this in dnsop.

-- END --