Subject: [pcp] CONSENSUS CALL on PCP security

From: Dave Thaler <[email-masked]>
Date: Mon, 15 Jul 2013 00:33:14 +0000

The WG has discussed two approaches for using EAP with PCP:
direct EAP-in-PCP vs using PANA.

At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP
and 10 or 11 for PANA. There was significant confusion/disagreement
around requirements and proposed solutions at that time.

At IETF 85, we again polled the room and got a different result, this
time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however,
still significant confusion/disagreement around requirements and
proposed solutions.

Since IETF 85, we have made lots of progress on getting agreement
on the requirements, and draft-reddy-pcp-auth-req now seems to be
relatively stable without significant areas of disagreement known.
Discussion may of course continue if new issues are raised but we
believe any additional changes are unlikely to affect people's
position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA.

The general sense of the WG also seems to be that either approach could be
made to fit the requirements, so we believe it is now time for us to
determine consensus (draft-resnick-on-consensus is a great read)
on the approach question. We know many folks would just like to 
make a decision and move on.

Hence the chairs would like to ask the WG which solution direction the
WG should pursue in meeting the requirements. Please state your
recommendation on this thread, preferably along with your rationale.
Avoid responding on this thread to others' rationale, use a separate
thread as needed.

To help us judge consensus, please use the template below and
respond by SUNDAY JULY 28.

-Dave and Reinaldo

---

1) Could you *live with* EAP-in-PCP? If not, state reason you would object.

    <NO and state reason, or YES>

2) Could you *live with* PANA? If not, state reason you would object.

    <NO and state reason, or YES>

3) If you said yes to both 1 and 2, but have a strong preference between
the two, which approach do you prefer and why?

    <EAP-in-PCP, or PANA>.  <state reason>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 16 Jul 2013 05:50:59 +0000

Hi Dave,

In the poll when you refer to PANA, please clarify the draft you are referring to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ?

--Tiru.

> -----Original Message-----
> From: Dave Thaler [mailto:[email-masked]]
> Sent: Monday, July 15, 2013 6:03 AM
> To: [email-masked]
> Subject: [pcp] CONSENSUS CALL on PCP security
>

---

From: <[email-masked]>
Date: Tue, 16 Jul 2013 09:27:06 +0000

I would note that the two PANA approaches (side-by-side and encapsulation) may have difference in supporting PCP proxy.  In the side-by-side approach (draft-ohba-pcp-pana), PANA relay would need to be implemented on PCP proxy to communicate client's IP address to the server since PCP THIRD_PARTY option is carried only in PCP message.  In the encapsulation approach (draft-ohba-pcp-pana-encap), PANA relay would not be needed since PCP THIRD_PARTY option can be carried in a PCP message that encapsulates a PANA message.

Since PANA relay is simple stateless relay, it should not be a problem with the side-by-side approach as long as THIRD_PARTY option is the only PCP option inserted by PCP proxy.  However, if PCP proxy inserts other PCP options as well, then I think the encapsulation approach can be better than the side-by-side approach.

Regards,
Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Tuesday, July 16, 2013 2:51 PM
To: Dave Thaler; [email-masked]
Subject: Re: [pcp] CONSENSUS CALL on PCP security

Hi Dave,

--Tiru.

> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, 
> however, still significant confusion/disagreement around requirements 
> and proposed solutions.
> 
> Since IETF 85, we have made lots of progress on getting agreement on 
> the requirements, and draft-reddy-pcp-auth-req now seems to be 
> The general sense of the WG also seems to be that either approach 
> could be made to fit the requirements, so we believe it is now time 
> for us to determine consensus (draft-resnick-on-consensus is a great 
> read) on the approach question. We know many folks would just like to 
> To help us judge consensus, please use the template below and respond 
> by SUNDAY JULY 28.
> 
> -Dave and Reinaldo
> 
> ---
> 
> 3) If you said yes to both 1 and 2, but have a strong preference 
> between the two, which approach do you prefer and why?
> 

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: Alper Yegin <[email-masked]>
Date: Tue, 16 Jul 2013 12:50:32 +0300

Hi Yoshi,

> Since PANA relay is simple stateless relay, it should not be a problem with the side-by-side approach as long as THIRD_PARTY option is the only PCP option inserted by PCP proxy.  However, if PCP pr…

I didn't understand why PCP proxy having to insert any PCP options have any impact on the out-of band authentication performed by PANA.

Alper

---

From: <[email-masked]>
Date: Tue, 16 Jul 2013 13:32:56 +0000

Hi Alper,

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 6:51 PM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pcp] CONSENSUS CALL on PCP security

Hi Yoshi,

[YO] I meant any PCP options that affect PCP authentication behavior, in which case PANA relay in the side-by-side approach would have to insert equivalent PANA attributes which may not exist now. 

Regards,
Yoshihiro Ohba

Alper

>> Hence the chairs would like to ask the WG which solution direction 
>> the WG should pursue in meeting the requirements. Please state your

---

From: Alper Yegin <[email-masked]>
Date: Tue, 16 Jul 2013 19:44:29 +0300

Hi Yoshi,

> [YO] I meant any PCP options that affect PCP authentication behavior, in which case PANA relay in the side-by-side approach would have to insert equivalent PANA attributes which may not exist now. 

I'm trying to imagine what such PCP options would be? 

Alper

---

From: Dave Thaler <[email-masked]>
Date: Tue, 16 Jul 2013 16:50:54 +0000

> From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> Sent: Monday, July 15, 2013 10:51 PM
> Subject: RE: [pcp] CONSENSUS CALL on PCP security
> 
> Hi Dave,
> 
> In the poll when you refer to PANA, please clarify the draft you are referring
> to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or
> http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ?
> 
> --Tiru.

The question is intentionally agnostic as this is about a general approach,
not which specific implementation.  If it helps, you can interpret the
answer as "which of the two you think is better".

If the consensus is PANA rather than direct EAP-in-PCP, then we could 
ask as a follow-up question which of the two we should go with. If
you'd like to include your answer to that now though, feel free to
include that in your response to the call.

-Dave

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 16 Jul 2013 17:11:06 +0000

> Sent: Tuesday, July 16, 2013 10:21 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> not which specific implementation.  

Thanks that clarifies my doubt.

--Tiru.

> If it helps, you can interpret the

---

From: Alper Yegin <[email-masked]>
Date: Tue, 16 Jul 2013 23:01:07 +0300

Dave,

Last time we conducted this polling, the two pana-based solutions were asked separately.
Based on the discussions and the result of the poll, I realized some people preferred one PANA solution over the other, with possibly varying preference with respect to the EAP-o-PCP solution.
Bundling them up as one option is not a good idea.
So, I suggest we pose them as separate questions (like we did last time). After all, they are technically different.

One other thing: 

I'm not sure if enough thought went into the PCP Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfortable having thought all aspects around the proxy use. For (very important) example, what kind of security associations are needed for securing the proxy use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinations of these are needed? Then we need to talk about how we dynamically create those using any one of these solutions.

Alper

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 17 Jul 2013 02:21:00 +0000

Alper,

On 17/07/13 1:31 AM, "Alper Yegin" <[email-masked]<mailto:[email-masked]>> wrote:

Dave,

One other thing:

I'm not sure if enough thought went into the PCP Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfortable having thought all aspects around the proxy use. For (very important) example, what kind of security associations are needed for securing the proxy use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinations of these are needed?

We've included this in the updated version of auth req:

REQ-9: A PCP proxy that modifies PCP messages SHOULD have the
ability to independently authenticate with the PCP client and PCP
server. The presence of a PCP proxy hence requires two separately
authenticates SAs. As a consequence, the PCP proxy:

A. MUST be able to validate message integrity of PCP messages
from the PCP server and client respectively.

B. MUST be able to ensure message integrity after updating the
PCP message for cases described in sections 6 of ietf-pcp-proxy.

The PCP proxy MUST also permit authentication on only one side of
the proxy. For example, a customer premises host may not
authenticate with the PCP proxy but the PCP proxy may authenticate
with the PCP server.

-Prashanth

Then we need to talk about how we dynamically create those using any one of these solutions.

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,
[email-masked]<mailto:[email-masked]>

_______________________________________________
pcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pcp

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 17 Jul 2013 06:15:44 +0000

I have a clarification for both the drafts - how do EAP-in-PCP, PANA solutions meet REQ-14 ?

--Tiru.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 17 Jul 2013 09:53:32 +0300

Hi Prashanth,

> authenticate with the PCP proxy but the PCP proxy may authenticate

So:

- We have two types of SAs. One between the client and the proxy, another between the proxy and the server.
- None of them are mandatory to use.

For each one that needs to be used, we need to perform authentication between the end-points. 
(e.g., between client and proxy).

So, in a way, we are dealing with security in two independent parts; client to proxy, and proxy to server. 
They are totally segregated from security perspective. 

Right?

Hmm, one thing: The server may need to know the authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. So, we may need to define an option to carry that piece of information from the proxy to the server.

Alper

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 17 Jul 2013 07:09:32 +0000

Please see inline [TR]

From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, July 17, 2013 12:24 PM
To: Prashanth Patil (praspati)
Cc: [email-masked]; Tirumaleswar Reddy (tireddy)
Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Prashanth,

So:

Right?

[TR]

Why would the PCP server need to know the authentication ID of the client. For example Home network;   Alice (PCP client) -> Home Router (PCP Proxy) -> ISP (PCP Server)
Why would PCP Server in ISP care about the authentication ID of Alice ?

--Tiru.

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 17 Jul 2013 07:46:07 +0000

Hi Alper,

On 17/07/13 12:23 PM, "Alper Yegin" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Prashanth,

So:

PRA: Yes, none of them are mandatory, it's currently the prerogative of the server to mandate authentication. The proxy MUST be able authenticate with either client or server or both.

Right?

PRA: Right. As far as the client is concerned, the proxy is the PCP server. The proxy is in turn a client to the upstream PCP server. The two parts should be independent of each other.

PRA: May be, but don’t know why the server would want to know the auth-id of a client.

-Prashanth

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: Alper Yegin <[email-masked]>
Date: Wed, 17 Jul 2013 14:32:02 +0300

If the PCP server wants to provide some sort of differentiated service to the subscribers (e.g., different mapping lifetime), then it needs to know the authenticated ID of the subscriber.

Alper

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 17 Jul 2013 13:04:44 +0000

Hi Alper,
In the example below, wont the ISP consider all users behind the home router as a single subscriber and not differentiate among individual users? Essentially, the PCP Server would treat the proxy (i.e the home router) as a single subscriber.

-Prashanth

On 17/07/13 5:02 PM, "Alper Yegin" <[email-masked]<mailto:[email-masked]>> wrote:

Alper

Please see inline [TR]

Cc: [email-masked]<mailto:[email-masked]>; Tirumaleswar Reddy (tireddy)

Hi Prashanth,

So:

Right?

[TR]

--Tiru.

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: Alper Yegin <[email-masked]>
Date: Wed, 17 Jul 2013 17:36:35 +0300

For the home gateway case, yes I'd think so.
Could we not apply PCP proxy case to public WiFi hotspots? There in that case the terminals attaching to the AP are distinct subscribers.

Alper

On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote:

> On 17/07/13 5:02 PM, "Alper Yegin" <[email-masked]> wrote:
>

---

From: Dan Wing <[email-masked]>
Date: Wed, 17 Jul 2013 11:11:18 -0700

> They are totally segregated from security perspective. 

That is how I have modeled it in my head, yes.  Imagining a home network, there are "N" people and "MM" devices in the home.  Each person and each device might have its own credentials and its own permissions to do various things (e.g., I don't want to allow my Sony television to run a server).  My ISP does not care about my NNN people and MMMM devices; it only knows of one user, and only wants to know of one user (anything else is too hard for the ISP).  So, the PCP proxy enforces policies for the NNN people and MMMM devices, and the PCP proxy uses different credentials (and thus a different security association) to talk with the ISP's PCP server.  The per-user and per-device policy is "aggregated" by the PCP proxy.  The same would occur within an enterprise network, where there are NNN people and MMMM devices.

> Hmm, one thing: The server may need to know the authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. So, we may need to define an opti…

That's a different model, where the per-user / per-device policy is not aggregated by the PCP proxy; instead, the client's identity is propagated through the network.  I don't know if we need that model yet.

-d

---

From: Ben McCann <[email-masked]>
Date: Wed, 17 Jul 2013 19:20:32 +0000

YES

   Yes, but we really rather not use PANA. See below...

3) If you said yes to both 1 and 2, but have a strong preference between the two, which approach do you prefer and why?

We strongly prefer EAP-in-PCP for several reasons:

* PANA, as we understand it, is not mobile-friendly. It requires the PCP client to *always* have an authenticated session active and that is wasteful on mobile clients when the authentication rekey interval is much shorter than the mapping lifetime. Margaret Wasserman captured this in slides 13 and 14 of her presentation http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We believe the *client* should decide when to authenticate (because it needs to create or refresh a mapping) because that lets the client optimize its use of the network and reduce its power consumption. 

We understand that a PCP server may need to send a message to the client when no authenticated session is active. If no authenticated session is active then we prefer the server send an UN-authenticated "call home" message directing the client to authenticate and then the server can send its messages over the authenticated channel. We recognize an attacker can induce the client to connect to the server by forging an unauthenticated "call home" message. But, having done that, the client can ignore subsequent forged call home messages because it will already have an authenticated session. Worse case, an attacker can't make EAP-in-PCP consume any more client resources than PANA does because PANA requires the client to always have an authenticated session available.

* PANA requires more server side resources. The authentication protocol should efficiently support 100,000's of clients on a large PCP server. Why should the server continuously maintain authenticated sessions with *every* client? Clients using 24 hour mapping lifetimes can be served by short authentication key lifetime like, for example, 5 minutes. Let the client connect, authenticate, program the mappings, and then let the authenticated session expire. Rinse and repeat in 24 hours,. Client-driven authentication via EAP-in-PCP requires less resources on the server because the server can discard the authenticated session state once the key lifetime expires.

There was some discussion that PANA is preferable to EAP-in-PCP because it supports "liveness testing". We don't believe liveness testing is useful when the server resources consumed, per client, are PCP mappings. Checking the liveness of 100,000 clients is much more resource intensive on the server than just keeping the client's mappings around until they expire naturally at the end of their lifetime. In short, we believe EAP-in-PCP will scale better on the server than PANA.

* We believe the decision to use EAP-in-PCP vs. PANA is a choice between designing and implementing an EAP-in-PCP transport that is tailored for PCP versus adapting an existing protocol (PANA) to fit the needs of PCP.  We don't think implementing an EAP-in-PCP transport is difficult so we prefer it over PANA. EAP-in-PCP provides a clean slate that's unencumbered by the design decisions and assumptions of an existing protocol (PANA). 

-Ben McCann

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Jul 2013 06:37:55 +0000

From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, July 17, 2013 8:07 PM
To: Prashanth Patil (praspati)
Cc: Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

I did not get the use case, though there are distinct subscribers attached to the WLC (MAG), wouldn't WLC act as PCP Proxy and communicate with the PCP Server in ISP to which it's a single subscriber.

This looks just like Enterprise deployment where there are multiple users (similar to distinct subscribers attached to AP) communicating with the PCP server in the Enterprise Network, the PCP server in the campus would act as PCP proxy communicating with the ISP (PCP Server) to which it's a single subscriber.

--Tiru.

Alper

Hi Alper,

-Prashanth

Alper

Please see inline [TR]

Hi Prashanth,

So:

Right?

[TR]

--Tiru.

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: Alper Yegin <[email-masked]>
Date: Thu, 18 Jul 2013 11:06:47 +0300

Tiru,

I'm talking about "public WiFi hotspot". Like in coffee shops.
The PCP proxy and the PCP server are either owned by the same ISP, or two separate business entities.
The users who attach to the hotspot are all distinct subscribers with distinct service plans. This is different than how all members of my house appears to the ISP, or all employees appears to the enterprise network administration. 
So, the PCP service provided to each user may differ. Maybe not all users are allowed to control some certain ports.  For PCP server to be able to act based on the Id of the users, it needs to know who they are as the requests are proxies by the PCP proxy.

Alper

On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tireddy) wrote:

> I did not get the use case, though there are distinct subscribers attached to the WLC (MAG), wouldn’t WLC act as PCP Proxy and communicate with the PCP Server in ISP to which it’s a single subscriber.
>  
> This looks just like Enterprise deployment where there are multiple users (similar to distinct subscribers attached to AP) communicating with the PCP server in the Enterprise Network, the PCP server in the campus would act as PCP proxy communicating with the ISP (PCP Server) to which it’s a single subscriber.
>  
> --Tiru.
>  
> Alper
>  
>  
>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 18 Jul 2013 11:33:34 +0300

Hello,

I'm afraid your below issues are based on misconceptions introduced by the http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides.
We did address those misconceptions in several rounds, but it seems like some still linger.

PANA does not force clients to always have a session, or always stay awake or connected.

If a client wants to get authenticated and generate a 5 minute key, and afterwards sleep, detach, etc., it can very well do that using PANA.
We can support that by simply setting the lifetime of the PANA SA to that short fix value, or letting the PANA SA timeout and expire. 
So, you can run PANA and have a 5 min SA, then have no PANA activity for 23:55hrs, and then come back and do another PANA authentication and have another 5min SA. No problems.

Therefore, there are no issues with mobile, and no issues with server side resources.

After all, PANA is adopted by Zigbee Alliance. I don't think the deployment cases considered here are any more constrained than theirs…

> EAP-in-PCP provides a clean slate that's unencumbered by the design decisions and assumptions of an existing protocol (PANA). 

Was there any other concern leading to your above statement?

Alper

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 18 Jul 2013 13:44:44 +0200

Hi Ben: 

Apart from Alper's clarifications (I agree with them), I would like to add a few notes as well.

>> * PANA, as we understand it, is not mobile-friendly. It requires the PCP client to *always* have an authenticated session active and that is wasteful on mobile clients when the authentication reke…

[Rafa] This is incorrect. The PCP client could authenticate and immediately close PANA session (see PANA-Termination-Request/Answer) and still keeping the key generated for PCP. Second, in PANA, the client can decide when to authenticate (sending a PCI message).

>> We understand that a PCP server may need to send a message to the client when no authenticated session is active. If no authenticated session is active then we prefer the server send an UN-authent…

[Rafa] Again, this is incorrect. See my comment above about PANA-Termination-Request/Answer.

>> * PANA requires more server side resources. The authentication protocol should efficiently support 100,000's of clients on a large PCP server. Why should the server continuously maintain authentic…

[Rafa] Also incorrect. PANA termination does the job.

>> There was some discussion that PANA is preferable to EAP-in-PCP because it supports "liveness testing". We don't believe liveness testing is useful when the server resources consumed, per client,…

[Rafa] Liveness testing is something not mandatory in PANA. 

>> * We believe the decision to use EAP-in-PCP vs. PANA is a choice between designing and implementing an EAP-in-PCP transport that is tailored for PCP versus adapting an existing protocol (PANA) to…

[Rafa] You may agree with me that this pure speculation. However, as founder of OpenPANA project (http://sourceforge.net/projects/openpana/) I can speak on facts. We have been able to implement a PANA client in a sensor node and to install PAA in a small wireless router. I have given, a couple of times in this list, implementation information about lines of source code. 

Moreover, we have made the effort and presented in this WG the results of PCP-PANA integration with two different open source PANA implementations (OpenPANA and CPANA):

http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17

However, I am still waiting for seeing anything like this in EAP-in-PCP.

Best Regards.

>> -Ben McCann

-------------------------------------------------------
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: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Jul 2013 13:16:41 +0000

Hi Alper,

Please see inline [TR]

From: Alper Yegin [mailto:[email-masked]]
Sent: Thursday, July 18, 2013 1:37 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Tiru,

[TR]

If the PCP Proxy and PCP server belong to the same ISP, why can't the PCP Proxy itself enforce the subscriber-based policy ?
I do not understand why PCP Proxy cannot enforce identity-based policies for PCP, if you could explain or point to more details how the topology looks like ?, How PCP Auth works in this use with PCP proxy works in this use case ? it will help.

Thanks and Regards,
--Tiru.

Alper

Cc: Tirumaleswar Reddy (tireddy); [email-masked]<mailto:[email-masked]>

--Tiru.

Alper

Hi Alper,

-Prashanth

Alper

Please see inline [TR]

Hi Prashanth,

So:

Right?

[TR]

--Tiru.

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: <[email-masked]>
Date: Thu, 18 Jul 2013 13:39:52 +0000

Hi Tiru,

Abstract of pcp-proxy draft says:

“
   This document specifies a new PCP functional element denoted as PCP
   Proxy.  The PCP Proxy relays PCP requests received from PCP Clients
   to upstream PCP Server(s).  This function is mandatory when PCP
   Clients can not be configured with the address of the PCP Server
   located more than one hop.
“

If this abstract is correct, I interpret that PCP clients only know the PCP proxy’s address, but the PCP server *can* be the authentication end-point for the PCP clients.  This is similar to the http proxy case where http servers are the authentication end-points for http clients.  Having said that, I think it is a bad idea to mandate PCP proxy to be *the* end-point that authenticates the PCP clients in the proxy case.

Yoshihiro Ohba

From: [email-masked] [mailto:[email-masked]] On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: [email-masked]; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Alper,

Hi Prashanth,

So:

Right?

-Prashanth

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: Alper Yegin <[email-masked]>
Date: Thu, 18 Jul 2013 16:43:04 +0300

Hi Tiru,

I'd expect the PCP proxy to be as transparent and as light-weight as possible. Therefore, I'd normally expect the policy-based decision be made and executed on the PCP server. 
Besides, PCP server is the real end-point consuming requests of the PCP client. Therefore it is simpler to let the PCP server apply the policy on its own responses.

Btw, can the PCP proxy and the PCP server belong to two separate ISPs?
If so, would the PCP server be satisfied if it receives the "user's authenticated ID", or would it require to authenticate the user itself? 

Alper

On Jul 18, 2013, at 4:16 PM, Tirumaleswar Reddy (tireddy) wrote:

> If the PCP Proxy and PCP server belong to the same ISP, why can’t the PCP Proxy itself enforce the subscriber-based policy ?

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 18 Jul 2013 15:11:12 +0000

Hi Yoshihiro,
Although the abstract says that, I don’t think the intent is for the PCP Proxy to just be a relay agent. It is clear from other sections of the draft that the proxy is indeed a server and needs to modify fields (albeit minimal) before forwarding them to the actual server. This implies two independent authentications need to happen.

-Prashanth

On 18/07/13 7:09 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tiru,

“

Yoshihiro Ohba

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: [email-masked]<mailto:[email-masked]>; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Alper,

Hi Prashanth,

So:

Right?

-Prashanth

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: <[email-masked]>
Date: Thu, 18 Jul 2013 15:29:43 +0000

Hi Prashanth,

From: Prashanth Patil (praspati) [mailto:[email-masked]]
Sent: Friday, July 19, 2013 12:11 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ); [email-masked]
Cc: [email-masked]; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Yoshihiro,
Although the abstract says that, I don’t think the intent is for the PCP Proxy to just be a relay agent. It is clear from other sections of the draft that the proxy is indeed a server and needs to modify fields (albeit minimal) before forwarding them to the actual server. This implies two independent authentications need to happen.
[YO] I don’t understand your logic here. Even an http proxy can modify http requests (e.g., X-Forwarded-For header), and an http server can still authenticate http clients behind the proxy.

Yoshihiro Ohba

-Prashanth

Hi Tiru,

“

Yoshihiro Ohba

Hi Alper,

Hi Prashanth,

So:

Right?

-Prashanth

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Jul 2013 15:49:54 +0000

Hi Alper,

Please see inline [TR]

From: Alper Yegin [mailto:[email-masked]]
Sent: Thursday, July 18, 2013 7:13 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Tiru,

I'd expect the PCP proxy to be as transparent and as light-weight as possible.

[TR] Yes, PCP proxy is transparent. But it is acting as PCP server to the client; client does not have to know that the PCP proxy it is communicating with is acting as PCP proxy to upstream PCP server. Further PCP Proxy is stateful it will create NAT mapping etc. In all the PCP proxy scenarios mentioned in the http://tools.ietf.org/id/draft-ietf-pcp-proxy-03.txt PCP proxy will update the PCP message from the PCP client before forwarding to the PCP server; so if the PCP proxy authenticates with the PCP server it must have a separate SA so that it can update the Authenticate Data with the new MAC.

Therefore, I'd normally expect the policy-based decision be made and executed on the PCP server.

[TR] In my previous mails we discussed why it is not a problem with Home/Enterprise Networks which would have a PCP Proxy. If you could explain the "Public Wifi Hotspot" use case with more details, it will help us understand the scenario better.

--Tiru.

Alper

Hi Alper,

Please see inline [TR]

Cc: [email-masked]<mailto:[email-masked]>

Tiru,

[TR]

Thanks and Regards,
--Tiru.

Alper

--Tiru.

Alper

Hi Alper,

-Prashanth

Alper

Please see inline [TR]

Hi Prashanth,

So:

Right?

[TR]

--Tiru.

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 18 Jul 2013 16:23:18 +0000

Hi Yoshihiro,

On 18/07/13 8:59 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Prashanth,

To: ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ); [email-masked]<mailto:[email-masked]>

Hi Yoshihiro,

How does the proxy maintain message integrity if it modifies requests/responses? The case is different with HTTP.

-Prashanth

Yoshihiro Ohba

-Prashanth

Hi Tiru,

“

Yoshihiro Ohba

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: [email-masked]<mailto:[email-masked]>; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Alper,

Hi Prashanth,

So:

Right?

-Prashanth

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: Ben McCann <[email-masked]>
Date: Thu, 18 Jul 2013 17:00:54 +0000

Thank you for clarifying that "PANA does not force clients to always have a session, or always stay awake or connected".

That, I believe, wasn't Margaret's point. PANA *supports* server side re-authentication even if the client doesn't think it's necessary. So, if the server chooses, it can wake up the client by sending packets. That said, this really isn't a legitimate criticism of the PANA protocol. It's an issue that can be addressed by proper programming or configuration of the PCP/PANA server to make sure it doesn't unnecessarily re-authenticate the clients. 

So, I agree with you that PANA, on a properly configured server, can be as "mobile friendly" and lightweight as EAP-in-PCP. 

My concerns about starting from a clean slate are based, in part, on Steve Hartman's "Implementation Analysis: strong preference for PCP-specific approach" (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His arguments were persuasive (to me) and the counter-arguments were not. 

I understand that implementation should not dictate protocol design but I think we should let implementation *inform* protocol design. If I have to select between two ways to define a protocol, and one of them is simpler to implement, then I will tend to vote for the simpler option if all other criteria are equal. I see EAP-in-PCP as the simpler option even if there is source code for PANA.

I've also reviewed the OpenPANA source code and I have some concerns that illustrate this point:

* The PANA state machine includes 13 states with 22 separate input events. That state machine has to be integrated with the simpler PCP state machine. My intuition, based on too many years of experience, is that integrating the PANA and PCP state machines is tricky to implement, debug, and verify. That complexity is, in part, because PANA already has a fairly complex state machine. I don't believe EAP-in-PCP requires this much complexity.

* The OpenPANA implementation is about 6900 SLOCs long as measured by an sloccount version 2.26. This seems like a lot of code (aka complexity) to tunnel EAP packets over PCP. And, that doesn't include the code that must be added to PCP required to integrate PCP with PANA. I believe an EAP-in-PCP implementation will be much simpler but, I admit, I don't have an implementation to show you that proves that point.

* The presence of an open source version of PANA is a vote in its favor but that depends on whether that code is easily portable to many environments. I think the OpenPANA implementation makes assumptions about its runtime environment that aren't very portable. It assumes a multi-threaded environment with posix sockets and my runtime environment doesn't meet those requirements.

To be fair, I don't think I've said anything here that wasn't already covered by Steve Hartman. But, I did review the code and I agree with his conclusions.

-Ben McCann

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Thursday, July 18, 2013 4:34 AM
To: Ben McCann
Cc: Dave Thaler; [email-masked]
Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP security)

Hello,

After all, PANA is adopted by Zigbee Alliance. I don't think the deployment cases considered here are any more constrained than theirs...

Alper

---

From: <[email-masked]>
Date: Thu, 18 Jul 2013 20:19:21 +0000

Well, that is easy: Once the PCP server successfully authenticate a PCP client, it distributes a key used for protecting PCP message between the PCP client and the PCP proxy to the PCP proxy in a secure way.

Regards,
Yoshihiro Ohba

From: Prashanth Patil (praspati) [mailto:[email-masked]]
Sent: Friday, July 19, 2013 1:23 AM
To: ohba yoshihiro; [email-masked]
Cc: [email-masked]; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Yoshihiro,

Hi Prashanth,

Hi Yoshihiro,

-Prashanth

Yoshihiro Ohba

-Prashanth

Hi Tiru,

“

Yoshihiro Ohba

Hi Alper,

Hi Prashanth,

So:

Right?

-Prashanth

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 18 Jul 2013 23:30:34 +0200

Hi Ben:

> My concerns about starting from a clean slate are based, in part, on Steve Hartman's "Implementation Analysis: strong preference for PCP-specific approach" (http://www.ietf.org/mail-archive/web/pcp…

[Rafa] Why my answers in http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html are not ok?

> * The PANA state machine includes 13 states with 22 separate input events. That state machine has to be integrated with the simpler PCP state machine. My intuition, based on too many years of exper…

[Rafa] Ben, I have always assumed we all have experience in the area. In particular, I have been working on PANA since 2003 and I have done source coding myself, I have been leading an open source PANA implementation and deployed PANA in several EU projects,  without any inconvenience so far.

About the state machine, I can tell you that part of it is completely optional. 

And about the integration between PANA and PCP, I disagree based on the experience we got from http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17

> * The OpenPANA implementation is about 6900 SLOCs long as measured by an sloccount version 2.26. This seems like a lot of code (aka complexity) to tunnel EAP packets over PCP. And, that doesn't inc…

[Rafa] This number is completely wrong as I already explained in http://www.ietf.org/mail-archive/web/pcp/current/msg02631.html (as you may observe this is a repeating conversation). You may agree with me that doing the sloccount  over the entire package does not help too much. We need to be more specific.

In the message I already sent, the discussion was about openpana-0.2.3. Right now, we have openpana-0.2.4 and we have new values. The following values only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or RADIUS client since those values will be common to any other solution using EAP and RADIUS.

OpenPANA:

The PAA:

3130 LoC (PAA ST + PAA main program + PANA messages + PAA session + PRF)

The PaC

2720 (PaC ST + PaC main + PANA messages + PaC session + PRF)

It is worth noting that those values includes 1846 LoCs which are common functionality to PaC and PAA.

