On Thu, Apr 26, 2007 at 01:43:45PM -0400, Subir Das wrote:
> >
> > The last PANA-Auth-Request message MUST also carry an Algorithm AVP
> > if it is for the first derivation of keys in the session. The PANA
> > session MUST be deleted immediately after the last PANA-Auth message
> > exchange.[a12]
> >
> > [a12]Is it really a PANA Session? This is happening during
> > authentication and authorization phase which is a part of a PANA
> > session. Also the definition of PANA should include authorization as a
> > cause to session termination.
> >
> > [YO] Yes, it's a PANA session that is terminated
> > (s/deleted/terminated/ per your other comment.). With regard to
> > authorization as a cause to session termination, we can revise the
> > PANA Session definition in Section 2 to:
> >
> > PANA Session:
> >
> > A PANA session is established between the PANA Client (PaC) and
> > the PANA Authentication Agent (PAA), and terminates as a result
> > of an authentication or liveness test failure, a message
> > delivery failure after retransmissions reach maximum values or
> > session lifetime expiration, an explicit termination message or
> > any event that causes discontinuation of the access service. A
> > fixed session identifier is maintained throughout a session. A
> > session cannot be shared across multiple network interfaces.
> >
> > ("any event that causes discontinuation of the access service" was added.)
> >
> Subir> Fine with me. You may like to add "Authorization" after
> authentication
> since PANA session can be terminated if authorization fails but
> authentication
> succeeds.
OK.
> >
> > Implementations MUST limit the rate of performing this test. The PaC
> > and the PAA can handle rate limitation on their own, they do not have
> > to perform any coordination with each other. There is no negotiation
> > of timers for this purpose. Additionally, an implementation MAY
> > rate-limit processing of the incoming ping requests. It should be noted
> > that if a PAA or PaC which considers its connectivity lost after a
> > relatively small number of unresponsive pings coupled with a peer
> > that is aggressively rate-limiting the ping request and answer
> > messages, false-positives could result. [a14] Care should be taken when
> > rate-limiting ping request and answer messages to periodically
> > respond, and a PAA or PaC should not rely on ping request and answer
> > messages to quickly determine loss of connectivity.
> >
> > [a14]Not clear. May consider revising the senetence.
> >
> > [YO] How about this?
> >
> > "
> > Therefore, a PAA or PaC should not rely on highly frequent ping
> > request and answer message exchanges to quickly determine loss of
> > connectivity.
> >
> > "
> >
> Subir> The problem here is it is either request or answer. It can not be
> both.
> If answers arrive with frequent requests, then there is no loss of
> connectivity.
> Am I correct? Also you may delete "highly" here.
I think it might be good to describe it without mentioning request and
answer messages. How about this?
"
Therefore, a PAA or PaC should not rely on frequent ping
operation to quickly determine loss of connectivity.
"
> > The PaC may receive a PANA-Auth-Request before receiving the answer
> > to its outstanding re-authentication request message. This condition
> > can arise due to packet re-ordering or a race condition between the
> > PaC and PAA when they both attempt to engage in re-authentication.
> > The PaC MUST keep discarding the received PANA-Auth-Requests until it
> > receives the answer to its request.[a17]
> >
> > [a17]How will PAA know that PaC has not received it? Will PaC
> > retransmit PANA-Notification-Request?
> >
> > [YO] Yes. The PAA will answer to the PNR.
> >
> Subir> The question is when PaC will retransmit instead of discarding? This
> race condition may continue for a while.
PNR will be retranmitted by PaC based on retransmission timer. So
most probably the first retransmitssion of PNR will break the race
condition if it does not get lost.
> > 5.2. Sequence Number and Retransmission
> >
> > PANA uses sequence numbers to provide ordered and reliable delivery
> > of messages.
> >
> > The PaC and PAA maintain two sequence numbers: the next one to be
> > used for a request it initiates and the next one it expects to see in
> > a request from the other end. [a18] These sequence numbers are 32-bit
> >
> > [a18]Not clear. May cosnider revising it.
> >
> > [YO] How about this?
> >
> > "
> > The PaC and PAA maintain two sequence numbers: the one to be used
> > for the next outgoing request and the one it expects to see in the
> > next incoming request.
> >
> > "
> >
> Subir> How about this:
>
> "The PaC and PAA maintain two sequence numbers: one is for outgoing
> request and the other one is for incoming request."
OK.
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
