[pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider)

Alper Yegin <alper.yegin@yegin.org> Mon, 17 September 2012 08:32 UTC

Return-Path: <alper.yegin@yegin.org>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C559921F853E for <pcp@ietfa.amsl.com>; Mon, 17 Sep 2012 01:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level:
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rrSO0NvHMRD for <pcp@ietfa.amsl.com>; Mon, 17 Sep 2012 01:32:10 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9180C21F8495 for <pcp@ietf.org>; Mon, 17 Sep 2012 01:32:10 -0700 (PDT)
Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LdYhm-1Tunzf1ToQ-00igr8; Mon, 17 Sep 2012 04:32:07 -0400
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="windows-1252"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
Date: Mon, 17 Sep 2012 11:31:46 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB96F2AF-7545-457D-96EB-F78B7666C00C@yegin.org>
References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1278)
X-Provags-ID: V02:K0:KQ6YR06kSMPh9omcle6TwqgMuJ+AwvviF6kyiL0TqlF 0bT4qWYSdyAG3ThiwkFOGb6MFvaDCiEw5F8/f15uS5sK1taA74 47gWBe6XkI6JYbedz4UdQ5vk8Zto8oLBR1HOFmvf0HpcydpbNS OzGitI+e2Gx47LxHIVMnZiw4Jt+Xlrse0wmMh1uiVj5mXGNMtc QDuH3b8M9/xPac6sRocjFivb9/OPlD28hzE8ZUEkM0g6hRE6qG E6SSe69QgNRGfZ8T3KCGlYvO3AQb54U9SW/3mN9LY38eR+OarX YwpLc4JIcndsD7hfE0UW3Un5vLsdQ8/rMZv95FEAG0aq0UJO4Z AWJHRrYhdsF8sfWtJ0mgSxGc9tTY+O7nMQ8c/ZWGqZQnx5Nil/ J5Uc6xC56wIoA==
Cc: "'pcp@ietf.org'" <pcp@ietf.org>
Subject: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Sep 2012 08:32:11 -0000

> +1 all I have seen so far is very complex for simple authentication of pcp. Let's embed it into pcp.
> 

It does not get simplified because you put one inside the other. In fact, it gets more complicated. Please see below.

> 
> I've been following this discussion and my preference would be to avoid
> having a design that requires a 'control protocol' between PCP and
> something else. We should reuse other IETF standards whenever possible but
> I would prefer everything to be part of a single protocol.

This is so un-IETF to me. Here we have two distinct pieces of work (PCP and key management), that can be satisfied using two protocols, we are talking about cobbling them together. 
Like that was done in the PPP-era, and like it's done in GTP (of 3GPP). Lot of pain with both...
I'd understand how other SDOs would think that way, but their priorities are different. But for IETF, we design protocols, and cobbling up protocols unnecessarily gets in the way of modularity, which is very essential to IETF. Right?

More on this below...


> Having a
> separate protocol would mean significant more test and effort for
> productization due to interactions, new CLIs, unforeseen state machine
> issues, etc. 

Just the opposite. 
Inventing new EAP-over-UDP as part of PCP is a brand-new design with brand-new code. PANA is a standard with multiple interoperating implementations. 
It's obviously more stable then the to-be-designed EAP-over-UDP/PCP. 

State machines is one of the issues with cobbling up protocols. Two separate protocols, living side by side, the state machines have nothing to conflict.

If you put on inside the other, then problems arise.

Specifically in this case: The direction of PCP flow and EAP flow are just the opposite. PCP is host-side driven req/rsp. EAP is network-side driven req/rsp. So, now PCP state machine has to change to support that too. And, EAP can generate asynchronous requests at any time from the network side (re-authentication). Exact same issue that we had with the EAP-over-DHCP (in fact this whole discussion has the same pattern….)

And I have yet to hear someone saying yes EAP-over-PCP satisfies the EAP lower layer requirements. I had raised this issue 3 times, and don't see anyone doing the work. It's not as simple as defining a container to ship EAP payloads back and forth. 