Moreover, as I also explained in the e-mail we have a version for very constrained devices (sensor nodes). In particular we have a PaC implementation for Contiki OS named PANATIKI (http://sourceforge.net/projects/panatiki) and the values are: 

PANATIKI : 517 (PaC state machine) + 141 (PaC main program)

But again, please take into account this is just an open source implementation and not a product. And, of course, running code is absolutely better than no code.

Regarding your comment "And, that doesn't include the code that must be added to PCP required to integrate PCP with PANA", please see slide 12 in http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17  .  Just a 100 lines that includes "PCP Key derivation and export. Unix Sockets."  in the case of OpenPANA.

> * The presence of an open source version of PANA is a vote in its favor but that depends on whether that code is easily portable to many environments. I think the OpenPANA implementation makes assu…

[Rafa] For example, PANATIKI does not assume multi-threaded environment with posix sockets (it is an implementation for a sensor node after all). Btw, there are two open source implementations OpenPANA/PANATIKI and CPANA.

> To be fair, I don't think I've said anything here that wasn't already covered by Steve Hartman. But, I did review the code and I agree with his conclusions.

[Rafa] As you can see, I already counter-argumented that analysis. In any case, I will be in Berlin so any doubt you have about OpenPana/PANATIKI or just implementating PANA, let me know and I will be more than happy to meet and discuss.

Best regards.

---

From: Ben McCann <[email-masked]>
Date: Fri, 19 Jul 2013 00:55:21 +0000

Hi Rafa,

I incorrectly used a discussion about the suitability of the OpenPANA  implementation as an argument to defend my statement "EAP-in-PCP provides a clean slate that's unencumbered by the design decisions and assumptions of an existing protocol (PANA).". That argument was a waste of time because the suitability or availability of a reference implementation is irrelevant to whether PANA was designed with a set of security considerations that are appropriate for PCP. This understanding of the security considerations is the "clean slate" that is important to me.

For example, PANA negotiates its own security association so it can provide data integrity for the final EAP response packet. That's fine, but where have we decided that PCP needs to secure the integrity of that response packet? (It probably should). PANA does not secure the earlier EAP packets that carry parameters like the cipher suite selection or authentication parameters for the selected EAP method. So, those could be compromised by an attacker. Where have we decided that this is an acceptable risk for PCP? We haven't discussed that, but we implicitly agree to live with it if we move forward with PANA. (Or, at least, we accept that risk with some EAP methods).

I prefer EAP-in-PCP because it will make us think through those issues for PCP. (We've made a good start in the auth requirements draft). Until we get those requirements down, I think it's premature to decide PANA is the right choice. It might be, if we agree that PANA's security considerations are OK for PCP. Or, we could decide that a simple EAP-in-PCP transport w/o *any* security association is sufficient because we can leverage the security properties of EAP methods such as EAP-TTLS to achieve the data integrity required for the EAP protocol.

I'm vacation for two weeks and won't be in Berlin to continue this discussion face-to-face.

-Ben McCann

-----Original Message-----
From: Rafa Marin Lopez [mailto:[email-masked]] 
Sent: Thursday, July 18, 2013 5:31 PM
To: Ben McCann
Cc: [email-masked]
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security)

Hi Ben:

OpenPANA:

The PAA:

The PaC

Best regards.

-------------------------------------------------------
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: Dan Wing <[email-masked]>
Date: Thu, 18 Jul 2013 19:40:10 -0700

On Jul 18, 2013, at 6:43 AM, Alper Yegin <[email-masked]> wrote:

> Besides, PCP server is the real end-point consuming requests of the PCP client.

The PCP proxy is acting on the PCP requests, too, because the PCP proxy in a home (or a coffee shop) is very likely doing IPv4 NAT for all the reasons people do IPv4 NAT in homes and coffee shops.  When it does that, it necessarily also needs to change the source port number inside the PCP request.  For a concrete example, consider two hosts in a home, both listening on TCP/80, and both asking for TCP/80 mappings; one of them will be first and get what it wants (port 80 on the 'external' side of the home NAT), the other will get assigned some other port on 'external' side of the in-home NAT.  This gets repeated again on the ISP's PCP server, if the ISP is also operating its own NAT.

> Therefore it is simpler to let the PCP server apply the policy on its own responses.
> 

The ISP's PCP server does not need to know of the different users within the home --- exactly like PSTN telephone service where mom (or dad) gets the bill and anybody in the home can make a long distance phone call to Timbuktu. The ISP has little business incentive to have that awareness; the subscriber's CPE (running a PCP proxy) can solve that problem and know about the NNN users in the home, control things by time-of-day, and all the other things that are done on sophisticated residential CPE today.

-d

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Jul 2013 15:34:11 +0300

> The PCP proxy is acting on the PCP requests, too, because the PCP proxy in a home (or a coffee shop) is very likely doing IPv4 NAT for all the reasons people do IPv4 NAT in homes and coffee shops.…

OK. I think I was confused about the term "proxy".
Now I understand this is about controlling a chain of NATs. 
It's not like one node is proxying messages for another node, but one node is doing its own thing, and passing the message further up for the other node to do its own thing.
The roles of the two nodes are quite equivalent, not like one is simply forwarding messages back and forth.

Going back to your port 80 example, maybe the first gold user will get the port 80 and never a silver user is allowed to get it.
For that, the PCP server also needs to know the identity of the users.

Alper

Alper

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 19 Jul 2013 12:56:31 +0000

Distribution is not a good approach, brings in too many additional problems. How does the PCP Server trust the proxy, how is the key distributed, should it all be facilitated over PCP etc ?

The above problems aside, as being discussed in other threads, the role of the PCP proxy is not just that of forwarding but also acting on the request, installing state etc and does all of this based on its own policy. Also, an ISP's PCP server does not need to know of the different users within the home and has no incentive to individually authenticate each of those different users – it's only interesting to the proxy (the PCP server as far as the individual home users are concerned).
For all these reasons, the two legs are independent and need to have independent authentication.

-Prashanth

On 19/07/13 1:49 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Yoshihiro Ohba

To: ohba yoshihiro; [email-masked]<mailto:[email-masked]>

Hi Yoshihiro,

Hi Prashanth,

Hi Yoshihiro,

-Prashanth

Yoshihiro Ohba

-Prashanth

Hi Tiru,

“

Yoshihiro Ohba

Hi Alper,

Hi Prashanth,

So:

Right?

-Prashanth

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Jul 2013 15:58:15 +0300

Hi Ben,

"If I have to select between two ways to define a protocol, and one of them is simpler to implement, then I will tend to vote for the simpler option if all other criteria are equal."

Indeed.

But the simplicity comparison is apples to oranges. 
On one side there is an RFC that went thru the whole IETF system and got published as an RFC, with multiple interoperable implementations, and industry adoption.
On the other side is a incomplete, early stage personal I-D with no running code.
It's not surprising that the latter appears simpler. 

Lot of work starts with the same claim in IETF: We'll design a Simple X. One needs to wait and see how they end up eventually.

There's gotta be some tangible signs about the truthfulness of the claim, before IETF embarks on that path.
Otherwise we'd be abandoning the "reuse" mantra and spend precious IETF cycles on re-inventing.

…

Regarding the states in one PANA implementation and its implication on PCP integration:

PANA protocol itself has only 4 phases.
It does not matter if one implementation chose to implement it using 13 states.
Your implementation can use less. 

Besides,  number of states in EAP-o-Foo does not matter when integrating EAP-o-Foo with Foo.
Foo tells EAP-o-Foo to authenticate X, and EAP-o-Foo comes back with the result. 
It does not matter (for integration) how many states are used by EAP-o-Foo in between. It's an internal matter for EAP-o-Foo implementation.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Jul 2013 16:05:16 +0300

Let me inject my toughest on this one….

On Jul 19, 2013, at 3:55 AM, Ben McCann wrote:

> I prefer EAP-in-PCP because it will make us think through those issues for PCP.

Well, thinking about those issues are fine. It's fair. 
Jumping to a conclusion that EAP-o-PCP is simpler and sufficient, w/o doing that is not fine :-) 

Already few such things were brought up and examined (e.g., the need for server-side re-auth, ping, etc).
Re-auth turned out to be needed, ping turned out to be not needed but negligible amount of code. What else?

Alper

> (We've made a good start in the auth requirements draft). Until we get those requirements down, I think it's premature to decide PANA is the right choice. It might be, if we agree that PANA's security considerations are OK for PCP. Or, we could decide that a simple EAP-in-PCP transport w/o *any* security association is sufficient because we can leverage the security properties of EAP methods such as EAP-TTLS to achieve the data integrity required for the EAP protocol.
>

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 19 Jul 2013 13:09:53 +0000

On 19/07/13 6:25 AM, "Ben McCann" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Rafa,

Agreed. REQ-5 that lists requirements in this area should discuss points you've highlighted.

TLS/DTLS is a good candidate to satisfy REQ-14:

REQ-14: There SHOULD be support for a means to provide integrity
protection without user authentication, i.e., an anonymous client
should be able to verify a PCP server using server-side-only auth
and as a consequence obtain an SA which will be used for PCP
message integrity. For example, a client visiting foreign
networks such as a hotel, hot spot etc where the client may gain
access to the network but does not know the credentials to
authenticate with the PCP server. The negotiation of SA should be
secure such that the SA is only known to the anonymous client and
PCP server.

-Prashanth

-Ben McCann

-----Original Message-----
From: Rafa Marin Lopez [mailto:[email-masked]]
Sent: Thursday, July 18, 2013 5:31 PM
To: Ben McCann
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security)

Hi Ben:

OpenPANA:

The PAA:

The PaC

Best regards.

-Ben McCann
-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Thursday, July 18, 2013 4:34 AM
To: Ben McCann
Cc: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP
security)
Hello,

-------------------------------------------------------
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]<mailto:[email-masked]>
-------------------------------------------------------

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Jul 2013 16:21:55 +0300

They can use EAP-TLS with server-side-only authentication.

---

From: <[email-masked]>
Date: Fri, 19 Jul 2013 13:41:37 +0000

Hi Prashanth,

Sent: Friday, July 19, 2013 9:57 PM

Distribution is not a good approach, brings in too many additional problems. How does the PCP Server trust the proxy, how is the key distributed, should it all be facilitated over PCP etc ?
[YO] Key distribution is common in EAP/AAA (e.g., MSK distribution from AAA server to APs). Proxy itself needs to be authenticated by PCP server.  The resulting SA created between the proxy and server can be used as the secure channel for the key distribution. Details will need to be worked out, but I think we need to agree on the use case and requirement before entering into solution space.

Having said that I think the current PCP authentication requirements are still unclear  in terms of proxy support.

The above problems aside, as being discussed in other threads, the role of the PCP proxy is not just that of forwarding but also acting on the request, installing state etc and does all of this based on its own policy. Also, an ISP's PCP server does not need to know of the different users within the home and has no incentive to individually authenticate each of those different users - it's only interesting to the proxy (the PCP server as far as the individual home users are concerned).
For all these reasons, the two legs are independent and need to have independent authentication.
[YO] I agree that your model is definitely *a* valid use case, but my whole point is that there are other proxy use cases that would require end-to-end authentication between clients and server (e.g., public wifi hotspot).

Yoshihiro Ohba

-Prashanth

Regards,
Yoshihiro Ohba

Hi Yoshihiro,

Hi Prashanth,

Hi Yoshihiro,

-Prashanth

Yoshihiro Ohba

-Prashanth

Hi Tiru,

“

Yoshihiro Ohba

Hi Alper,

Hi Prashanth,

So:

Right?

-Prashanth

Alper

-Prashanth

Alper

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 22 Jul 2013 01:43:44 +0200

Hi Ben:

> I incorrectly used a discussion about the suitability of the OpenPANA  implementation as an argument to defend my statement "EAP-in-PCP provides a clean slate that's unencumbered by the design deci…

[Rafa] I must say I am a little bit confused about your general line of thoughts here. You started your arguments first saying about PANA is not mobile-friendly, then PANA consumes resources and then implementation problems or the liveliness test. Those are clearly misconceptions about PANA that we have clarified. Now, "clean slate" is regarding security considerations. Ok, let us discuss about security, but you may agree with me that this line of arguments might be a little bit confusing. 

> 
> For example, PANA negotiates its own security association so it can provide data integrity for the final EAP response packet.
> That's fine, but where have we decided that PCP needs to secure the integrity of that response packet? (It probably should).

[Rafa] The main purpose of the PANA SA does not have anything to do with protecting the final EAP response packet. As many security protocols, it provides key confirmation to bind authentication with the exported key material by EAP. This  is a cryptographic binding between the two layers. This ensures that same two entities participate not only performing EAP but also the EAP lower-layer protocol. This is useful to avoid man-in-the-middle attacks. Moreover it serves to avoid the attack you mention about ciphersuite and authentication parameters below (see how PANA generates the PANA_AUTH_KEY). 

> PANA does not secure the earlier EAP packets that carry parameters like the cipher suite selection or authentication parameters for the selected EAP method. So, those could be compromised by an attacker. Where have we decided that this is an acceptable risk for PCP?

[Rafa] If you don't have any keys.... how are you supposed to protect anything?  If we assume we are performing EAP for authentication and key management, we will not have any key material exported to any EAP lower-layer (e.g. PCP or PANA) until EAP is successfully finished at the end.  Moreover EAP is designed to operate with no security assumption in the lower-layer. 
 
> We haven't discussed that, but we implicitly agree to live with it if we move forward with PANA. (Or, at least, we accept that risk with some EAP methods).

[Rafa] See my comment above, there is no such a risk. Btw, what EAP methods are you referring to? As I said EAP is designed to operate with no security.

> 
> I prefer EAP-in-PCP because it will make us think through those issues for PCP. (We've made a good start in the auth requirements draft).

[Rafa] About simplicity, how about this? Let assume that the only thing you have to worry about at PCP level is to manage a pre-shared key between PCP client and PCP server. That is simple, don't you think?

> Until we get those requirements down, I think it's premature to decide PANA is the right choice.

[Rafa] Then, do you think the consensus call is too premature? 

> It might be, if we agree that PANA's security considerations are OK for PCP. Or, we could decide that a simple EAP-in-PCP transport w/o *any* security association is sufficient because we can leverage the security properties of EAP methods such as EAP-TTLS to achieve the data integrity required for the EAP protocol.

[Rafa] Either or I don't understand your point or I think there is some confusion about EAP and its layers (see Fig. 1 and 2 in RFC 3748) EAP-TTLS is a method and it will export keys to the EAP lower-layer . Why do you relate EAP-TTLS with the protection of the EAP protocol ?

In this regard, I also think there is a general misconception about EAP. For example, people may think that this is just tunneling EAP in PCP (I think you even mentioned this in a previous e-mail). But it is not. RFC 3748 defines requirements for a correct EAP lower-layer. If we transport EAP in PCP , PCP will become an EAP lower-layer according to the EAP standard. Consequence is PCP has to follow requirements imposed by RFC 3748 and RFC 5247 to be a correct EAP lower-layer. In other words, this means we will have to define a new EAP lower-layer and to follow the same path we already followed with PANA which is a RFC now. In other words, we are essentially re-inventing the wheel (I say this based also on experience since, at research level, I have tried to design different EAP lower-layers... EAP-in-X, EAP-in-Y, etc...). I would appreciate if you could read this link I sent to the list about this aspect:  http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html

The usage of PANA avoids to include all these aspects in PCP itself (PANA already does it), and as a consequence the PCP security would be simplified a lot.

> I'm vacation for two weeks and won't be in Berlin to continue this discussion face-to-face.

Enjoy your vacations!

---

From: Tina TSOU <[email-masked]>
Date: Tue, 23 Jul 2013 21:11:16 +0000

Dear all,

    YES

Thank you,
Tina

---

From: "Martija, Ricardo V" <[email-masked]>
Date: Fri, 26 Jul 2013 17:43:49 +0000

YES

    YES

    PANA. PCP can "piggyback" on PANA for the key management function and

    eliminate the need for using EAP directly over PCP. At IETF86, Y. Ohba

    demonstrated that:

    a) the PANA-based PCP authentication solution and its implementation can

        meet ALL the basic PCP authentication requirements

    b) the PANA-based PCP authentication solution works

    c) support for PCP authentication requires minimal changes to existing

        open-source PANA implementation

Rick

---

From: Dave Thaler <[email-masked]>
Date: Sun, 28 Jul 2013 10:37:11 +0000

Just a reminder that this poll is closing shortly.  If you plan to respond, please do so asap.

-Dave

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dave Thaler
> Sent: Monday, July 15, 2013 2:33 AM
> To: [email-masked]
> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP and 10
> or 11 for PANA. There was significant confusion/disagreement around
> requirements and proposed solutions at that time.
> 
> At IETF 85, we again polled the room and got a different result, this time 12
> hands for direct EAP-in-PCP and 6 for PANA. There was, however, still
> significant confusion/disagreement around requirements and proposed
> solutions.
> 
> Since IETF 85, we have made lots of progress on getting agreement on the
> requirements, and draft-reddy-pcp-auth-req now seems to be relatively
> stable without significant areas of disagreement known.
> Discussion may of course continue if new issues are raised but we believe
> any additional changes are unlikely to affect people's position on overall
> solution approach, i.e. direct EAP-in-PCP vs. PANA.
> 
> determine consensus (draft-resnick-on-consensus is a great read) on the
> approach question. We know many folks would just like to make a decision
> and move on.
> 
> Hence the chairs would like to ask the WG which solution direction the WG
> should pursue in meeting the requirements. Please state your
> Avoid responding on this thread to others' rationale, use a separate thread as
> needed.
> 
> To help us judge consensus, please use the template below and respond by
> SUNDAY JULY 28.
> 
> -Dave and Reinaldo
> 
> ---
> 
> 3) If you said yes to both 1 and 2, but have a strong preference between the
> two, which approach do you prefer and why?
>

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 28 Jul 2013 18:47:55 +0200

>     <NO and state reason, or YES>

Yes.

>     <NO and state reason, or YES>

Yes.

>     <EAP-in-PCP, or PANA>.  <state reason>

I have a very strong preference for EAP-in-PCP for several reasons, all of which I have presented in WG sessions.  In summary, I believe that adding PANA to the security stack adds complexity to the solution, and I do not see any benefits that justify the added complexity.  Also, the "code reuse" benefit of using PANA and EAP is not, in my opinion, any greater than the code reuse benefit of using EAP directly, as PCP would require modifications to the PANA standards and modifications to any available PANA code.

I continue to believe that both solutions could work, and that they would provide the same level of security.

Margaret

---

From: Stuart Cheshire <[email-masked]>
Date: Sun, 28 Jul 2013 10:37:50 -0700

> 1) Could you *live with* EAP-in-PCP? If not, state reason you would object.

YES.

> 2) Could you *live with* PANA? If not, state reason you would object.

NO.

To elaborate, what I mean is that I would be willing to lobby the relevant Apple engineering teams to implement EAP-in-PCP, and I believe that such efforts would have a reasonable chance of being successful. Note that "relevant Apple engineering teams" covers multiple groups -- PCP client, AirPort Base Station, Internet Sharing, and iPhone personal hotspot.

I believe that trying to lobby those four groups to support PCP authentication via PANA would have a small chance of success, because that solution is more complicated and has more potential for more inter-group dependencies.

Stuart Cheshire

---

From: <[email-masked]>
Date: Sun, 28 Jul 2013 18:21:07 +0000

No.  

EAP-in-PCP is a re-invention of PANA in that it modifies PANA header to be a PCP opcode and PANA AVPs to be PCP options.  What opponents of PANA say "it's complex than EAP-in-PCP" is either a false statement or misconception, given that there is no known running code of EAP-in-PCP AFAIK.  The basic part of the scheme is the same as that of PANA, except that the scheme lacks support for protected server-initiated re-authentication trigger to renew an existing SA.  As a result, the scheme would unnecessarily force the server and client to wait until the existing SA to be expired to have a new SA even if immediate re-key is needed, to follow the PCP authentication requirements.  This functional shortcoming could probably resolved by further modifying the scheme, but it would make the scheme functions in the same way as PANA.  

I am strongly concerned on re-invention in the IETF because if we (the IETF) go with this scheme, then we are basically endorsing to develop multiple different application-specific EAP transport protocols.  Instead, we should re-use an existing standard protocol as much as possible for reducing risk of design flaws as well as reducing maintenance cost of standard protocols.  In this problem space, re-use of EAP is not sufficient and we need to think about re-use of existing EAP transport as well, as transporting EAP has to consider many aspects to get it right, and that is why EAP-in-PCP looks similar to PANA.  Like it or not, re-invention cannot be a good engineering way than re-use.  (For the same reason, I would strongly object if someone come up with a new authentication protocol that functions in the same way as EAP or a new host configuration protocol that functions in the same way as DHCP, etc.)

Yes.

Regards,
Yoshihiro Ohba

---

From: Subir Das <[email-masked]>
Date: Sun, 28 Jul 2013 17:06:17 -0400

No. IMO, the current  specification is not complete.  Assume that the draft
is modified and it satisfies  the PCP requirements, my understanding  is
that it will end up with another protocol very similar to PANA. What would
be the benefit of doing the similar work and develop yet another EAP lower
layer when we have already an IETF protocol that satisfies all the PCP
requirements?  It was shown that PANA works with PCP
without any modifications of existing PANA RFC. The results were presented
in the last IETF.   So my points are: existing RFC and running code.
Moreover, the integration is simple.

N.B.: PANA is currently under deployment in a major vertical market.

   Yes.

 Thanks,
-Subir

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 Jul 2013 21:45:02 +0000

> I am strongly concerned on re-invention in the IETF because if we (the IETF) go with this scheme, then we are basically endorsing to develop multiple different application-specific EAP transport pr…

You will notice that Margaret made a statement about her preference, but she stated it in response to the question about preference, and in that context it made sense and was responsive to the chairs' question.   The above statement reads to me like a statement of preference, not a technical objection, and so it seems to me not to be responsive to the chairs' question.   Is there a technical objection somewhere in the above text that I have missed, or are you in fact just stating a preference?

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 00:46:44 +0300

No.

Supporters have not made a successful case for not using an already existing IETF RFC, and instead reinventing it (which is EAP-o-PCP).

Besides, EAP-o-PCP spec is still incomplete (no support for server-initiated re-auth -- which people finally agreed to its need after long debates). 

On one side, there is an IETF RFC that got adopted by another SDO (Zigbee Alliance), implemented by multiple vendors and successfully interoperated.
On the other side is an incomplete spec, which at best can do what PANA already does if and when it goes thru the same stages.

There's literally no indication that EAP-o-PCP would be any better, simpler, etc. after passing all those stages.  

Yes.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Sun, 28 Jul 2013 23:57:16 +0200

NO. 

Let's avoid re-inventing the wheel. All the arguments I have seen in favor of EAP-in-PCP have been based on pure speculation so far. The same has happened with the arguments against PANA. And those against PANA either they have been based on misconceptions about PANA or simply the arguments were wrong. Here in the list, we have clarified several times these points one by one. In any case, the fact is PANA is a RFC, another fact is that it has running code (two open source implementations so far) and another fact it has been easily integrated with PCP as we showed in IETF 86. So, what else do we need?

YES.

---

From: <[email-masked]>
Date: Sun, 28 Jul 2013 21:58:07 +0000

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Monday, July 29, 2013 6:45 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [pcp] CONSENSUS CALL on PCP security

[YO] I wrote the above statement from architectural point of view, which I believe is a technical matter (not just a preference).

Yoshihiro Ohba

---

From: Pedro Moreno Sánchez <[email-masked]>
Date: Sun, 28 Jul 2013 23:58:52 +0200

1) Could you *live with* EAP-in-PCP? If not, state reason you would object.
NO. During the discussion, it has been stated that the integration of PANA
and PCP is hard to implement and to mantain given the current PANA
opensource implementations (i.e., OpenPANA and CPANA)

As one of main developers of OpenPANA and the PCP-PANA integration project
presented at the IETF86 meeting, I would like to totally disclaim this
argument. Given the
currently available code of OpenPANA and CPANA, the integration with PCP
was really easy.
Our PCP-PANA integration from scratch took few lines of code and, however,
it leaded
to a correctly working solution according to the PCP requirements.

On 28 July 2013 23:57, Rafa Marin Lopez <[email-masked]> wrote:

> Let's avoid re-inventing the wheel. All the arguments I have seen in favor
> of EAP-in-PCP have been based on pure speculation so far. The same has
> happened with the arguments against PANA. And those against PANA either
> they have been based on misconceptions about PANA or simply the arguments
> were wrong. Here in the list, we have clarified several times these points
> one by one. In any case, the fact is PANA is a RFC, another fact is that it
> has running code (two open source implementations so far) and another fact
> it has been easily integrated with PCP as we showed in IETF 86. So, what
> else do we need?
>
> >

-- 
----------------------------------------------------------------------------
Pedro Moreno Sánchez  - MSc Computer Engineer
Networks and Telematics
Faculty of Computer Science - University of Murcia
30100 - Murcia - Spain
email: [email-masked]
----------------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 Jul 2013 22:07:01 +0000

> [YO] I wrote the above statement from architectural point of view, which I believe is a technical matter (not just a preference).

No, it's not a technical matter.   It is a matter of preference, in much the same way that the choice of whether to have an open atrium that brings in sunlight, or closed floor that provides more square footage is a matter of preference.

If the extra square footage is a must, then that _becomes_ a technical argument, because the atrium provides less square footage.   But none of the four people (you, Alper, Subir and Rafa) who just asserted that EAP-in-PCP was something they could live with gave a reason why they couldn't live with it.   All four of you just said you couldn't live with it because you like atriums better than closed floors.   I do too, and it's a perfectly valid thing to say, but it's not a reason to say you can't *live with* EAP-in-PCP.

The problem with discussions about what is "architecturally better" tend to be matters of opinion, which can't be resolved, so it's always better to have some technical argument to use as a basis for differentiating between the choices, so that we don't have to make a choice based on a coin toss.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 Jul 2013 22:11:26 +0000

On Jul 29, 2013, at 12:07 AM, Ted Lemon <[email-masked]> wrote:
> But none of the four people (you, Alper, Subir and Rafa) who just asserted that EAP-in-PCP was something they could live with gave a reason why they couldn't live with it.

Sorry, that should have been "could not live with".

---

From: Alan DeKok <[email-masked]>
Date: Sun, 28 Jul 2013 20:11:04 -0400

I agree with Margaret.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 28 Jul 2013 20:12:02 -0400

[email-masked] wrote:
> EAP-in-PCP is a re-invention of PANA in that it modifies PANA header to be a PCP opcode and PANA AVPs to be PCP options.  What opponents of PANA say "it's complex than EAP-in-PCP" is either a false statement or misconception, given that there is no known running code of EAP-in-PCP AFAIK.

  Only if you ignore the previous conversations on this topic, along
with statistics.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 28 Jul 2013 20:20:24 -0400

Rafa Marin Lopez wrote:
> Let's avoid re-inventing the wheel. All the arguments I have seen in favor of EAP-in-PCP have been based on pure speculation so far.

  No.

> The same has happened with the arguments against PANA. And those against PANA either they have been based on misconceptions about PANA or simply the arguments were wrong.

  No.

> Here in the list, we have clarified several times these points one by one.

  Partly.  The arguments for PANA are (a) it's a standard, and (b)
random pointing to proprietary implementations.  The arguments for
EAP-in-PCP have drawn on prior art, with statistics, facts, and evidence.

  The main reason to not use EAP-in-PCP is that it's not a standard use
of EAP.  But EAP has been proven to work in practice in similar situations.

> In any case, the fact is PANA is a RFC, another fact is that it has running code (two open source implementations so far) 

  Are these actually used anywhere?  i.e. have even the authors used them?

  Last I looked, I couldn't even build them in a Posix environment.
They seemed to require a specific version of Linux with specific
libraries, etc.

  They just don't look like production code used in a wide variety of
environments.

  And to show my statistics: every new release of FreeRADIUS has 1M
downloads just from my web site.  It's worked for nearly 15 years on
Linux, *BSD, Solaris, AIX, HPUX, Mac OSX, with a preliminary Windows
port.  It's used by tier one Telcos, in loads reaching 100K+
transactions per day, for over a decade.

  Even ignoring the usage numbers, the open source PANA implementations
don't match that level of code quality, portability, or stability.  I
would *not* recommend depending on them in any production environment.

> and another fact it has been easily integrated with PCP as we showed in IETF 86. So, what else do we need?

  The truth would help.

  Alan DeKok.

---

From: Dacheng Zhang <[email-masked]>
Date: Mon, 29 Jul 2013 09:38:13 +0200

+1 I was beside Margaret when she sent the email, and fully agree with her. I am ok with PANA but like EAP-in-PCP more.

I found that EAP-in-PCP is criticized to be incomplete during the discussion. But I believe the key point of the current discussion is to clarify which type of solution is more suitable to PCP rather than which work is more complete. Right? 

Cheers

Dacheng

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 10:58:01 +0300

Hi Ted,

I cannot live with the possibility that IETF would not be reusing an existing protocol, and instead reinvent it just because few folks insist on their own solution.
I cannot live with it, because 
> it'd suck considerable amount of energy out of precious IETF cycles while designing it now, and while maintaining/extending it later,
> it'd suck considerable amount of energy out of architecture designers when they need to deal with the integration of one more protocol, and maintaining/extending it later,
> it'd suck considerable amount of energy out of product developers when they need to implement one more protocol, maintaining later too.

I feel funny when I need to explain why reuse is a good thing on an IETF mailing list.

I think the questions that'd get a YES answer is a different one: Can EAP-o-PCP made to work? 
Yes, it can be. 

Let me give another example to illustrate this: 

If someone comes along with a new host configuration protocol, with equivalent functionality as DHCP, without any substantial issue with DHCP, can it be made to work?
YES.
Should IETF live with it?
NO.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 11:06:57 +0300

Alan,
I'll leave it to the open source implementors to respond, if they care.

But let me point the following:

PANA having two open-source implementations is just one of the signs of maturity and completeness of the work.
If you don't want to use those implementations, that's OK. Write your own. This is not a sufficient justification to design a whole new protocol from scratch.

Alper

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Jul 2013 08:33:38 +0000

> I cannot live with the possibility that IETF would not be reusing an existing protocol, and instead reinvent it just because few folks insist on their own solution.

The working group can never reach consensus if we use this as the basis for making consensus decisions.

The reason DHCP hasn't been replaced by something else is not that nobody's tried.   It's that nobody's produced something better.   There have been numerous attempts to replace DHCP.   Some have produced useful results; none have eliminated the demand for DHCP.

For example, SLAAC replaces part of DHCP functionality, and it is popular because of the ways it is _better_ than DHCP.   DNS-SD replaces parts of DHCP, because it solves the problem _better_ in a specific domain.   If I were to have said "we shouldn't do DNS-SD because you can do that with DHCP," this would not have been constructive, and if I had gotten my way, it would have resulted in a bad outcome.

So this is why I am pressing you to state a technical objection if you have one, rather than taking the architectural issue as a technical objection, which it is not.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 11:54:27 +0300

Ted,

> For example, SLAAC replaces part of DHCP functionality, and it is popular because of the ways it is _better_ than DHCP.   DNS-SD replaces parts of DHCP, because it solves the problem _better_ in a…

Obviously those solutions made a technical case for getting into the IETF system. 
If they were doing what DHCP did, nothing more, nothing less, then they'd be rejected.

> So this is why I am pressing you to state a technical objection if you have one, rather than taking the architectural issue as a technical objection, which it is not.

Someone brings in a proposal draft-X.
I look at it and state that RFC-Y solves that problem.
I do lengthy analysis and discussions, and conclude that proponents of draft-X couldn't demonstrate why draft-X is still needed.
So, I state draft-X is not needed.

IMHO, this is a technical objection.

And whether it's called technical or not, if this line of discussion were not respected in deciding what IETF gets to do, then what's to prevent proliferation of functional clones of IETF standards, within IETF? Whatever it is, then maybe we should be asking that question too.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jul 2013 11:22:51 +0200

Subir,

The specification for the use of PANA with PCP is also incomplete.  We would need to make a fairly major decision about _how_ to use PANA with PCP (side-by-side or encaps) both of which have pluses and minuses, because PANA was not designed to be a general-purpose authentication layer with upper layers.

Also, we will need to define what parts of PANA are/are not used with PCP, and make sure that we specify the use of PANA w/PCP in a way that does not conflict with the use of PANA on the same device for authenticating network access (as that is the purpose of PANA).

I believe it is possible to do this work, just as I believe it is possible to specify a direct PCP to EAP mapping.  I honestly think it will be more work to specify the PANA solution, and that the eventual implementation will be more complex.

I feel uncomfortable about people stating that they can't "live with" EAP-over-PCP because they just happen to like PANA better. If there is an actual technical reason why any of you believe that an EAP-over-PCP solution will not work, could you state it?

If we are claiming we "can't live with" things that will work, simply because we prefer the other option, I would like to change my response accordingly.

Margaret

Sent from my iPad

On Jul 28, 2013, at 11:06 PM, Subir Das <[email-masked]> wrote:

> No. IMO, the current  specification is not complete.  Assume that the draft is modified and it satisfies  the PCP requirements, my understanding  is that it will end up with another protocol very similar to PANA. What would be the benefit of doing the similar work and develop yet another EAP lower layer when we have already an IETF protocol that satisfies all the PCP requirements?  It was shown that PANA works with PCP without any modifications of existing PANA RFC. The results were presented in the last IETF.   So my points are: existing RFC and running code. Moreover, the integration is simple.
>

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jul 2013 11:27:11 +0200

Alper,

The problem with your argument is that PANA is _not_ a general-purpose authentication protocol, EAP is.  One solution reuses EAP directly, and the other incorporates PANA and EAP.  Both of them reuse existing security standards.

Including PANA between EAP and PCP is roughly akin to including UDP in an IP over IP tunnel.  There are cases where it is valuable to do so, and cases where UDP would provide overhead and no value.  It doesn't make sense to include UDP between IP and IP _just because_ it is a standard.  In my opinion, PANA does not add sufficient value to be worth the overhead of including it.  Your opinion may differ from mine.

Margaret

Sent from my iPad

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Mon, 29 Jul 2013 12:52:54 +0300

YES
YES
>     <EAP-in-PCP, or PANA>.  <state reason>
EAP-in PCP

Talking strictly as an operator, i first heard of PANA through this WG (when the initial talks about pcp auth were happening).
I'm not saying PANA won't do the job (maybe better in some areas), i'm just saying that i feel more comfortable working with something i have some experience with, regardless the possible scenario that PANA's learning curve might end up less steep than expected.
Whatever the vendors decide to implement it's fine by me, as long as there is interoperability between all of them. Operators need something to work.

--
Tassos

---

From: Subir Das <[email-masked]>
Date: Mon, 29 Jul 2013 06:00:07 -0400

Margaret,
We  implemented the side-by-side approach and found that it does not
require any change to PANA RFC and it was relatively simple. Of course we
need to define a PANA use case for PCP if that is what you meant by
additional specification. It would be good to have a discussion on where
you think the complexities are and the conflicts between network access
authentication and PCP authentication using PANA.

We have not implemented direct EAP over PCP. If you have an implementation
and it satisfies the PCP requirements, can we get a copy? It would be then
easier for us to compare.

Thanks,
-Subir

On Mon, Jul 29, 2013 at 5:22 AM, Margaret Wasserman
<[email-masked]>wrote:

>
> Subir,
>
> The specification for the use of PANA with PCP is also incomplete.  We
> would need to make a fairly major decision about _how_ to use PANA with PCP
> (side-by-side or encaps) both of which have pluses and minuses, because
> PANA was not designed to be a general-purpose authentication layer with
> upper layers.
>
> Also, we will need to define what parts of PANA are/are not used with PCP,
> and make sure that we specify the use of PANA w/PCP in a way that does not
> conflict with the use of PANA on the same device for authenticating network
> access (as that is the purpose of PANA).
>
> I believe it is possible to do this work, just as I believe it is possible
> to specify a direct PCP to EAP mapping.  I honestly think it will be more
> work to specify the PANA solution, and that the eventual implementation
> will be more complex.
>
> I feel uncomfortable about people stating that they can't "live with"
> EAP-over-PCP because they just happen to like PANA better. If there is an
> actual technical reason why any of you believe that an EAP-over-PCP
> solution will not work, could you state it?
>
> If we are claiming we "can't live with" things that will work, simply
> because we prefer the other option, I would like to change my response
> accordingly.
>
> Margaret
>
>
>
> Sent from my iPad
>
> No. IMO, the current  specification is not complete.  Assume that the
> draft is modified and it satisfies  the PCP requirements, my understanding
>  is that it will end up with another protocol very similar to
> PANA. What would be the benefit of doing the similar work and develop yet
> another EAP lower layer when we have already an IETF protocol
> that satisfies all the PCP requirements?  It was shown that PANA works with
> PCP without any modifications of existing PANA RFC. The results were
> presented in the last IETF.   So my points are: existing RFC and running
> code. Moreover, the integration is simple.
>
> On Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler <[email-masked]>wrote:
>

---

From: <[email-masked]>
Date: Mon, 29 Jul 2013 10:43:10 +0000

I fully agree with what Alper stated below. 

For information to the WG members that were not involved in Zigbee Alliance:

During   ZigBee IP  discussion on PANA, Toshiba released CPANA as open source with the request from the Alliance members. It helped the community to make the decision but when vendors build their products they may not be using the open source code.  In any case, they have PANA as a mandatory function of ZigBee IP, and are interoperable and available in the market.

Thanks,
Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Monday, July 29, 2013 5:07 PM
To: Alan DeKok
Cc: [email-masked]
Subject: Re: [pcp] CONSENSUS CALL on PCP security

Alan,

Alper

On Jul 29, 2013, at 3:20 AM, Alan DeKok wrote:

>> In any case, the fact is PANA is a RFC, another fact is that it has 
>> running code (two open source implementations so far)
>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 14:46:05 +0300

Hello Tassos,

"i'm just saying that i feel more comfortable working with something i have some experience with,"

This statement is alerting me to a possible misunderstanding. 

