Re: [pcp] EAP-over-PCP

[Alper Yegin <[e-mail]>]

Hi Sam,


> 
> 
> Hi, Alper.
> Thanks for your review.
> We're glad that we were able in your eyes to successfully re-use a lot
> of the work that went into PANA design.
> We really appreciated being able to look at previous lower-layer work
> including PANA and draft-ietf-abfab-gss-eap to make our job easier.
> 
> 
> If the WG believes terminology realignment would be beneficial here,
> then we can work towards that goal.
> 
> I'd appreciate comments from PCP implementors on the state machine
> integration issue that Alper brings up.
> 
> Depending on what's easy for PCP implementations we have a number of
> options.
> 
> In RFC 3748  the conversation is conceptually server driven.
> However, there is typically a client (lower layer) indication to get
> things started.
> 
> However, the only reason that the conversation is server-driven iss
> retransmissions. If you take a look at section 2 of RFC 3748 you note
> that the protocol is lockstep. The server cannot send a new request
> until the client has responded to the previous one.  If you take a look
> at section 4.3, a lower layer may sent the retransmission timeout to
> infinite. In this mode, the server will never generate an unsolicited
> request.
> So, it's entirely possible to  view things as a client-server protocol
> with client-driven retransmissions if that makes things easier for PCP
> implementations.
> 

I don't understand how this works.
EAP authenticator performs rexmits. 
So, if it does not get a response, it'll keep rexmitting. So, how can you achieve "server will never generate an unsolicited request"?

And, furthermore, there'd be EAP re-authentication which can be initiated by the client or server. This is another reason for having to support server-side requests.

Alper








> That's the approach we took in draft-ietf-abfab-gss-eap. That spec is an
> approved EAP lower layer in the RFC editor queue. That spec treats EAP
> as a simple lock-step client-server protocol. We lose a half round trip
> because we ask the server to get started and it then asks us for our
> identity. We came up with mechanisms for including our identity in the
> first request, trimming a half round trip. The decision of that working
> group was that the complexity was not worth it, but that optimization is
> available if it helps with PCP.
> 
> so, feedback from people with PCP state machines would be really helpful
> about which of these issues matter to you.