> 
> We will certainly even face all kinds of backward/forward compatibility
> issues between PCP, PANA (as an example) and whatever control protocol
> will run between them due to different features and evolution timeline.
> 

Again, situation is the opposite. 
Having them separate will allow them to evolve independently. 
Adding new features to a revision or extension of PANA is better than adding it to N different protocols which chose to embed equivalent of PANA.



> Although one can argue that PCP and PANA will run together as one entity
> the next step would be somebody asking for them to be decoupled and able
> to run anywhere. This train is never late.
> 

They are running separately. They are de-coupled as "protocols". What we are coupling is the "state" generated/used by PANA and PCP.
This decoupling is a feature for "protocols", not a bug. Using state generated from one protocol in another is a "architecture design" or "implementation".

Alper





> 
> -----Original Message-----
> From: Alper Yegin <alper.yegin@yegin.org>
> Date: Fri, 14 Sep 2012 16:38:17 +0300
> To: Margaret Wasserman <margaretw42@gmail.com>
> Cc: <pcp@ietf.org>
> Subject: Re: [pcp] PANA implementatinos to consider
> 
>> Hi Margaret,
>> 
>> Your below questions are implementation specific.
>> Let me answer them to describe how this can be implemented in one way.
>> Certainly there are other ways to implement them.
>> 
>>> 
>>> On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote:
>>>> As for the implementation complexity, I don't quite understand why
>>>> PANA (which is basically EAP over UDP) would ever be more complicated
>>>> then to-be-designed "EAP over UDP within PCP framework". While I don't
>>>> see a reason for former being more complicated, I see reasons for
>>>> seeing the latter being more complicated, as the whole thing now needs
>>>> to live within another protocol framework (read: format, flow, state
>>>> machine harmonization between the two).
>>> 
>>> I don't understand how you get away from coupling PANA and PCP, even in
>>> the demultiplexing case where they run side-by-side on the same port.  I
>>> think a number of details are being glossed over in your latest document
>>> when you refer to a need for an "API" between PANA and PCPŠ
>>> 
>> 
>> Association or binding of state between PANA and PCP is common on both.
>> But there are different degrees of "coupling". Or where you couple them.
>> Are we coupling the state generated/maintained between the two, or are we
>> coupling the protocols themselves.
>> 
>> You could say, a host configures a care-of address using DHCP, and uses
>> that IP address with Mobile IP, hence DHCP and Mobile IP are coupled.
>> Or, you could invent carrying DHCP over Mobile IP, and call that coupling
>> too.
>> 
>> Another more relevant example: Running IKE for IPsec, or running IKE over
>> IPsec (however you do it).
>> 
>> 
>>> Let's start with a simple case where the PCP Client wants to initiate
>>> and authenticated PCP request...
>>> 
>>> The Client needs to ask the PANA Client to initiate authentication.
>>> How?  
>> 
>> PCP software triggers the PaC to perform authentication.
>> Like how IKE gets triggered when IPsec SA needs to be setup.
>> 
>> 
>>> Will that request include any details about the mapping request that is
>>> being made?  i.e. will the PANA Client be asking for authentication _and
>>> authorization_ to perform a particular action?  Or do we assume that a
>>> PCP client is authenticated via PANA, and that authorization for a
>>> particular action is a separate step that is performed as part of PCP?
>>> If they are separate, do we need a new set of PCP error codes for the
>>> situation where an authenticated PCP client performs an unauthorized
>>> action, or is that already covered in the PCP spec?
>> 
>> 
>> That trigger I mentioned above will include two pieces of information: 1.
>> Indication that this is an auth/authz for PCP, 2. IP address of the PAA
>> (which is same as the PCP server).
>> 
>> 
>>> When the PCP Client asks the PANA Client to perform authentication,
>>> what are the possible results that can be returned from that request,
>>> and how are they communicated back to the PCP Client?  You have only
>>> described the success case in your document.
>> 
>> PANA already generates success and failure results. This result will be
>> conveyed to the PCP client via the API.
>> If the result is success, also the PCP_AUTH_KEY and PANA Session ID and
>> PANA Key ID need to be passed via that interface.
>> 
>> 
>> 
>>> 
>>> How does this work in the case where the PCP Server is not running a
>>> PANA Server?  I _think_ that if a PCP Client asks its PANA Client to
>>> perform authentication, and the PCP Server does support authentication,
>>> some sort of "unsupported version" error code will be returned to the
>>> _PCP Client_ (due to the details of your proposed demultiplexing
>>> scheme), and that nothing will be returned to the PANA Client, at all.
>>> We would need to make sure that secure PCP clients are specified to
>>> handle an "unsupported version" error differently when the PANA Client
>>> is in this particular state, but how does the PCP Client know that this
>>> is why that error was returned?  If this does happen, how does the PCP
>>> client inform the PANA Client that it should stop trying to perform
>>> authentication with that particular PCP Server?
>>> 
>> 
>> I'd like to first understand how the client-side decides when to use
>> authentication, and when not to?
>> Can you, or someone, explain that? Once I understand the scenarios we are
>> trying to cover, I can come back and answer your question.
>> 
>> 
>>> Also, how does the PCP Client know when the _PCP Server_ is ready to
>>> receive its request?  Are we assuming that the PANA Server will not
>>> return an indication to the PANA Client that the client has been
>>> authenticated until _after_ it has provisioned the necessary SA on the
>>> PANA Server?  
>>> 
>> 
>> The order of events is:
>> 
>> 1. PANA is executed
>> 2. PaC provides the results to the PCP client
>> 3. PCP client contacts PCP server, using  authentication tag generated
>> with the SA from step 2.
>> 4. Upon encountering new SA, PCP server contacts the PAA to obtain the
>> matching parameters (or, the PAA had already pushed those params to PCP
>> server after 1. These are different implementation choicesŠ..)
>> 
>> 
>> 
>>> What if an additional application on the same PCP Client system wants
>>> to perform an authenticated request with the same PCP Server in the
>>> meantime?  Will that second request result in a second (interleaved)
>>> PANA negotiation, or will the PCP Client be told that a PANA negotiation
>>> is already pending?  If the latter, how will the second PCP Client
>>> thread by informed when the PANA negotiation has completed?  (Note:  The
>>> right answer here depends heavily on whether the PANA authentication
>>> depends, in any way, on the contents of a specific PCP request -- the
>>> authentication vs. authentication/authorization question above).
>>> 
>> 
>> Second API call can be told that there is already an ongoing
>> authentication and wait for the result.
>> Or, maybe it says "OK" but does not generate a second PANA session
>> because the same PANA session (or, more specifically the security
>> association generated by it) can be used with both PCP requests.
>> 
>> 
>>> All of these questions will need to be answered, IMO, in a full
>>> specification of the PCP/PANA demultiplexing mechanism, precisely
>>> _because_ PCP and PANA are running separately.
>> 
>> Errr, I don't think so. None of these are impacting the over-the-wire
>> behavior (i.e., the "protocol"), but they are all about implementation --
>> not something we need to put in the protocol specs.
>> 
>> 
>> If we were to use EAP over PCP, do you think we need to define how EAP
>> methods interface with EAP which interfaces with PCP. How one triggers
>> the other and gets the results back. I don't think so.
>> 
>> 
>> 
>>> The "API" is where this coupling is provided between the two "state
>>> machines", as you refer to them.  Why is this any simpler if PANA and
>>> PCP are running side-by side than if we run PANA encapsulated in PCP?
>>> (or, if we run PCP directly over EAP, for that matter)
>>> 
>> 
>> 
>> Please see the top part about my "coupling" response.
>> 
>> If you run two protocols side by side, you point how one can trigger the
>> other. And ideally, triggers target meaningful states. E.g., one protocol
>> triggers other to run, and at the end of execution the result is returned
>> (PCP triggers PANA to execute).
>> If you run one protocol inside another, then you have to nest their state
>> machines, and unless you are purely lucky, that cannot work automatically
>> w/o aligning their state machines. (Like I said, PANA state machine is
>> designed the way it is in accordance with the EAP state machine.)
>> 
>> Alper
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Margaret
>>> 
>>> 
>> 
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp