Victor, You've raised an interesting issue (CC: Mark). Please see my comment below.
On Thu, Apr 19, 2007 at 11:50:15AM -0400, Victor Fajardo wrote: > Hi, > > A few more issues we can check: > > a. In Sec 5.5, the following text: > > " > + The last PANA-Auth-Request as well as ping request before > completion of the initial PANA-Auth-Request and > PANA-Auth-Answer exchange. > " > > should be replace with: > > " > + The last PANA-Auth-Request before completion of the initial > PANA-Auth-Request and PANA-Auth-Answer exchange. > > + Ping request. > " > > Reasons: We should not allow ping during authentication and > authorization phase and re-authentication phase since it will allow for > multiple outstanding requests to be sent (ping and auth request) which > tends to complicate state transitions. Also, we don't need liveness test > during these phases anyway since we already rely on session lifetime to > detect failed sessions. There is one problem with allowing ping in access phase only. Suppose both a PaC and a PAA are in access phase, and the PaC sends a ping request while the PAA sends a PAR to start re-authentication at the same time. Then PAA will not accept the ping request because it has entered re-authentication phase. If ping is allowed in any state, then PAA can answer to the ping request. BTW, I've found another issue here. In the above example, The PaC will accept the PAR sent from the PAA and can return a PAN, but it cannot send a new PAR (this can happen if the PAN does not carry EAP), until the ping request is answered. This is actually breaking lock-step behavior of PANA (queuing requests should not be required for a lock-step protocol). If the ping message is handled independently of other messages, then this kind of corner case will not exist. I now remember Mark's suggestion to have a separate sequence number space for pana ping and handle pana ping independently of other pana messages. I am now pretty motivated for it :) > > b. In Sec 5.5: > > " > * In the access phase: > > + PANA-Auth-Request. > " > > Just for clarity, maybe it should be "+ PANA-Auth-Request with any of its > bit flag set". I think the current text is sufficient. BTW, at least 'R' bit is set for PAR :) > > c. Optional text we want to consider for the same complexity reason as (a) > above. > > -- Sec 4.2.; First paragraph; Add a sentence: "The ping request MUST be > sent only when there are no other pending un-answered request". > -- Same with sec 4.3 and 4.4 with regards to re-auth and termination > request. Not sure how to phrase it though. Maybe "A PANA session MUST not > enter the > [re-auth|termination] phase while there are pending un-answered request" > (??). I think this is already covered in the following sentence in Section 5.2: "A peer can only have one outstanding request at a time." I found another issue on Section 5.5: PTR should be accepted in authentication and authorization phase and the re-authentication phase as well, otherwise, it will create a race condition similar to the problem of ping request and PAR for re-auth crossing each other. Regards, Yoshihiro Ohba > > regards, > victor > > > > > _______________________________________________ > Pana mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pana > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