EAP-over-PCP is being invented in PCP WG. There's really nothing in there that people can possibly have experience with.
(except for EAP, but that's common between EAP-o-PCP and EAP-o-PANA).

Alper

---

From: Alan DeKok <[email-masked]>
Date: Mon, 29 Jul 2013 07:51:44 -0400

> EAP-over-PCP is being invented in PCP WG. There's really nothing in there that people can possibly have experience with.

  Yes, there is related experience.  Please see previous discussions on
EAP being transported in other protocols.

  Alan DeKok.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 14:51:46 +0300

Margaret,

On Jul 29, 2013, at 12:27 PM, Margaret Wasserman wrote:

> 
> Alper,
> 
> The problem with your argument is that PANA is _not_ a general-purpose authentication protocol, EAP is.  One solution reuses EAP directly, and the other incorporates PANA and EAP.  

This is plain incorrect.
You give the impression that you simply put EAP as a payload of PCP and be done with it.
We had a lengthy discussion on that, and pointed out the EAP lower layer requirements in RFC 3748. 

> Both of them reuse existing security standards.
> 
> Including PANA between EAP and PCP is roughly akin to including UDP in an IP over IP tunnel.  
> There are cases where it is valuable to do so, and cases where UDP would provide overhead and no value.  It doesn't make sense to include UDP between IP and IP _just because_ it is a standard.  In my opinion, PANA does not add sufficient value to be worth the overhead of including it.  Your opinion may differ from mine.
> 

Now you are pointing to just one of the two ways PANA is provided, the one that tunnels PANA over PCP.
Yes, there's additional UDP header there. But is that a big enough problem to justify reinvent a solution? Note that this is not about carrying all IP traffic over an additional UDP layer. This is for brief authentication signaling only.

And then there's the other way of using PANA, which is the side-by-side approach, which is not subject to that extra UDP header at all.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 14:57:28 +0300

> EAP being transported in other protocols.

Which ones specifically? And how are the experience with those protocols are translating to favoring EAP-o-PCP but not EAP-o-PANA?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 29 Jul 2013 08:02:44 -0400

> PANA having two open-source implementations is just one of the signs of maturity and completeness of the work.

  It's offered by you as proof that we should use PANA.

> If you don't want to use those implementations, that's OK. Write your own.

  No, I'm saying that those implementations aren't mature.  Which
invalidates your use of them as proof we should use PANA.

  It's simple logic.  Your straw man portrayal of my argument is both
false, and a well-known logical fallacy.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 29 Jul 2013 08:05:44 -0400

> Which ones specifically? And how are the experience with those protocols are translating to favoring EAP-o-PCP but not EAP-o-PANA?

  I said:

Please see previous discussions on EAP being transported in other protocols.

  If you're too lazy to search the WG archives, I'm too lazy to do that,
too.

  And I have this thing where I "remember" what happened.  You're
playing the fool by claiming ignorance, and asking me for endless
justifications of my opinion.

  I'm not going to play that game.

  Alan DeKok.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jul 2013 14:08:17 +0200

Subir, 

In the implementation you site below, what mechanism did you use to distinguish between PCP-related PANA traffic and regular network-access-related PANA traffic?  Were you able to use a single PANA implementation for both tasks, running on a single port without specifying any way to distinguish between the two different PANA purposes?

Margaret

Sent from my iPad

On Jul 29, 2013, at 12:00 PM, Subir Das <[email-masked]> wrote:

> Margaret,
> We  implemented the side-by-side approach and found that it does not require any change to PANA RFC and it was relatively simple. Of course we need to define a PANA use case for PCP if that is what you meant by additional specification. It would be good to have a discussion on where you think the complexities are and the conflicts between network access authentication and PCP authentication using PANA. 
>  
> We have not implemented direct EAP over PCP. If you have an implementation and it satisfies the PCP requirements, can we get a copy? It would be then easier for us to compare. 
>  
> Thanks,
> -Subir  
>  
> 
> 
> On Mon, Jul 29, 2013 at 5:22 AM, Margaret Wasserman <[email-masked]> wrote:
>> 
>> Subir,
>>

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jul 2013 14:21:46 +0200

BTW, the major concern that I have with the side-by-side PANA approach is _not_ that it won't work, but that it involves two different ports that need to be equally accessible (and at the same IP address) in order for PCP to work properly -- in my experience, that presents a huge operational problem.  How is a network/system admin supposed to know that it is necessary to configure firewalls to pass both the PCP and PANA ports in order for PCP to work properly?

IMO, the encapsulated PANA approach is very similar to the PCP-over-EAP approach, operationally, except that PANA introduces more complexity and overhead.

Margaret

Sent from my iPad

---

From: Subir Das <[email-masked]>
Date: Mon, 29 Jul 2013 08:34:56 -0400

Both side-by-side and encapsulated approaches can work using a single port.
In our implementation we didn't use two separate ports. As I mentioned to
you, would be interested t know the complexity and overhead issues.

On Mon, Jul 29, 2013 at 8:21 AM, Margaret Wasserman
<[email-masked]>wrote:

> BTW, the major concern that I have with the side-by-side PANA approach is
> _not_ that it won't work, but that it involves two different ports that
> need to be equally accessible (and at the same IP address) in order for PCP
> to work properly -- in my experience, that presents a huge operational
> problem.  How is a network/system admin supposed to know that it is
> necessary to configure firewalls to pass both the PCP and PANA ports in
> order for PCP to work properly?
>
> IMO, the encapsulated PANA approach is very similar to the PCP-over-EAP
> approach, operationally, except that PANA introduces more complexity and
> overhead.
>
> Margaret
>
>
>
> Sent from my iPad
>
> On Mon, Jul 29, 2013 at 5:22 AM, Margaret Wasserman <[email-masked]
> > wrote:
>
>>
>> Subir,
>>
>> Also, we will need to define what parts of PANA are/are not used with
>> PCP, and make sure that we specify the use of PANA w/PCP in a way that does
>> not conflict with the use of PANA on the same device for authenticating
>> network access (as that is the purpose of PANA).
>>
>> I believe it is possible to do this work, just as I believe it is
>> possible to specify a direct PCP to EAP mapping.  I honestly think it will
>> be more work to specify the PANA solution, and that the eventual
>> implementation will be more complex.
>>

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jul 2013 14:36:22 +0200

Hi Alper,

> You give the impression that you simply put EAP as a payload of PCP and be done with it.

I don't know what you are referring to...  We wrote a draft that explains how to do this.  It is quite a concise draft, and people who want to know what we are proposing can read it.  I hope, at this point, that this is a discussion between people who understand the contents of all three drafts.

> Yes, there's additional UDP header there. But is that a big enough problem to justify reinvent a solution? Note that this is not about carrying all IP traffic over an additional UDP layer. This is…

I was making an analogy, not discussing (just) the UDP header in PANA.  IMO, there are significant portions of PANA that are not needed for PCP, and they are all additional overhead in both PANA approaches.

> And then there's the other way of using PANA, which is the side-by-side approach, which is not subject to that extra UDP header at all.

In my opinion, the side-by-side approach is fatally flawed, because it uses two ports (see my previous message).  Therefore, all claims that are made about the side-by-side approach are immaterial IMO.

The only PANA solution I can "live with" is the encapsulated approach, and I consider it inferior to the direct PCP-over-EAP approach, because of added complexity/overhead that offers little/no benefit.  I admit that they will both work, though.  They will both provide the same level of security and approximately the same operational/user experience, so I can "live with" either of them, even though I have a strong preference.

Please note that the _only_ PCP implementor who has stated an opinion has claimed that he would implement the direct PCP-over-EAP solution and would not implement a PANA-based solution.

Margaret

---

From: Pedro Moreno Sánchez <[email-masked]>
Date: Mon, 29 Jul 2013 15:11:17 +0200

Hello Margaret,

> Please note that the _only_ PCP implementor who has stated an opinion has
> claimed that he would implement the direct PCP-over-EAP solution and would
> not implement a PANA-based solution.
>
> I would like to say that this comment is incorrect. Both Ricardo Martijaand I implemented a functional PCP client and PCP server from scratch,
supporting the two PANA opensource implementations available (i.e., OpenPANAand
CPANA). The results of this integration were presented by Yoshihiro Ohba in
the IETF86 meeting. Additionally, both of us have stated our opinion in
favor of PCP-PANA approach. Please see:
http://www.ietf.org/mail-archive/web/pcp/current/msg03223.html
http://www.ietf.org/mail-archive/web/pcp/current/msg03234.html

Best,
Pedro.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 16:57:02 +0300

Hi Margaret,

> I don't know what you are referring to...  We wrote a draft that explains how to do this.  It is quite a concise draft, and people who want to know what we are proposing can read it.  I hope, at th…

I hope so too.

> I was making an analogy, not discussing (just) the UDP header in PANA.  IMO, there are significant portions of PANA that are not needed for PCP, and they are all additional overhead in both PANA ap…

We discussed this. Only two things turned out to be "extras". One is pana-ping, the other is IP reconfig flag.
These are two minor features, costing 10s of lines of code.  Not implementing, or implementing and not using is not a deal at all. At least not a deal to design a whole new protocol from scratch.
(We discussed this already. I'm sure you are not doing this intentionally, but repeatedly raising an already addressed issue is not productive).

> In my opinion, the side-by-side approach is fatally flawed, because it uses two ports (see my previous message).  Therefore, all claims that are made about the side-by-side approach are immaterial…

No, it uses single port. This issue was discussed long time ago, and already addressed, and documented in the I-Ds.
Both PANA solutions work over PCP port.
(this, again, is another "discussed and addressed issue").

> Please note that the _only_ PCP implementor who has stated an opinion has claimed that he would implement the direct PCP-over-EAP solution and would not implement a PANA-based solution.

Not true. Please see Pedro's email.

Thanks.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 17:07:44 +0300

> Please note that the _only_ PCP implementor who has stated an opinion has claimed that he would implement the direct PCP-over-EAP solution and would not implement a PANA-based solution.

Aside from ignoring Pedro's input, this is also not reflecting what Stuart said. He said: 

"To elaborate, what I mean is that I would be willing to lobby the relevant Apple engineering teams to implement EAP-in-PCP, and I believe that such efforts would have a reasonable chance of being successful. Note that "relevant Apple engineering teams" covers multiple groups -- PCP client, AirPort Base Station, Internet Sharing, and iPhone personal hotspot.

I believe that trying to lobby those four groups to support PCP authentication via PANA would have a small chance of success, because that solution is more complicated and has more potential for more inter-group dependencies."

Nowhere I see a commitment to implement EAP-o-PCP and not to implement PANA. 
This is all about "willingness to internally lobby" and "predictions about what might the engineering teams do". That's all.

Alper

> I would like to say that this comment is incorrect. Both Ricardo Martija and I implemented a functional PCP client and PCP server from scratch, supporting the two PANA opensource implementations available (i.e., OpenPANA and CPANA). The results of this integration were presented by Yoshihiro Ohba in the IETF86 meeting. Additionally, both of us have stated our opinion in favor of PCP-PANA approach. Please see:

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jul 2013 16:57:19 +0200

Sorry, Pedro.  I apologize for being unaware of your implementation.  Could you send a pointer to the open source project, if there is one?

Thanks,
Margaret

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Mon, 29 Jul 2013 17:58:05 +0300

Alper, from an operator's view, i see something like the following:

EAP over PANA over/with PCP
EAP over PCP

In the first case i have an intermediate layer which already works according to your experiences, but adds an unknown entity to operate/troubleshoot.
In the second case i have a known entity, which must be made to work in a way that is easy to operate/troubleshoot.

Really, i don't know if the second case is viable, but i would be willing to take the risk. From a vendor's view, everything might be different.
I wish i could have much simpler auth built into PCP from the beginning (generally i don't enjoy the idea of using something extra), but that is another talk.

--
Tassos

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Jul 2013 19:20:49 +0300

Hello Tassos,

I think there's a misunderstanding in here.

The name "EAP over PCP" may give a false comfort to the people, thinking "I know EAP (RFC 3748), I know PCP (RFC 6887), so it's just implementing two well-known specs".

That's not so. 

EAP over PCP involves implementation of EAP, PCP, and EAP-o-PCP specs (draft-ietf-pcp-authentication-0X). All three.
This last spec is the so-called "EAP lower layer" according to RFC 3748 terminology (and that's what PANA is too).
So, in that solution too one has an intermediate layer.
In other words, In terms of counting entities, there are same number of entities to deal with.

As for comparing the entities with respect to their viability, completeness, maturity, PANA is several years ahead of draft-ietf-pcp-authentication. (RFC + implemented + interoperated + other SDO adopted).

Alper

The EAP over PCP solution involves an intermediate layer between the EAP and PCP, which is defined in

---

From: Dave Thaler <[email-masked]>
Date: Mon, 29 Jul 2013 16:36:18 +0000

> The name "EAP over PCP" may give a false comfort to the people, thinking "I
> know EAP (RFC 3748), I know PCP (RFC 6887), so it's just implementing two
> well-known specs".
> 
> That's not so.
> 
> EAP over PCP involves implementation of EAP, PCP, and EAP-o-PCP specs
> (draft-ietf-pcp-authentication-0X). All three.
> This last spec is the so-called "EAP lower layer" according to RFC 3748
> terminology (and that's what PANA is too).

If you're counting specs, then I get a different count:
"EAP over PCP" = 3 specs: EAP, EAP-over-PCP (aka pcp-authentication), and PCP
"EAP-PANA-PCP" = 4 specs: EAP, PANA, PANA-with-PCP (e.g. draft-ohba-pcp-pana-encap) and PCP.

> As for comparing the entities with respect to their viability, completeness,
> maturity, PANA is several years ahead of draft-ietf-pcp-authentication. (RFC
> + implemented + interoperated + other SDO adopted).

My understanding is he's saying that PANA-with-PCP is not several years ahead
of EAP-over-PCP.  That seems a valid point to me.

-Dave

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Mon, 29 Jul 2013 23:25:09 +0300

The differentiation i'm trying to emphasize is that in terms of actual operation i feel like i'm having to compare the following:

EAP over a unknown (for me) but "old" transport protocol & this transport protocol over/with PCP
EAP over a new but "known" (for me) transport protocol

So i'm not actually looking at  the development effort needed (which in case of PANA might indeed be less and the developers are the ones that should take that into account most), but on the operation effort from a very high level.
I can understand (but not always agree with) the protocol re-usability "rule" of IETF, but if i had to choose between "combine X old solutions" vs "create a new solution", i wouldn't always choose the first.
If the vendors (from where i buy from) come back and tell me otherwise, then most probably i'll have to accept their opinion (unless i'm a very large operator, which can drive things the other way around).

--
Tassos

---

From: Alper Yegin <[email-masked]>
Date: Tue, 30 Jul 2013 11:41:48 +0300

> of EAP-over-PCP.  That seems a valid point to me.

I think that's a very optimistic view, knowing IETF :-)
See, it took us several months to convince people that network-initiated re-auth is needed (for something that obvious, it takes that long in IETF!), and then after many months their I-D is still not supporting that essential aspect….

---

From: Alper Yegin <[email-masked]>
Date: Tue, 30 Jul 2013 11:54:11 +0300

> "EAP-PANA-PCP" = 4 specs: EAP, PANA, PANA-with-PCP (e.g. draft-ohba-pcp-pana-encap) and PCP.

I was counting protocol entities in response to intermediate layer comment.

As for counting the number of docs, yes you are correct.

If you look at the content though, you see PANA ones are all about describing how to glue PANA with PCP (hence 3-4 pages of content), whereas EAP-o-PCP includes the glue + defines the new thing to glue (14 pages in its incomplete/early stage form).

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 30 Jul 2013 13:27:09 +0200

I think we should try to reach consensus on a a way forward now.  If we don't get moving, we may not be able to finish any PCP security solution before the WG disappears, and I think it is important to have a security solution.  Because of that I do not support asking any new questions now.

From my perspective, though, the only PANA solution I can live with is the encapsulated approach.

I understand that it is possible to specify some sort of hack involving the version fields and/or create a new short header to allow the side-by-side PANA approach to work on a single port, but I think that is equally undesirable to running the side-by-side version on two ports.  

After talking to Subir about his implementation, he indicated that the PANA messages in his implementation are transmitted inside PCP headers, which (in my mind) means that he has implemented the encapsulated option.  The fact that he has said that he implements the side-by-side option makes me concerned that we may not have the same idea of what those two different options actually are.  We will need to make sure we know exactly what we are comparing before we ask people to choose between them.

Margaret