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

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 26 Nov 2012 14:36:10 +0000

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 --

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Nov 2012 19:54:45 +0200

Hi Alan,

> it's not hard.

> PANA is rather a lot more work.  

Because? (Just don't be saying IP-Reconfig, and Ping -- which counts for 50-60 lines of PANA code. And not the re-auth either, as lack of that makes people jump lot of hoops and does not even give you a secure solution at the end, see Sam's attempt).

> definition, more work to implement.

Can you expand on this?

Alper

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Nov 2012 13:06:52 -0500

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

I don't know what Alan's specific issues are, but  I expanded on this a
fair bit in  my implementation analysis mail.
I think the simplest way to look at implementation issues like this is
to actually look at implementations.

You described the points I brought up as relatively easy to resolve. I
disagree with that assertion.

Similarly Reinaldo brought up a number of his implementation
concerns. You again described them as relatively trivial, although
Reinaldo and I disagreed.

Alan did not go into specifics.

Ultimately it doesn't matter. The IETF does not come to consensus on
implementation issues. We do consider them in deciding between
options. It's useful for people to provide details so others can judge
the credibility of the claims they are making.
However, we come to consensus on approach for the standard, not on
specific issues like implementation complexity.

Perhaps Alan will provide details. I suspect you won't agree with
whatever he says.
We're basically going to be left with myself, Alan, Margaret, Reinaldo and Stuart
believing that there are implementation challenges with PANA greater
than with a PCP lower layer.
You, Yoshi and perhaps others disagree.
Each member of the group can  consider all the opinions expressed  when
coming to their opinion about what approach we should choose.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Nov 2012 20:28:16 +0200

Well, claims are interesting to hear,  but not as much as hearing the technical facts behind them.
Making umbrella statements like "I disagreed" without giving any technical reasons is not helpful at all. 

Obviously, this discussion style is not productive. Arguing back and forth without someone driving the discussion forward is such a waste of time, for everyone.

I, once again, calling the chairs to more actively drive the discussion forward. Either they can do it, or they designate a neutral party to summarize the discussions towards making decisions. Honestly, this excessive amount of back-and-forth on discussion points without someone putting an end to it is wasteful.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Nov 2012 21:18:11 +0200

Alan,

I don't remember anyone saying "implementing PANA is trivial".
The only claims on the table are like the ones from you. Unsubstantiated.

Your data below is less than useful.

Why? Because first of all, we are comparing a multi-vendor implemented interoperating IETF standard RFC with some uncooked solution. 
Those numbers could make some sense, if any, when we have EAP-o-PCP solution at the same level of maturity. 

Besides, when providing such numbers you really need to be more scientific and provide lot of background. Otherwise, I gotta tell you, they look way too unrealistic and scary…..

Alper

On Nov 27, 2012, at 8:50 PM, Alan DeKok wrote:

> Alper Yegin wrote:
>> Because?
>  Experience?
>  And reading the PANA specs... there's rather a lot more there than
> just encapsulating EAP into another transport layer.  RFC 5191 has about
> 40 pages of requirements, state machine, protocol encoding, etc.
> 
>  I find it astonishing that anyone would claim that implementing PANA
> is trivial.  It would take anyone a fair bit of time to read the RFCs
> and implement PANA.
> 
>  As proof, I've looked at both OpenPANA and cpana.  The "sloccount"
> code metric tool says:
> 
> Openpana:
> Total Physical Source Lines of Code (SLOC)                = 6,912
> Total Estimated Cost to Develop                           = $ 205,696
> 
> Cpana:
> Total Physical Source Lines of Code (SLOC)                = 16,397
> Total Estimated Cost to Develop                           = $ 509,500
> 
>  Which fits in with my earlier estimate.  That's just the PANA portion,
> and doesn't include any EAP methods.
> 
>  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Nov 2012 16:12:18 -0500

> I don't remember anyone saying "implementing PANA is trivial".

  You keep saying things like "it's only 50 lines of code".  That meets
the definition of "trivial".

  I showed that a PANA implementation is more like 10K lines of code.
And neither CPANA and OpenPANA are suitable for use as a library in a
production environment.  So the current available information shows it's
not "trivial".

> The only claims on the table are like the ones from you. Unsubstantiated.

  Only if "unsubstantiated" means "supported by data".

> Your data below is less than useful.

  Nonsense.

> Why? Because first of all, we are comparing a multi-vendor implemented interoperating IETF standard RFC with some uncooked solution. 

  "We" are doing no such thing.  I was trying to discuss the cost of a
PANA solution (code, time, $$) using publicly available data.  You're
ignoring that data.  Instead, you're using proprietary (i.e. secret)
vendor data to support your position.  But you aren't sharing that data
with us.

  Are we supposed to believe you simply because you say you're right?
That fits the dictionary definition of "unsubstantiated".

> Those numbers could make some sense, if any, when we have EAP-o-PCP solution at the same level of maturity. 

  Again, I have facts.  As I said earlier, and as you well know from the
discussions at the time, I have implemented EAP over other transport
layers:

$ git diff eapodhcp master | wc -l
     462

  That is ~500 LoC to implement EAP using DHCP as a transport layer, via
an existing DHCP server.  That code is *just* transport.  All of the EAP
work is done by the wpa_supplicant EAP library.

  That's hard data.  Any PCP implementation can be extended to transport
EAP with (ballpark) 500 lines of code.

  In contrast, PANA requires fixing the open source PANA
implementations, with some unknown amount of effort.  Or, it requires
integration with proprietary vendor implementations, with some unknown
amount of effort.

  Again, I have data, and you have unsubstantiated assertions.

> Besides, when providing such numbers you really need to be more scientific and provide lot of background. Otherwise, I gotta tell you, they look way too unrealistic and scary…..

  Well... I'm a published nuclear physicist.  I think I have some
comprehension of scientific methods.  Bald claims of "more scientific"
and "provide more background" are meaningless.  In addition, you've
imposed arbitrary requirements on me, but avoided them yourself.

  I can play the same destructive game.  You have provided no background
for your claims of inter-operable implementations of PANA.  I'm willing
to agree that they exist, but you've provided no data about their
complexity, cost of development, or cost of integration.  By your own
rules, your position is unsubstantiated by any data, and you need to
provide more background.

  The only facts under discussion right now are the ones I have given.
They are based on publicly available data, which can be independently
verified by anyone.  That is following the scientific method.

  I welcome public data to support your position.  Until then, your
position is based on appeals to authority, and zero data.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Nov 2012 18:23:57 -0500

I agree with Alan's rough data.
EAP over GSS-API is somewhat larger than Alan's EAP over DHCP, although
I made no effort to trim out GSS bits unrelated to EAP from the data I
reported.
However it's definitely smaller than both open-source PANA
implementations.

In addition, once you have a production ready PANA implementation, you
still need to write the glue between PANA and EAP.  If you have a PANA
library and if a couple other assumptions are true, that might actually
be relatively easy.
If you have a non-library PANA and need an IPC mechanism, that's likely
to be moderately  complex probably on the same order of complexity as an
EAP lower layer for PCP.

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Nov 2012 12:08:27 +0900

Alan,

Where is the EAP over DHCP specification that is implemented by you 
available?
How the specification satisfies EAP lower-layer requirements? Who 
reviewed the specification?  More information about the target protocol 
would be appreciated  because it would make sense to discuss code size 
of a particular implemetation of a particular protocol only if everyone 
agrees that the protocol itself is properly designed.

Regards,
Yoshihiro Ohba

(2012/11/28 6:12), Alan DeKok wrote:
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Nov 2012 23:17:11 -0500

> Where is the EAP over DHCP specification that is implemented by you

  The last code I published is at:

	http://git.freeradius.org/eapodhcp.html

> agrees that the protocol itself is properly designed.

  Happily, we don't have to.  As an implementor, Sam said his code was
close, but a bit bigger than my numbers.  So we have (again) more
confirmation that I'm in the right ballpark.  I'm sure Sam could product
detailed numbers, if he wants.

  I welcome similar numbers from anyone else.

  And independent of numbers, anyone *still* has to convince me that EAP
over PCP is more complex than EAP over PANA over PCP.  Simple logic
tells me that cannot possibly be true.

  Alan DeKok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Nov 2012 13:56:21 +0900

Alan,

I appreciate your attempt to share more information with us.

As you may know, you implemented the protocol 
(http://tools.ietf.org/html/draft-pruss-dhcp-auth-dsl-07) on which IETF 
did not reach consensus in 2010 to work on it, after a lengthy debate in 
both DHC WG and Intarea.  Since I really don't think the protocol is 
properly designed (that is why it got a push-back),  usefulfuness of the 
provided code size data on the protocol in the context of evaluating PCP 
authentication proposals is limited IMO.  I believe a proper EAP 
transport design over UDP will look like PANA or IKEv2.

Best Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Nov 2012 14:39:36 +0900

Detailed cpana code size data is available at:
http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/MitsuruKanda.pdf

Regards,
Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Nov 2012 10:16:48 +0200

Alan,

Now I understand why you are under the wrong impression about PANA.
You are benchmarking it against EAPoDHCP, a protocol work that was half-cooked and broken when it was rejected by IETF. 
Sure it'd have less number of lines…. I'm not surprised at all. 

Well, anyways, if you think some parts of PANA are not needed, let's discuss that. We did discuss and agree on the PANA-Ping and IP-Reconfig features, which did not have much impact on code size anyways. Re-auth is proving to be necessary, so it's not something that can be yanked out. 

See below.

> the definition of "trivial".

You must have misunderstood. The whole PANA implementation is not 50 lines of code.
I clearly stated that the agreed extra parts (ping and ip reconfig) are 50-60 lines of code.

> vendor data to support your position.  But you aren't sharing that data

What data are you referring to? 50-60 lines of code is based on the open source implementations.

> EAP with (ballpark) 500 lines of code.

EAPoDHCP is such a wrong benchmark. It's broken, it does not work, it's incomplete, just a draft……. 

> for your claims of inter-operable implementations of PANA.  

PANA is in Zigbee IP spec, and it went thru multiple interop events before the Zigbee IP spec is published.

> I'm willing

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Nov 2012 10:29:29 +0200

> tells me that cannot possibly be true.

For PCP implementors, EAPoPCP is more complex than PANA over PCP because they'd have to be building an EAP lower layer out of PCP. Having PANA in between would shield them from such details. Authentication gets offloaded to PANA. 

This is true even if you consider an implementor who implements only PCP in his life.

If you consider an implementor (a person, team, or company) who needs to deal with multiple platforms, having to deal with EAPoFoo, EAPoBar, EAPoWhatever is more complex than dealing with PANA. Same concern for IETF for its design and standardization effort…. Why replicate the work, when we can reuse existing standards. 

If you consider design architects who also need to deal with an array of protocols, once again dealing with single authentication protocol is much simpler than dealing with N protocols.

(Aren't these obvious to anyone who has at least some IETF experience anyways??) 

Alper

---

From: Alan DeKok <[email-masked]>
Date: Wed, 28 Nov 2012 09:38:27 -0500

Yoshihiro Ohba wrote:
> authentication proposals is limited IMO.

  Which is why I already said that Sam's numbers are more important.

  He said it was more than 500, but much less than 10K LoC.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Nov 2012 09:19:15 -0500

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> Alan, I appreciate your attempt to share more information
    Yoshihiro> with us.

    Yoshihiro> As you may know, you implemented the protocol
    Yoshihiro> (http://tools.ietf.org/html/draft-pruss-dhcp-auth-dsl-07)
    Yoshihiro> on which IETF did not reach consensus in 2010 to work on
    Yoshihiro> it, after a lengthy debate in both DHC WG and Intarea.
    Yoshihiro> Since I really don't think the protocol is properly
    Yoshihiro> designed (that is why it got a push-back), usefulfuness
    Yoshihiro> of the provided code size data on the protocol in the
    Yoshihiro> context of evaluating PCP authentication proposals is
    Yoshihiro> limited IMO.  I believe a proper EAP transport design
    Yoshihiro> over UDP will look like PANA or IKEv2.

The EAP implementation in strongswan's charon (an ikev2 daemon) appears
to be around 1200 lines.
However, charon does not use a third party  EAP library, so I'm having a
bit of trouble pulling apart what counts as  the EAP layer from what
counts as the EAP lower layer.

The EAP lower layer part may be as small as 800 lines of code.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Wed, 28 Nov 2012 09:53:14 -0500

Alper Yegin wrote:
> You are benchmarking it against EAPoDHCP,

  Only if you ignore my repeated benchmarks of PANA implementations.

> Well, anyways, if you think some parts of PANA are not needed, let's discuss that. We did discuss and agree on the PANA-Ping and IP-Reconfig features, which did not have much impact on code size an…

  I've skimmed the PANA docs, and I think it's way too complicated for
just EAP transport.  I fail to see why PANA is necessary for UDP, but
much simpler EAP state machines work for EAPoL.  From what I can tell,
there are *extra* requirements in PANA that are not needed when an
application needs to carry authentication data.

> I clearly stated that the agreed extra parts (ping and ip reconfig) are 50-60 lines of code.

  I did see that.  You're presuming that PANA is already being used, and
treating it as zero cost.  I'm trying (desperately) to talk about the
cost of PANA.

> What data are you referring to? 50-60 lines of code is based on the open source implementations.

  I guess your references to VENDOR IMPLEMENTATIONS and my note that you
had no DATA ABOUT THOSE IMPLEMENTATIONS went unnoticed.

> EAPoDHCP is such a wrong benchmark. It's broken, it does not work, it's incomplete, just a draft……. 

  It's real data.  Unlike your VENDOR IMPLEMENTATIONS, for which you
HAVE NO DATA.

  You are ignoring my next sentence:

>> I'm willing to agree that they exist,

  You're looking at half of the data, and drawing false conclusions.
That's not a scientific process.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 28 Nov 2012 10:01:30 -0500

> If you consider an implementor (a person, team, or company) who needs to deal with multiple platforms, having to deal with EAPoFoo, EAPoBar, EAPoWhatever is more complex than dealing with PANA. Sam…

  So far, we have the following non-standardized EAP transports:

    DHCP    (EAPoDHCP)
    PCP     (Sam)
    GSS-API (moonshot)

  The implementors seem to be fine with this cost.  They seem to think
that ~1K LoC for EAP integration is fine.  The alternative is some
unknown amount of code for PANA integration.

  Do you have numbers for the cost (LoC) to integrate PANA with a
pre-existing application?  As the PANA guy, I'm presuming you have such
numbers at your fingertips.

  Is it less than 1K LoC?  Does PANA solve issues which are not
addressed in a simple EAP transport layer?  If so, which issues?

  Please explain.

  Alan DeKok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Nov 2012 00:44:46 +0900

Alan,

Sam's implementation data is about GSS-EAP which is totally different 
from the EAP over PCP proposal.   Therefore, I don't consider the data 
to be a fair basis for the ongoing debate on PCP authentication 
proposals.  GSS-EAP code size can be smaller than PANA because GSS-EAP 
relies on reliabilty provided by application.  I suspect  reliabilty 
part is excluded from the code size count.  If this is the case, using 
GSS-EAP code size won't be a fair comparison.

Similarly, EAP over DHCP does not provide orderly delivery of EAP 
message (so it does not satisfy EAP lower-layer requirements), and using 
EAP over DHCP code size won't be a fair comparison either.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Nov 2012 09:53:57 +0900

Sam,

Thank you for sending data for strongswan's charon keying daemon about 
IKEv2 which I consider a proper designed EAP transport.  If your count 
excludes reliability function part of IKEv2, then I would claim that it 
is still not a fair basis for evaluating PCP authentication proposals.  
In this debate, I believe we can only make a meaningful apple-to-apple 
comparison by evaluating PANA and  EAP-over-PCP implementations.  What 
is missing is statistics on EAP over PCP implementation which does not 
seem to exist.

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Nov 2012 20:01:53 -0500

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> Sam, Thank you for sending data for strongswan's charon
    Yoshihiro> keying daemon about IKEv2 which I consider a proper
    Yoshihiro> designed EAP transport.  If your count excludes
    Yoshihiro> reliability function part of IKEv2, then I would claim
    Yoshihiro> that it is still not a fair basis for evaluating PCP
    Yoshihiro> authentication proposals.  In this debate, I believe we
    Yoshihiro> can only make a meaningful apple-to-apple comparison by
    Yoshihiro> evaluating PANA and EAP-over-PCP implementations.  What
    Yoshihiro> is missing is statistics on EAP over PCP implementation
    Yoshihiro> which does not seem to exist.

I understand your position.
I don't actually expect that either you or Alper are particularly likely
to be convinced that a PCP lower layer is the right approach.
I expect you to continue to believe that PANA  is the right approach.

Also, as I mentioned early, we're not trying to come to consensus on
questions related to what's easy to implement.

I actually suspect that most of the PCP implementors can take the data
Alan, you and I have provided and come to their conclusions.
If any of them speak up asking for more help I'll jump back into the
discussion.

I agree with Alper that a lot of back and forth isn't going to help. So,
unless someone explains how continuing this discussion is going to help
them make up their mind, I think we've done what we can here.  I am
really happy to go on if it is actually likely to change someone's mind,
but I think it's fair to the rest of the WG to ask people to speak up
and say "yeah, please keep the mail coming; here's how this could help
me."

--Sam

---

From: <[email-masked]>
Date: Thu, 29 Nov 2012 08:17:33 +0100

Dear all, 

Below some answers for the questions raised for this draft. 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Reinaldo Penno (repenno)
>Envoyé : lundi 26 novembre 2012 15:36
>À : [email-masked]
>Objet : [pcp] PCP MoM (FRIDAY, November 9, 2012)
>

Med: The procedure is not specific to SIP/SDP, it is even valid for non-sdp protocols. Are you suggesting we send a message to mmusic WG for instance? 

>be?

Med: Is this really a reason to not do it for PCP? 

 How do even/odd SIP devices work today? Why is it 
>"essential" that PCP

Med: What we are proposing in this draft is very very simple. If this option is not supported, we will continue with current practices (which have many drawbacks):

* enable an ALG in the NAT (I'm more concerned about the CGN case)
* or enabled some mechanism in the service side (e.g., SBC, Proxy Server)

The proposed PCP option allows 

* to remove any service-specific ALG handling RTP/RTCP traversal from the CGN/NAT
* Simplify the service access point (e.g., SBC): no need for hosted nat traversal
* For the SIP case, there is even no need to use symmetric SIP, Symmetric RTP, etc. 
* No issue with unidirectional media sessions

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 29 Nov 2012 10:05:25 +0100

Hi Alan:

I really appreciate this analysis. In particular, I am interested in the results about OpenPANA. Performing:

sloccount state_machines/ include.h lalarm.* maincliente.* mainservidor.* panamessages.* prf_plus.* panautils.*

Total Physical Source Lines of Code (SLOC)                = 3,687

If I include some xml processing (our implementation get config file information from XML but others can implement it differently) I got: 

sloccount state_machines/ include.h lalarm.* maincliente.* mainservidor.* panamessages.* prf_plus.* panautils.* loadconfig.*

Total Physical Source Lines of Code (SLOC)                = 4,203

I excluded aes.c aes.h cmac.c and cmac.h since they are not part of the standard.

It is worthing noting that the pana state machine implementation of both PaC and PAA implies:

sloccount state_machines/

Total Physical Source Lines of Code (SLOC)                = 1,660

Furthermore I would like to include some information about panatiki which is a PANA Client (PaC) for constrained devices that we have implemented.

sloccount pana-state-machine/ pac.c ahi_aes.h include.h

Total Physical Source Lines of Code (SLOC)                = 741

Not sure if you run this command in the openpana.0.2.3.tar.gz (which also implements PANA Relay, which is a different standard) or in the trunk of openpana svn.

I obtained similar data as yours if libeapstack is included (EAP methods and EAP state machine) but you said you didn't include them. So I am trying to replicate your analysis but I have not been able to do it. I really appreciate if you send me the command you performed and where.

Thanks!

>> Total Estimated Cost to Develop                           = $ 509,500

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 29 Nov 2012 20:36:30 +0900

Hi,

I've confirmed the result of "sloccount" to "cpana (libcpana)"
which is a library implementation for PANA itself. I've got the
same result as described in the mail by using the latest cpana's
source code (revision 10).

 > Total Estimated Cost to Develop                           = $ 509,500

However, "cpana" has not only C language source files but also
shell scripts which are generated in build process. Here is the
result of "sloccount" with "--details" option to "cpana."

----
  [$sloccount --details cpana]
  11      makefile        cpana   Makefile.am
  32      ansic   cpana   avpcommon.c
  747     ansic   cpana   ses.c
  74      ansic   cpana   strlcat.c
  97      ansic   cpana   log.c
  357     ansic   cpana   auth.c
  89      ansic   cpana   avp.c
  416     ansic   cpana   ioinet6.c
  932     ansic   cpana   pac.c
  70      ansic   cpana   seq.c
  70      ansic   cpana   ctx.c
  882     ansic   cpana   paa.c
  390     ansic   cpana   evsimple.c
  36      ansic   cpana   debug.c
  84      ansic   cpana   msg.c
  193     ansic   cpana   hash.c
  53      ansic   cpana   ev.c
  281     ansic   cpana   msgsend.c
  6       ansic   cpana   init.c
  119     ansic   cpana   io.c
  419     ansic   cpana   ioinet.c
  145     ansic   cpana   msgparse.c
  16      ansic   cpana   memdup.c
  33      ansic   cpana   avpeap.c
  17      ansic   cpana   rand.c
  117     ansic   cpana   ses.h
  16      ansic   cpana   cpana.h
  45      ansic   cpana   postconfig.h
  95      ansic   cpana   ctx.h
  56      ansic   cpana   io.h
  47      ansic   cpana   ev.h
  6       ansic   cpana   util.h
  61      ansic   cpana   types.h
  29      ansic   cpana   constants.h
  43      ansic   cpana   msg.h
  45      ansic   cpana   preconfig.h
  6       ansic   cpana   debug.h
  56      ansic   cpana   ses_p.h
  18      ansic   cpana   log.h
  14      ansic   cpana   hash.h
  38      ansic   cpana   avp.h
  10      ansic   cpana   functions.h
  344     sh      cpana   install-sh
  1542    sh      cpana   config.sub
  407     sh      cpana   depcomp
  1232    sh      cpana   config.guess
  6331    sh      cpana   ltmain.sh
  281     sh      cpana   missing
----

Then, I extracted only C source files from "cpana" and
categorized them into "PaC part", "PAA part", and "others."

Here are results of "sloccount" to them.

----

  [only PaC part]
  Total Physical Source Lines of Code (SLOC)                = 3,350
  Total Estimated Cost to Develop                           = $ 96,148

"PaC part" includes:

  auth.c       avpeap.c  constants.h  ctx.h  msgparse.c  rand.c  ses.h
  avp.c        avp.h     cpana.h      msg.c  msgsend.c   seq.c   ses_p.h
  avpcommon.c  config.h  ctx.c        msg.h  pac.c       ses.c   types.h

  ----

  [only PAA part]
  Total Physical Source Lines of Code (SLOC)                = 3,283
  Total Estimated Cost to Develop                           = $ 94,130

"PAA part" includes:
  auth.c       avpeap.c  constants.h  ctx.h  msgparse.c  seq.c  ses_p.h
  avp.c        avp.h     cpana.h      msg.c  msgsend.c   ses.c  types.h
  avpcommon.c  config.h  ctx.c        msg.h  paa.c       ses.h

  ----

  [others]
  Total Physical Source Lines of Code (SLOC)                = 2,121
  Total Estimated Cost to Develop                           = $ 59,499

"others" includes:
  config.h  ev.h         hash.h  ioinet6.c  memdup.c      strlcat.c
  debug.c   evsimple.c   init.c  ioinet.c   postconfig.h  util.h
  debug.h   functions.h  io.c    log.c      preconfig.h
  ev.c      hash.c       io.h    log.h      rand.c

----

Best,
Yasuyuki Tanaka

---

From: Tom Taylor <[email-masked]>
Date: Thu, 29 Nov 2012 09:39:18 -0500

I could add that back when we did the MIDCOM work, we included this 
capability in the MIDCOM semantics. For instance, see section 2.3.5 of 
RFC 5198. It seemed like an obvious requirement at the time, because 
VoIP was a major driver for a lot of what was going on.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Nov 2012 10:38:48 -0500

So... you're not going to provide data to support your position, and
neither is Alper.

  I see no reason to continue this conversation, because it's not a
conversation.  You're asking me to meet certain criteria, while refusing
to meet them yourself.

  Alan DeKok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Nov 2012 00:54:42 +0900

Both openpana and cpana data have been provided.

Yoshhiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Nov 2012 11:20:26 -0500

> Both openpana and cpana data have been provided.

  By which you mean *I* provided the data.

  Alper and you still haven't provided:

a) the cost of proprietary vendor PANA implementations

b) the cost of integrating those with an application

c) the cost of integrating cpana or openpana with PCP

  Sam and I have both provided data around the cost of implementing PANA
(cpana && openpana), the cost of integrating EAP with another protocol
for transport (EAPoDHCP, Moonshot, EAP-IKEv2).  Sam has alluded to the
cost of integrating EAP with PCP (a bit over 500 LoC).

  All you've done is poke holes in other peoples arguments.

  You have supplied *absolutely no data* to support your position.

  Until you support your position, I think it's safe to say there is
absolutely no reason to use PANA.  Demanding that PCP use PANA based
only on your say-so is not productive.

  Alan DeKok.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 29 Nov 2012 18:18:26 +0100

Hi Alan

Didn't you receive my previous e-mail to the PCP ML about OpenPANA data? I think the data I sent about OpenPANA are the correct ones. I were not able to replicate your data about OpenPANA. 
Please check my e-mail in the link. I would really appreciate it.

http://www.ietf.org/mail-archive/web/pcp/current/msg02631.html

Best regards.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Nov 2012 16:26:04 -0500

Rafa Marin Lopez wrote:
> Didn't you receive my previous e-mail to the PCP ML about OpenPANA data?

  Yes.  The data is similar enough to what I posted earlier, that I
don't see it as changing any of my conclusions.

  Alan DeKok.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Nov 2012 15:41:54 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, November 28, 2012 11:18 PM
> To: Reinaldo Penno (repenno); [email-masked]
> Subject: [pcp] PCP for RTP/RTCP (was RE: PCP MoM (FRIDAY, November 9,
> 2012))
> 
> Dear all,
> 
> >De : [email-masked] [mailto:[email-masked]] De la part de
> >Reinaldo Penno (repenno) Envoyé : lundi 26 novembre 2012 15:36 À :
> >[email-masked] Objet : [pcp] PCP MoM (FRIDAY, November 9, 2012)
> >
> >responsibility for the sake of a single legacy protocol
> >
> Med: The procedure is not specific to SIP/SDP, it is even valid for non-
> sdp protocols. Are you suggesting we send a message to mmusic WG for
> instance?

The port adjacency is (was) a need of RTP (RFC1889, RFC3550) which
is now owned by AVTCORE.  

A survey of endpoints that support a=rtcp (RFC3605) or send their RTP
and RTCP over the same port (as being pursued by RTCWEB) would be
valuable.  The question comes down to:  does the industry still need
port adjacency, or by the time PCP standardizes this functionality
and it gets deployed will it be relevant any more?  It will take a
couple of years.

> Med: Is this really a reason to not do it for PCP?

It does demonstrate that there seems little _requirement_ for
this functionality - or else it would have been implemented
or been a must-have requirement.  That is, there are some sort
of workaround/workarounds the industry is currently using today.

> Med: What we are proposing in this draft is very very simple.
>
> If this
> option is not supported, we will continue with current practices (which
> have many drawbacks):
> 

Would SBCs be de-installed if this feature is added to PCP?

> * No issue with unidirectional media sessions

Those benefits are beyond what was presented at the PCP meeting.  They
are pretty interesting / valuable.

Can the SIP and/or AVTCORE working groups help convince PCP that this
is necessary / helpful / useful?

-d

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 30 Nov 2012 00:41:54 +0100

Hi Alan,

Maybe I am missing something, but the lines you posted (6,912) are around twice the lines I provided (3,687) (apart from other data such as the 741 lines for a PaC in constrained devices). Not sure how they are similar.

Thanks for your time.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Nov 2012 08:54:18 +0900

Alan,

Cpana was developed by Toshiba (my affiliation), and its source code was 
published based on a request by ZigBee Alliance in order to facilitate 
ZigBee IP development.
So it's basically a vendor PANA implementation.  The person who posted 
cpana data is my colleague whom I asked to post it, so it's virtually 
coming from me.

The cost of integrating it with an application is publically available 
in the following paper:

"A key management framework for AMI networks in smart grid",  Das, S., 
Ohba, Y. ;  Kanda, M. ;  Famolari, D. ;  Das, S.K., IEEE Communications 
Magazine, August 2012.

The target application is ANSI C12.22 smart metering application. The 
integration cost is 1.7KByte of code for so called universal key 
management function in the paper.
The cost of integrating cpana with PCP is not available now because it 
is not implemented yet, but I expect it to be similar size.

Lastly, I was not poking holes in other peoples arguments.  What I 
technicaly claimed is the data for EAP over DHCP, EAP-GSS and IKEv2 is 
not a fair basis for comparing PCP authentication proposals on the table 
because EAP over DHCP does not satisfy EAP transport requirements and 
data for EAP-GSS and IKEv2 seem to exclude  reliability function that 
would be additionally required for PCP to transport EAP.  In other 
words, it makes little sense to discuss size of orange and grape when 
discussing size of two apples.  Any technical counter argument is welcomed.

Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Nov 2012 18:58:33 -0500

Rafa Marin Lopez wrote:
> Maybe I am missing something, but the lines you posted (6,912) are
> around twice the lines I provided (3,687) (apart from other data such as
> the 741 lines for a PaC in constrained devices). Not sure how they are
> similar.

  The numbers for a full PANA implementation are well over 1K LoC.  The
difference between 4K and 7K is that the 4K number discounts a bunch of
things which aren't "really" part of a PANA implementation.  I'm not
familiar enough with OpenPANA to divide the numbers that way, so I just
counted the code I saw.

  The 741 LoC for a PaC in a constrained device is nice.  But there was
already the claim (not by me) that cpana && OpenPANA weren't ready for
prime time.  So presumably that number will grow as it becomes
production ready.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Nov 2012 19:04:53 -0500

I've responded to those points in prior messages.

  I'll also note that you previously claimed (Nov 27) that IKEv2 was a
"proper EAP transport design", and a better metric for evaluation.  Now
you're claiming it's not.  I also disagree with your claims about
EAPoDHCP, but I see nothing productive coming from that conversation.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Nov 2012 09:49:13 +0900

What I previously claimed is:

"Thank you for sending data for strongswan's charon keying daemon about 
IKEv2 which I consider a proper designed EAP transport.  If your count 
excludes reliability function part of IKEv2, then I would claim that it 
is still not a fair basis for evaluating PCP authentication proposals."

Yes, IKEv2 is a proper designed EAP transport, but the data shown by Sam 
is not a
a fair basis for evaluating PCP authentication proposals if it excludes 
reliability function part of IKEv2 in that case it is not going to be an 
apple-to-apple comparison.

For IKEv2, what is needed for PCP discussion is data including 
reliability function.

Yoshihiro Ohha

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 07:40:04 +0100

Hi Dan,

Please see inline. 

Cheers,
Med 

>De : Dan Wing [mailto:[email-masked]] 
>Envoyé : vendredi 30 novembre 2012 00:42
>À : BOUCADAIR Mohamed OLNC/OLN; 'Reinaldo Penno (repenno)'; 
>[email-masked]
>Objet : RE: [pcp] PCP for RTP/RTCP (was RE: PCP MoM (FRIDAY, 
>November 9, 2012))
>
>valuable. 

Med: I checked https://www.sipit.net/SIPit29_summary and seems there is no data for a=rtcp attribute. Real SIP deployments I'm aware of does not make use of this atribute. This is why we mentioned in the draft the following:

   [RFC3605] defines an explicit "a=RTCP" SDP attribute for some
   applications using a distinct port than RTP+1.  Even though [RFC3605]
   defines a new attribute for explicitly specifying the RTCP attribute
   for the SDP based applications, but since it is not a MUST to use
   this attribute, there are still applications that are not compliant
   with this RFC.  

 The question comes down to:  does the industry still need
>and it gets deployed will it be relevant any more?

Med: One of the major SIP-based deployment in Europe relies on a SIP agent in the CPE + The CPE is beining controlled by the same provider. Integrating this option does require change only at the CPE side; no change is required at the service side. This option is more for legacy deplopyments.

  It will take a
>couple of years.

Med: Perhpas, but this option is IMHO trivial. Integrating it to an existing SIP UA is simple + there are already existing PCP servers which handle this option. All what we need is an official codepoint.

PCP-base says:

   Additional PCP Option codes in the ranges 4-63 and 128-191 can be
   created via Standards Action [RFC5226], the ranges 64-95 and 192-223
   are for Specification Required [RFC5226] 

Why it is an issue to assign a codepoint in the 192-223 range for this option? 

>> * Simplify the service access point (e.g., SBC): no need for 
>hosted nat
>> traversal
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 30 Nov 2012 12:11:47 +0100

> Why it is an issue to assign a codepoint in the 192-223 range for this option?

I tend to agree with Mohamed. The draft is technically sound, short 
simple, and easy to implement. Yes it may address a corner case of RTP, 
one which we may want to see disappear quickly, but it appears to still 
be an important corner case in some deployments. And IMHO it's the 
IETF's responsibility to clean up after itself when it makes a mess. The 
WG should adopt this draft.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 30 Nov 2012 13:50:39 +0000

>and it gets deployed will it be relevant any more?  It will take a

It has been several years since a=rtcp has been defined and in the live
deployments that we have
seen, it is rarely used. I don¹t see that rapidly changing in the next
couple of years.

>of workaround/workarounds the industry is currently using today.

Do we know what that workaround is? That can be helpful.

Thanks
Senthil

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 30 Nov 2012 07:05:35 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 29, 2012 10:40 PM
> To: Dan Wing; 'Reinaldo Penno (repenno)'; [email-masked]
> Subject: RE: [pcp] PCP for RTP/RTCP (was RE: PCP MoM (FRIDAY, November
> 9, 2012))
> 
> Hi Dan,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> >De : Dan Wing [mailto:[email-masked]] Envoyé : vendredi 30 novembre
> >2012 00:42 À : BOUCADAIR Mohamed OLNC/OLN; 'Reinaldo Penno (repenno)';
> >[email-masked] Objet : RE: [pcp] PCP for RTP/RTCP (was RE: PCP MoM
> >(FRIDAY, November 9, 2012))
> >
> >The port adjacency is (was) a need of RTP (RFC1889, RFC3550) which is
> >now owned by AVTCORE.
> >
> Med: I checked https://www.sipit.net/SIPit29_summary and seems there is
> no data for a=rtcp attribute. Real SIP deployments I'm aware of does not
> make use of this atribute. This is why we mentioned in the draft the
> following:
> 

Yeah, but I was hoping for more definitive information to help motivate
the PCP working group.

One other point in favor of your draft is that a=rtcp support is needed
on both the local and remote ends, and while a person can influence the
local end (install PCP client, PCP server, and your PCP extension), there
is effectively no influence of the remote end, where a=rtcp support is
also needed.

> >port adjacency, or by the time PCP standardizes this functionality and
> >it gets deployed will it be relevant any more?
> 
> Med: One of the major SIP-based deployment in Europe relies on a SIP
> agent in the CPE + The CPE is beining controlled by the same provider.
> Integrating this option does require change only at the CPE side; no
> change is required at the service side. This option is more for legacy
> deplopyments.

What does that network do, today?  I am guessing, but I expect that it
does latching (draft-ietf-mmusic-latching).  What problem exists on
that network today that would be solved by deploying PCP?  Are there
incentives in place to actually deploy the PCP solution and remove 
whatever RTCP solution is used today?

> >It will take a couple of years.
> 
> Med: Perhpas, but this option is IMHO trivial. Integrating it to an
> existing SIP UA is simple + there are already existing PCP servers which
> handle this option.

The complexity is that it continues a legacy of applications that 
rely on certain ports, when we know -- due to NAT64, NAT44, MAP (A+P),
and other IPv4 address sharing technologies -- that applications are
less and less likely to be able to acquire certain desired ports.  

That problem of acquiring a specific port was apparent a decade ago, 
when a=rtcp was published in 2003.

> All what we need is an official codepoint.
> 
> PCP-base says:
> 

Code point assignment is done by IANA, not by the PCP working group.  
The specification required range exists for situations where a standard
is not possible or is not desired.  This may well be such a case, but
I know that I don't know enough about how and why this extension would
be used in the industry.

-d